Re: A Working (but Minimal) JIT

[Noah Lavine]

Hello!

> Interesting.  Dealing with end-of-buffers situation is indeed tricky
> with lightning, and register allocation is lacking (I thought this
> wouldn’t necessarily be a problem because we can do a reasonable job
> with a fixed set of statically allocated registers.)

That seems true, yes. Given that most of the instructions won't need
to be translated, it's possible that switching back over in the middle
of the project wouldn't be that hard. (I have a partially-completed
Lightning JIT to start from, too.)

> I think it’s OK to jit just at call time at first.  There could be a
> call counter on procedures, which would allow you to determine whether
> it’s worth jitting (i.e., only jit a procedure after it’s been call at
> least N times.)

That sounds good. I think it should probably be activated by all of
the 'call' instructions, with a counter on procedures.

There is also something that I was trying to figure out but couldn't -
how does code from the REPL make its way into the VM? Specifically,
what entry point should I modify if I want REPL code to be JITted
automatically? (Is it one of the call instructions other than
'mv-call', or a call to a 'vm-*-engine' function?) That would make
testing this a lot easier.

> My plan was to use macro magic to turn each ‘VM_DEFINE_INSTRUCTION’ into
> a function definition, except for the ‘call’ instructions and similar.
> Then all the jit’d code would do is call these functions, so jitting
> would be quite simple.  Still, it’d remove one layer of interpretation,
> which could lead to performance gains.
>
> Then instructions could gradually be rewritten in libjit assembly, but
> that takes time.

That makes sense.

I have an alternate idea about how to do this, but please bear with
me, because it would be a little strange.

I could certainly rewrite the important instructions with libjit,
however, this would result in duplicated code, which is not ideal. I
was wondering if you would be interested in coming up with a way to
write them once so that they could be expanded to either
directly-runnable C code or libjit calls. (Libjit basically implements
a subset of C, so I don't think this would be too difficult.)

I was also wondering (and here's where the build process would get
weird) if this language could be translated with Guile. The goal would
be to wind up with a situation where Guile has the ability to take
some description of low-level machine operations and translate them
either into regular C code or into libjit calls. The reason is that it
would be a small step from there to building a libjit-based assembler
directly into Guile, and then you've got the ability to compile things
into machine code using only Scheme. (You could, for instance, then
write a custom compiler for regular expressions that didn't go through
the regular Guile VM instructions but just jumped to machine code.
That might be really, really fast. You could also then start writing
optimizations of Guile code in Guile.)

The trouble would be that then Guile would be used to build Guile. It
would still be possible to have a version which was completely C code,
but that wouldn't be the source version. I know this would be moving
in a strange direction, and I would understand if you thought this was
a bad idea, but I think it would have have interesting benefits.

> I’m looking forward to the next news bulletin.  ;-)

Thanks! I'll work on that. :-)

Noah