Nicholas Clark wrote:
On Thu, Nov 14, 2002 at 11:23:04AM -0300, Daniel Grunblatt wrote:
Can any opcode be a resume target without knowing that it is a resume target? If yes, we have a nasty time being a JIT.
The question is "without knowing". I think the resume address is known (somewhere at least) because the exception handler has to be set up.
In my mind there seem to be two classes of things: ops that could throw exceptions ops that could be the resume target of exceptions I'm assuming that we can only resume on op boundaries.
I think so.
(so a division by zero exception has to resume after the op.
Or could retry the op (as was proposed in perl6-language) after correcting the "problem".
er. what happens on some sort of PMC fetch exception. Can it resume internally?
Unlikely, either the op is repeatable or not (because it already had side effects)
When, say, div throws an exception it will longjmp to the handler, that handler will know where to continue the execution of the program, right? so after doing its job it will have to call a function that given a PC will load the cpu registers as needed ...
This code has to be in JIT already (with probably some helper function outside), so it could be rather complicated, but it is doable of course.
This sounds horribly like the C rule of don't rely on automatic variables after the return from longjump. No. I don't have an answer.
But I have a proposal:
- Normal runloops don't have a problem with longjmp
- 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
As we already seem to need to restore processor registers on resume, we could do the reverse thing on exception too.
Nicholas Clark
leo
