I thought about how the JIT would operate. Since going with a strictly linear
single pass would complicate some things (although it would work), I will
read in the byte code and all the associated details for a single method first.
Before however, I would determine the size of operations and then parse those.
However I believe this time I will just have a program to micro-op kind of
thing where instead I read it straight from the input stream. I do not worry
yet about which types are at which position, I just read in the byte code.
Then once it is read in, I mark places where exceptions occur, and then when
Table) is read I mark places where entry points are in the
micro operations. Then once I have all that information I can do some
verification and perform basic stack caching optimizations and such. At least
this way I would not need to have the code byte array duplicated in memory
while I build an object representation of it.
Something that would be handy would be to just emulate an executable automatically as if nothing happened. This could be useful instead of packing it into a ZIP and such.
Seems my ZIP writer has trouble writing the hello ELF and forms a bad ZIP.
Actually no I am using it wrong, I never closed the ZIP.
I can likely simplify the emulator system and move some packages around. Since
chv stuff is emulator only, it would likely be best to rename it.
So to simplify some loading operations, I can have it where I have a class based representation of an executable object where there is then a kind of generic loader regardless of the binary format. Generally I would want this so that the code is very similar and abstracted. There also needs to be the consideration that many targets will need ELF binaries parsed and such.