Re: A Working (but Minimal) JIT

[Noah Lavine <noah.b.lavine@gmail.com>]

Hi,

> Regarding whether or not to jit, I'm OK with doing that in the `call'
> instruction.

Sounds good. I'll put it in there. (And also in 'mv-call' and 'tail-call'.)

> 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.

I see what you mean, but I don't know of a library that fixes that.

The problem I'm having with the current code is that (I think) there
is no portable way to jump from C code to another function (or block
of machine code of any sort) without pushing a frame on the stack. A
normal C function call makes the stack deeper (unless the compiler
optimizes it, which is a GCC thing), and using a goto where the target
isn't fixed at compile time is a GCC extension. And the only other way
for a C program to do a jump is setjmp and longjmp, but I don't see a
way to use those for this.

I think that the best way is to use inline assembly to make the tail
call. But in order to do that portably, we would need a macro that
expanded to different code for GCC, MSVC, and any other compilers that
Guile wanted to support, as well as different code for different
architectures. My idea is to first do it with a trampoline, and then
maybe replace the trampoline with a macro like that.

How does all of this sound?

> Anyway, these are my concerns.  Obviously you're the one hacking the
> code, so do what you like :)

I agree with your concerns. Thanks a lot for showing me how to do this.

Noah