[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A Working (but Minimal) JIT

From: Andy Wingo
Subject: Re: A Working (but Minimal) JIT
Date: Sat, 20 Nov 2010 14:37:04 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)


On Fri 22 Oct 2010 06:29, Noah Lavine <address@hidden> 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

  * A well-defined convention for that native code. That's to say that
    the native code could come from JIT compilation, or from AOT

  * 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 :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]