Re: A Working (but Minimal) JIT

[Andy Wingo]

Hi Noah,

Apologies for the stochastic response times here...

On Thu 02 Dec 2010 04:58, Noah Lavine <address@hidden> 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/