On Thu, Nov 14, 2002 at 11:23:04AM -0300, Daniel Grunblatt wrote: > On Thursday 14 November 2002 10:32, Leopold Toetsch wrote: > > Daniel Grunblatt wrote: > > > On Thursday 14 November 2002 05:14, Leopold Toetsch wrote: > > >>What JIT needs to know is the location of the resume opcode, to mark it > > >>as a jump target properly, so that processor registers can be setup > > >>correctly. > > > > > > Well, any opcode could be a target, so I suggest to build something like > > > a section entrance code that given the PC could load the apropiate > > > registers and jump to the middle of a jitted section. Yes, it will be > > > slow but we are talking about exceptions here.
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. If we know all resume targets in advance (care of the compiler or assembler labels, even if all resume targets includes "all opcodes that follow any opcode that could throw an exception") then I think life is a lot easier. [which is probably what the bits I've snipped were saying] 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. (so a division by zero exception has to resume after the op. er. what happens on some sort of PMC fetch exception. Can it resume internally? ) > > There must be some code, that installs the exception handler. This code > > has the address of the exception handler, which JIT has to know too. > > Being prepared to enter at arbitrary places in JIT would inhibit > > processor register usage totally, or wouldn't be any win. > > > > Either I didn't make my self clear (sorry) or my understanding of exceptions > is wrong ... probably both. > > 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 and jump into the jitted code again but if there > was no exception the jitted code executes as usual. 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. Nicholas Clark
