Re: Native Code Again

[Noah Lavine]

Him

>> Therefore, I think the path to a native-code VM is to leave the VM as
>> it is (except maybe reserve an opcode for native-code calls). Then I
>> write first a C parser for Guile and then a converter program that
>> would take Guile's current VM and output a JIT VM like I've described.
>
> Hah, it seems we concluded on the same thing after all...

Yeah, it seems like that's the way to go.

>> Specifically, you could construct the VM using the JITcode generator,
>> either on Guile startup or whenever the user decided to enable native
>> code generation.
>
> This is a very interesting possibility.  It scares me, in its
> complexity, but it does seem to handle all of the objections that I had.

The complexity actually scares me too. I only mentioned it because it
seemed like the cleanest way to make tail calls work. After reading
your email, though, maybe it's not worth it.

> And also... why not rely on gcc's tail-call optimization, in the case
> where it works?  You can check for it at configure-time.  I just ran
> some small tests for tail-calls between functions in separate
> compilation units and it shows that indeed, gcc does the right thing.

I don't think you want to rely on that, because then programs might
break at -O0 that would work fine at higher optimization levels.
However, if GCC added a special intrinsic function that would always
do a tail call, then that could work. And they might very well add it
if we asked them to.

> I guess that given this circumstance, things are a lot easier.  The JIT
> library still needs to know how to tail-call a C function, but that is
> more tractable.  If you don't have tail-calls, perhaps the JIT compiler
> uses trampolines as you and Ludovic proposed; and that becomes a case
> that only gets exercised with -O0, and possibly not even then if we add
> -foptimize-sibling-calls when available.

Well, the JIT library can already tail-call C code. That's the reason
I had thought of using the JIT library to generate the VM. The main
advantage of that is that tail calls would work everywhere the JIT
works, so there wouldn't be any new restrictions on what platforms
could use JIT. (Also, it frees me from having to do more work.) But
even with that advantage, it could make startup really slow, and it's
hugely complex, as you say.

I suppose ultimately the best thing would be to make C code do tail
calls. As far as I can tell, all major C compilers (gcc, icc, msvc,
llvm) support inline assembly, so it can be done. It might be easiest,
though, to do trampolines first, and then implement real tail calls
platform-by-platform. (That may have been what you were saying, too.)

Noah