I will need to remember which allocations were saved to the stack so that when I invoke a method, if any are used/cached on the stack then their actual register values may be used insted of generating another copy.


I saw compilation fail and the JIT being launched anyway.


Actually that is because of the optional dependencies.


I suppose I should store the old stack pointer just before the address of the new stack pointer. Return can essentially restore this old value and then jump to the return address location. So this way, in the exception handler it knows where to restore the stack value since it is in a known location. The exception handler would have to have it so that it uses the actual method stack needing during its handling work.


Also, I can store the reference to the method also for stack trace purposes which would be needed for debugging. I can keep that information in a register so that it is always around. And when a method is returned it can be restored.


Actually the argument allocator will need a flag that specifies that allocations are not to be saved. Then I can use argumentAllocate for method calls.


Argument allocation handling along with methods is very tricky. I basically lose association of the original types and I would have to handle long/double in multiple ways. So I believe for arguments that I will add a new class for argument input and output keys. Basically it would be NativeArgumentInput<X>. When an argument gets an allocation it would be returned in a NativeArgumentOutput<X>. This way it will be much easier to determine which variables were actually allocated.


invokeMethod could probably use the stack map types for the method call potentially, although variables might be better.


Well this rewritten argument allocation code is much nicer.


The argument priming method definitely got much smaller, the same will be said of method invocations.


Actually, it may be easier if I continue doing something similar with the method arguments and storing it in a class. It can contain the method and the stack type rather than convoluting the structure information which would be very useful.


I am going to need some common interfaces for the native code output streams that actually write the machine code.


The common interface can use a new RISCRegister and an ofInteger and such placed there. The base interface I described earlier can be generic using the specific implementation of the register type.