A Working (but Minimal) JIT

[Noah Lavine]

Hello all,

After not emailing for a while, I have some good news: a JIT engine is working!

The current version is as minimal as possible. It can only JIT a
function that does nothing and returns 0. And it's only activated by
the 'mv-call' VM instruction. Here's how I've been testing it:

> (define (return-0) 0)
> (define (call-it) (return-0) 0)
> (call-it)
0

That last 0 is returned by JITed code.

The patch against master contains a lot of uninteresting things in
addition to the few interesting ones, so I've put the whole repository
on GitHub to make getting it easier. It's at
address@hidden:noahl/guile-jit.git .

The biggest change since the last version is that I switched from
Lightning to libjit. This was mostly because I realized that if I was
going to use Lightning, I would need to implement a register
allocator, and seemed like a bad idea when libjit already had one.
libjit also solved a memory allocation problem which had been causing
trouble in the Lightning version, and in general has a very
easy-to-use interface, so I think this is a good way to go.

(You'll probably need to configure Guile with '-ljit' to build it,
assuming you have libjit installed in standard include and library
paths. The people from the libjit mailing list recommended using their
git version, which you can find at
http://git.savannah.gnu.org/cgit/dotgnu-pnet/libjit.git, rather than
the latest release.)

I also changed the interface between JITed code and compiled code a
bit, in a way that I think makes more sense, but probably neither way
I've tried is optimal.

I hope this is the sort of JIT engine that you might want to include
into Guile. I think it more or less follows Ludo's plan for
compilation. As I see it, there are now two big tasks to be undertaken
before that could happen, and they're independent.

First, we would need to figure out how to integrate this into the VM
more. Right now it's only activated in the 'mv-call' instruction, but
it should be activated by all of the instructions. Also, the calling
method looks pretty ugly to me now. I'd like to find a way to smooth
it out, but I'm not sure how. Finally, this version uses a five-word
representation for procedures, but it might be possible to get it back
down to four.

Second, the compiler would need to be extended to handle more VM
opcodes. This is a task that could be done incrementally. The compiler
is basically a big switch statement that does each opcode in turn, and
it has the ability to give up at any point if it sees an opcode it
doesn't know how to translate, so opcodes can be added one at a time.
(I would actually like to talk about an alternate way to do that, but
that's a good conversation to have after people decide that the
general design is what Guile needs.)

So, this is a possible way to get a JIT engine in Guile. What do
people think of it?

Noah Lavine