Ahhh, I get you. Sounds like it could be incredibly fast indeed.
Cas 
[quote]Ahhh, I get you. Sounds like it could be incredibly fast indeed.
[/quote]
Well, it turns out I was a little dumb. I learned that there was no way to distingush between program code and data in the ROM unless I actually execute the code and follow the jumps. sigh
Itās the same principle I outlined before - itās just that the work now has to be deferred until runtime, like Hotspot, instead of load time.
This is farking buttloads easier for something like JET, that can know which classfile data is actually bytecode instructions.
God bless,
-Toby Reyelts
Maybe you can flag 256 byte or 1k pages in memory as being recently written to and upon attempting to execute code in such a page, run it through the compiler?
Cas
[quote]Maybe you can flag 256 byte or 1k pages in memory as being recently written to and upon attempting to execute code in such a page, run it through the compiler?
[/quote]
I think thereās some miscommunication.
The point Iām trying to make, is that I canāt translate the machine code, unless I can follow the jumps. This is because the bits immediately following a jump may be anything - data/garbage/whatever. Once I hit that, thereās no way to continue. I considered trying to statically follow the jumps, but this seems nearly impossible for half the jumps, which do things like jump to an address stored in a register. (You canāt even do clever stuff, like look for a CALL before a RET, because the crazy programmer may have done something insane like do a RET without having ever executed a CALL). So the only recourse I have is to track instructions as they are executed.
This is annoying compared to something like a Java class file, where there is no difficulty in understanding what parts are data and what parts are bytecode. It gets even nicer than that, because Java mandates that you do have to be able to statically analyse where a program can jump to.
God bless,
-Toby Reyelts