Hi,
On Fri 22 Oct 2010 06:29, Noah Lavine <noah.b.lav...@gmail.com> writes:
> After not emailing for a while, I have some good news: a JIT engine is
> working!
Great news!
I have been behind on things a bit, so apologies for taking a month to
get back to you, and then only partially. In any case Ludovic probably
knows more both about assembly and JIT work, so I'm happy to not be a
"gatekeeper" of sorts here...
That said, I am concerned about complexity. The current VM, though
obviously slow, does have the advantage of being relatively
simple. Adding a JIT complicates things. Well, adding another form of
compilation complicates things, JIT or AOT or whatever -- so my primary
concern is that, as we add native compilation, we need to keep things
mentally tractable.
I have worked with many people who seem to be able to keep an inhuman
number of names and relationships in their head at one time. I fear I am
not such a person, so we will have to keep things extra-simple :)
So what I would really like to see would be:
* Ideally, a 4-word objcode representation that includes native
code.
* A well-defined convention for that native code. That's to say that
the native code could come from JIT compilation, or from AOT
compilation.
* A uniform way to invoke native code from the VM, and VM code from
native code -- *preserving tail calls*. This seems to require either
trampolines within the VM or platform-specific tail-call assembly.
* A uniform interface to create JIT code as needed, in the call
instructions. i.e.
if (SCM_UNLIKELY (SCM_NEEDS_JIT (proc)))
scm_jit_x (proc);
or something.
We should be able to merge all of that into Guile before any JIT code
goes in, and maybe even before 2.0 if the patches were small enough and
came fast enough ;-) Then we could take our time experimenting on how
best to do native compilation.
So, to reiterate: *simple*, with a good *tail call* story. If we can
find a solution that has those characteristics, fantastic :)
Andy
--
http://wingolog.org/
