07:48
GenericRegisterAllocator need not be abstract and actually implemented by
a sub-class. It just has to register the set of registers used for it and that
is basically it.
07:49
So I need a stack register, and one that indicates the current method.
07:51
So what I need is an effective means of pool sharing. I want a single constant pool shared for all methods. If I had a per-method pool there would be duplicate information but I would have a method pointer for the most part. I already have a stack register. I am going to need one for the table. Let me see which x86 registers could act as GPRs.
08:01
So x86 has the following:
EBPEBXESI-- Only used in a few instructions (MOVSB,MOVSW, etc.)EDI-- Only used in a few instructions (MOVSB,MOVSW, etc.)
This would mean that my current allocation is 2.
09:12
So my allocator will need state so that I can store the specific state of what is allocated for jumping backwards and such. One thing to consider is that I will need to store state for every operation since I do not know locations which are jumped back to (I do not scan these beforehand). So it depends, do I shave off some memory usage for processing time by getting the jump targets? It might not be worth it as much however. When it comes to exception handling, I would need to have it where the exception handler uses the same exact state and such and the same stack. However, with my plan to copy anything to locals when they are set, would mean that exception handlers would not need to worry much about which local variables are assigned where. Then due to the rules of the virtual machine, I then am able to have it where I can just keep things very simple by not going into much computational complexity when parsing.
09:17
The class name for the register allocator is quite too long.
09:24
Thinking about it, is the current method this is in really needed at all? Well if an exception does occur, it will need to know which exception handler to jump to since the entire pool set is shared. Also some kind of evil optimization code can do is to change the this pointer, since in reality all methods are really static for the most part.
10:14
If I have differing return types and keeping it only singular with int/float then I can handle MMIX where int and float are stored in the same registers.
10:18
Actually that will not work, because the system could also be 16-bit which means I need more types.
10:25
Actually, the generic JIT should be used for 32-bit and 64-bit systems. When it comes to 16-bit and lower, there would have to be a new JIT anyway because that JIT should be optimized for said systems. If I were to support 8-bit and 16-bit with the generic JIT that would be needlessly complicated. It could actually work, but to the generic JIT it would have to for example make it so that all operations act as if they were done in 32-bit registers.
10:29
Right now my generic format is limited to 16-bit limitations for the most part, but that definitely does keep the binary size small.
10:35
So then the question is, is a pool and method pointer part of the allocator? A register would have to be used for PIC.