Re: Native Code Again

[Ken Raeburn]

On Jan 28, 2011, at 09:33, Noah Lavine wrote:
> 
>> 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.

It's also dependent on code-specific and machine-specific parameters that are 
coded into gcc; skimming some sources briefly (and keep in mind, I'm a bit 
rusty at this), it looks like:

 * various cases of needing different amounts of stack space for arguments
 * alpha: target must be known to use same $gp value; no indirect calls
 * arm: can't be 'long' call out of range of short branch insn; no indirect 
calls
 * ia64: target must be known to use same GP
 * pa: must be 32-bit mode; target must be static function in same file if not 
ELF; no "portable runtime"?
 * rs6000: no indirect calls; target must be static (I think?) if AIX
 * rx: no indirect calls
 * sparc: no indirect calls

There are other constraints I've ignored, for example if return registers 
differ (because return types are different) or some cases of PIC code 
generation (unless you're thinking of writing out object code to reload 
later?).  The requirements for no indirect calls need to be looked at platform 
by platform; I expect for the generated code that we would be using indirect 
calls, wouldn't we, with target addresses loaded from structures?

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

They probably all do, but you'd have to know how to release the stack frame, 
possibly restore saved registers, put the outgoing arguments into the right 
locations, adjust for differing numbers of arguments, etc.

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

Starting with trampolines seems like a good idea to me.

Ken