Jason Gloudon wrote:
On Thu, Nov 14, 2002 at 04:28:00PM +0100, Leopold Toetsch wrote:
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.
Rather inefficient, as probably every function may throw an exception (i.e. a PMC called with a wrong vtable method), but of course a doable approach.
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.
I'd rather restore registers properly. We know per section, which registers are used, so it shouldn't be too hard.
... As has been pointed out a few times before, exceptions and the restart ops present the same problem.
Yes, current restart code (i386) would break, when registers are saved through external calls.
restarting JIT, exceptions or multiple segments are all similar. WRT inefficiency: current JIT code is slow for external code - mainly when PMCs are involved (I have some ideas to get this a lot faster) and JIT code is produced at program load time. The latter could be done in IMCC, which has all the info (basic blocks ...) ready, so this info could be passed on to build_asm, which would be a lot simpler and somehow faster.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).
I do expect to JIT compile everything.
leo
