09:43
Actually the other way around would be better. That is having the Set use the map, I can really just use null keys or a marker object.
14:09
No wonder no nodes were ever red, since the color default to null, basically just black.
15:58
So calling a method requires that temporary registers are saved somewhere. Any arguments to be passed are placed in the argument registers. If an argument is not temporary then that also must be saved. Due to my previous ruling of forcing locals to always be up to date, locals do not have to be saved, only temporary registers that are on the Java stack which use temporary registers. A such, the minimum stack space needed for a method is the number of local variables which are available. So then this means that local variables are copied on the call and also passed as arguments to be stored in local variables on the stack for exception handling. Basically since locals must be stored on the CPU's stack for exception handling (so they can be restored by the exception handler, or some other jump target), at the start of every method I will need to generate code that copies the input arguments to these positions. The number and type of input arguments are always known however. This may be the simplest route to take, although there will be a loss of speed due to storing values in memory. However, the locals would operate on an entirely copy on write mentality. Then this also means that saved registers are mapped to local variables and the initial arguments are just saved. However if the input argument registers are considered temporary then their values can just be copied to the saved registers which are then mapped to local variables, written to the stack, and the temporaries cleared. This would be a bit of a shuffle however.
16:08
The copying and shuffling can be done right after the arguments are primed and the first instruction point placed after the shuffle code.
17:35
Although it will be slightly shuffled, because I should have the remaining arguments first. This way I can still conform to the calling convention in case I ever need to call libraries.
18:21
For the LUI, I can cheat by making a vt100 interface that just uses
System.out. I can then additionally work on Squirrel Quarrel and have for
example AIs battling each other. Although I would be unable to play I could
use the basic interface to implement a few other things however. Also with the
plan for LUI interfaces, I can even have a LUI interface which implements the
LCD UI from MIDP 3 potentially. I suppose that I would like these interfaces
to be visible via the service loader, however this basic interface should
have a very low number so that it is chosen last.
18:51
Then with the LUI service displays, when it comes to different operating systems I can have differing backends. I suppose for sanity that the display service will implement a console of a given size with attributes. Then the display service just literally needs a redraw or a draw command that is called that performs the actual work. This way the actual implementing code is kept as simple as possible. Pretty much every display device that I know of uses a cell based interface.