On Thu, Nov 14, 2002 at 04:28:00PM +0100, Leopold Toetsch wrote: > - JIT could have it's own low level exception handler: > * gets jumped to, so registers are still ok > * saves processor registers to parrots > * then longjmps to parrot handler
I didn't finish my response... The way I have thought this would be done (given C opcode functions raising exceptions) is to spill parrot registers back into the interpreter structure from hardware registers before calling opcode functions that might raise exceptions using longjmp. Spill here means we update the interpreter structure registers, but consider the CPU register values still valid if the opcode does not raise an exception. JIT code that needs to raise an exception can do the same thing as C code, call the exception raising function that does a longjmp. The runops loop would use setjmp to catch the exception and will do one of at least two things: Determine that the exception resumes control at an op that can be safely jumped to in JIT generated code. In other words the op is not in the middle of a section of code for which the JIT code assumes a certain register allocation. Or Find that the execution resumes control somewhere that is not safe to jump to in the JIT code (or has not been JIT compiled), and passes control to the interpreter runops loop. The remaining issue is then determining when it is again safe to resume jit execution so that control can be passed back to the JIT code. I have a few ideas on doing this, but I'd like to hear what folks have to suggest. As has been pointed out a few times before, exceptions and the restart ops present the same problem. The fact is that the above complication will be necessary once we start dealing with multiple non-contiguous bytecode segments, as I do not expect one will JIT compile every piece of code because of the inefficiency of doing that (unless we make the JIT code less specialized than it is on at least IA-32/x86, where addresses of registers and the interpreter pointer are embedded in the generated code). -- Jason
