2015/04/09

DISCLAIMER: These notes are from the defunct k8 project which precedes SquirrelJME. The notes for SquirrelJME start on 2016/02/26! The k8 project was effectively a Java SE 8 operating system and as such all of the notes are in the context of that scope. That project is no longer my goal as SquirrelJME is the spiritual successor to it.

15:18

My XPM decoder is a bit messy and could be optimized much better. I am also missing support for X11 color names as color input.

15:42

The XPM decoder could also use the progress indicators for those that may need it when an image is loaded. I can most likely optimize the XPM reader and use strips of input from a giant character array of sorts and then decode lines based on that instead and perhaps save on the tokenization phase with the simple tokenizer included in Java.

17:37

I believe I need a better class which describes the target CPU rather than using JSON architecture information since that can be messy. Right now the only thing I have which describes an architecture is the set of registers and then I rely on JSON architecture information to provide for the size of registers and such. However not all registers are created equal, and this becomes a problem when there are various mixes of register setups. So my current information set does not work and needs to be replaced. I can provide a manager which is able to be used by ServiceLoader to find CPU definition and any assembler bits as needed. Then FormCodeProfile can be modified so that it uses said definition sets rather than defining all of it itself. This would simplify and make it more powerful. Then using the CPU information I can then create generators which can handle more instruction sets and CPU types without much trouble.

18:47

This new CPU data stuff appears that it will be very efficient and help make things easier to use.

19:41

Big thunderstorm arrived, so I quickly shut my laptop off.

20:03

I can also deprecate AssemblyLanguage since the CPUData essentially replaces it.

20:12

Well, I cannot deprecate it exactly because then I would need lots of CPU definitions for stuff that might not even exist. So it would be best to move it into the transcompiler since it is used there for the most part.

21:39

Since CPUData is rather static and I would like to cache it, CPUProvider should not have their own but instead use lambda for new creation and such so that the parent classes take care of all the caching and such.

21:42

So then the question remains, is CPUData to be even abstract or just final. If CPUProvider is going to handle caching and validity of bits then there might not even be a need for extended CPUData classes. Right now there is nothing abstract in CPUData at all. But doing everthing through the provider will be much cleaner. There is really no need to recreate thousands of CPUData classes when all of them will be the same anyway. Generally in most cases only a single one will exist at a time, unless another object which was compiled by something else was obtained. So yes, CPUProvider will do all the heavy lifting and CPUData will become final and immutable to be cached by CPUProvider. Then I can perform more complex handling of registers based on input flags and such.