07:39
Thinking about it, does it really matter if my compiler normally treats saved and unsaved registers as the same for the most part.
07:45
One thing though is that a register could possibly exist in both a register and the stack, in the event of local variables.
08:15
The stack is going to need correction due to the way I pass variables. I make it so that objects are their native pointer size rather than slot size. One thing I will have to manage though is making sure no space is wasted on the stack for objects. Essentially if an object is on the stack it should fit within a slot. Then I suppose for the allocator if it detects that an attempt is made for example writing a 64-bit object to a 32-bit slot, that it will adjust accordingly. This would be better than making all slots 32-bit which would mean that on 64-bit systems the stack would become extra bloated.
09:48
I can do the initial local argument rebinding to the stack as required in the priming, just after priming I have to generate copies as needed if a local is in a register argument and the stack.
09:52
One thing I might want to do is to decouple the native machine code bits (stuff that is used by the generic JIT to generate machine code). In the future I may want to write a second JIT, so I will need to do a refactoring split of the generic JIT. However, although I could do it now, that would complicate my current design because I only have a partial JIT and I do not yet know the final code layout.
10:02
However, this only needs to be done for exception handlers. If there are none in the code then it does not have to be performed.
10:04
In fact, if there are no exception handlers then I never need to copy the locals to the CPU stack at all.
10:06
When it comes to synchronized methods, if a method is synchronized I will
need a monitor exit before every return and a monitor enter. Additionally,
there will need to be an implicit finally that just does monitor exit. Although
actually, this is stored in a local variable somewhere, although it just
needs to be copied somewhere if a method is synchronized so that even if the
this variable gets replaced it is not lost. The implicit finally or other
monitor exit can really just load from this special stack location.
10:38
Actually with the linkage stuff in the pool, I only need to handle the calling convention in the generator. Really the linker just takes care of the links for the most part. This actually simplifies things greatly.
10:41
Actually one thing I will need to do is make the global pool accessible to the
sub-writer implementations in the generic code. Although this might not
actually be required at all. The class GenericMethodWriter and such can be
changed so that it uses a configuration object of sorts. This way the
constructor can grow as needed in the future.
10:46
So yes, the global pool could be rewritten. I can pretty much change the
loading stuff to use slightly new logic. Then make GenericMethodWriter and
friends get a method configuration so that factory-like construction is
made simpler and allows for growing. Also, although I keep going back to this
and such, I can have an interpreter on top of the JIT for testing purposes.
It would not be an actual compiled environment, but the run-time would run on
the JIT.
10:53
Although, I should add the interpreted JIT much later on in the future. This way I can see how well new JITs scale.
12:42
My Git exports should have my name changed and such to use my name and my e-mail.
13:11
And now my name has changed, at least in the Git mirrors that I maintain. GitHub was incapable of setting up aliases in repositories although BitBucket supports such things.
13:20
So that change as I mentioned before, only affects the generic method writer code, although it still needs to be given the pool and a few other things. My first goal should be to make the global pool visible to implementations of the generic JIT.
13:57
I should start to write more detailed commit messages and increase my current standards.
16:44
That might be a bit costly though due to the early state of the project. Everything is changing very fast so there are no real stable bits as much.
17:13
It would be best if my error listing went to the base of the project. Also the
DisplayService should use a class which handles terminal size and attribute
data.
17:24
Another useful thing would be if the error listing code told me what the error code for the current project is.
17:36
The code that is appearing for the LUI code is getting a bit ugly. I believe something that I need instead is a terminal driver of sorts. The display code will just then access the terminal directly via devices. Then I can remove the need for a separate service and just have a terminal service so to speak.
18:00
So yes, a terminal driver, then a meep-lui-terminal which then uses that.
This would be very simple to do.
18:07
It would also be nice if manifests were auto-generated by the create script also. This would save some time.
20:30
As before I would have the meep-lui-terminal package, that will provide
LUItoTerminal and TerminalToLUI. Then one thing I can do is make a
hypothetical mini-POSIX environment that I can use on a given system. It should
be an environment that can be used for developing SquirrelJME. Then later on
I can integrate the shell with an IDE.