Hi Noah, Apologies for the stochastic response times here...
On Thu 02 Dec 2010 04:58, Noah Lavine <noah.b.lav...@gmail.com> writes: > have the JITed code be a C function that returns an enum to indicate > what the VM should do next. This is widely known as the "trampoline" approach -- you fall down to some known dispatcher, then bounce back up. It would be nice to avoid it though. And actually, terminology-wise, I should have been more precise when I said: >> I prefer the trampoline approach used by primitives, continuations, >> foreign functions, etc -- they are normal procedures, whose code is a >> stub that does the type-specific dispatch. Let's call this sort of thing the "stub" pattern. > 1. Make the regular 'call' instruction be the one that implements > JITing. But this would introduce a branch to procedure calls. Regarding whether or not to jit, I'm OK with doing that in the `call' instruction. > 2. Add an instruction, to be put in the normal function preamble, that > decides whether or not to JIT the function that is currently > executing I think this would be too much overhead. > It sounds like 2 is what you want. Is that right? (Currently I'm doing > option 1.) No, I think what you're doing is right in this regard. But regarding how to call a natively-compiled function -- I think this is really, really critical. It's an important decision that will have some far-reaching effects. I would like for natively-compiled functions to get their objcode replaced with a short stub that tail-calls the native code -- maybe the stub would consist of just one instruction, `native-call' or something. (Obviously this instruction doesn't exist yet). That instruction would do a tail call in such a way that the vm engine is no longer on the stack. I am concerned about JIT libraries precisely because they tend to impose a C calling convention on native code, without allowing for more appropriate conventions that allow for tail calls and multiple values on the stack. Anyway, these are my concerns. Obviously you're the one hacking the code, so do what you like :) Happy hacking, Andy -- http://wingolog.org/
