Re: A Working (but Minimal) JIT

[Noah Lavine]

Hi,

> I am concerned about complexity.

I agree that complexity is a problem. I just sent an email about
Jitgen, which is something I cooked up to reduce code duplication.
However, I can't tell if it's going to end up reducing code complexity
or increasing it. What do you think?

> 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.

Let me answer these together, because I think they affect each other.

I've been poking around in the code, and noticed that procs.c has a
reference to "applicable structs". As I understand it, these are
structures that can also act as procedures. Procedures with setters
are implemented this way. Is it possible to use these as containers
for JITed code, and leave the objcode format alone? (And on a related
note, is there any documentation for them?)

I've been thinking about this because even if I could put JIT code in
the objcode struct now, that wouldn't make much sense for AOT compiled
code that wouldn't necessarily have or want objcode. It might be
better to pick an interface to compiled code now that would work with
AOT compiled code in the future, as you say.

>  * 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.

This one could be hard. I can make JITed code call the VM as a tail
call, because libjit will generate tail calls if you ask it to, but I
don't see how to get from C code to JIT code without pushing onto the
stack without either some assembly code or a trampoline. I think a
trampoline would be easier, but I will ask on the libjit mailing list
how people have solved this before.

>  * 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.

That seems easy enough.

Noah

On Sat, Nov 20, 2010 at 8:37 AM, Andy Wingo <address@hidden> wrote:
> Hi,
>
> 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
>    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/
>