[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Native Code Again
Re: Native Code Again
Fri, 28 Jan 2011 11:19:55 -0500
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
* 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.