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 g...@github.com: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
