Øyvind Harboe wrote:
Trampolines are strange things... :-)
- Are nested functions part of the C standard or a GCC extension?
I believe the answer is a GCC extension. I have seen evidence,
but no proof to this effect.
They are of course a gcc extension
- AFAICT, the cris target is saving the value of the
static chain register in the trampoline. How can that work
with recursive functions? Does the cris target PASS or FAIL
gcc.dg/trampoline-1.c?
It should work fine, because the trampoline is supposed to be
built on the stack
- Lately e.g. the AMD CPU has added support for making it impossible
to execute code on the stack. The town isn't big enough for
both stack based trampolines and stack code execution protection.
What happens now?
Usually it is possible to disable this stack protection. If it is not
possible, then that's a very serious limitation.
- Are trampolines used for anything else but nested functions
in C? I believe they are used by Ada.
They are used by both the Ada and Pascal front ends in a fundamentally
critical way.
- Many backends do not support trampolines. Are trampolines
something that is ultimately being added to the backends?
We have not encountered any targets not supporting nested functions
in porting Ada to many different targets.
- Do (theoretical?) alternatives to trampolines exist? I.e. something
that does not generate code runtime.
Yes, you could have double length pointers for function pointers (pointer
to code + static link). This is the more conventional implementation, but
it introduces an overhead when not using nested functions. This overhead
is more than acceptable in Ada, where it would be very nice to get rid
of trampolines for efficiency's sake. But for C this would not be acceptable.
My personal uninformed opinion is that trampolines cause more trouble
than they are worth.
Well as I said above, trampolines or an equivalent are currently critically
needed by some front ends (and of course by anyone using the (very useful IMO)
extension of nested functions in C).
