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.
09:35
And last night was not really that great, in terms of sleep. Oh well.
10:31
Due to the variadic nature of Assembler's put, referencing that will be easy, however the specific actual instruction bits will be a bit more tricky.
10:37
The generic code should be just saveToCall then a down step into the native macro set. Since even with a method it will vary how an architecture will reference said reference.
11:43
The DecodedMethod argument list should contain the first instance object if the method itself is not static. This also makes the allocator be correct if the method being modified is static or not, since the first register set is included as needed.
12:09
It might be easier if I were to have saved registers (local variables) and volatile ones in the register set. That way when I do exception handling in the future, only the local variables are saved and I do not need to worry about the volatile temporary ones at all. It would make it a bit easier to handle as a bunch of registers can be ignored as they are not truly important.
12:21
And then I have to add checking to make sure that the temporary IDs do not clash with non-temporaries. Although that is not that strict of a requirement.
12:30
The temporary stuff is only for exception handlers though, so it should probably be called unsaved instead or similar.
12:39
Then with the saved and unsaved, at least for PowerPC I can keep the saved registers in the same location so that I do not have to do magical stack reworking whenever I call an exception. However, saved values that exceed the register count and that are placed on the stack will cause some slow down when there are many of them in use. However, the optimizer can reduce that possibility by shuffling the values when needed. Shuffling as in a register that would be on the stack is instead swapped with another if in case it is never used at all. Or alternatively, the most lively ones could be re-ordered so they are in actual registers rather than the stack. Unsaved values for exceptions can just end up being in the "volatile" register usage set and ignored when an exception handler is used.
12:44
Was thinking of having the first register return value be the same as the first argument register, but that might be a bit nasty when used.
12:55
This means that Allocation/Allocator need to be changed so that saved registers are more important and stick to a single location.
13:00
I put a note for that. Another thing that I am thinking about is the return register and the initial register map for Java locals. The return register is an output register however. I notice that the getFirstUnusedRegister() I made specifically to use the first possible correct register for a method is a bit toasted. The initial state of a Java method call does not exactly match by genericized register state with the kind of locals Java uses. So at the start of a Java method I am going to have to do some decoding and moving around so that the input types (for long/double) are correctly mapped to the working set of values.
13:07
Actually, for the return register it would kind of be simpler to share the first argument since it will just get trashed when the calling method is restored anyway so there is no point in dedicating an entire register to it when it is only used once.
14:25
Allocator and thus Allocation need changing to support the saved and unsaved states as needed. But having the saved and unsaved just made handling exceptions much much easier. Since before I would have had to have super complex state moving around and that may just have been slower.