Oyvind Harboe wrote:
> Trampolines are strange things... :-)
> - 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?
> - Do (theoretical?) alternatives to trampolines exist? I.e. something
> that does not generate code runtime.
The main purpose of tramplines is to provide a function with extra
data privete to given instance (and to do this at runtime). There
are some alternatives: `thick pointers' and double indirection.
Both methods associate extra data with function pointers and require
different way of calling functions via function pointers. Thick
pinters carry extra data together with the pointer, making calls
faster but copying slower. Also, thick pointers beeing bigger then
machine addressess are not compatible with usual pointers.
Double indirection slows calls, but pinter is compatible with
machine address and cheaper to copy around.
If a language wants to interface with C then the language must
use the same representaition of function pointers as C. For standard C
thick pointers are both inefficient and may break a lot of real code.
Double indirection is quite compatible (and IFAIK is used by some
system ABI-s). Still for C double indirection is more expensive
then calling pointer directly. And for established targets ABI is
fixed, so there is no choice...
One can always imagine different implementation. For example, assign
invalid adresses to function pointer and use a signal handler to
sort out what should be called and with what arguments. But I will
not advocate such implementation.
So given constraint of compatibility with existing C implementations
trampolines look like the best choice. Tramplines are in fact standard
implementation technique in functional languages, especially for
interfacing with C.
But there is no need to generate trampolines on the stack. Namely,
one can generate code in a separate area. In C this causes problems
with garbage collection, which IMHO can be solved, but requre alloca-like
tricks. On the other hand trampolines in separate area may provide
extra functionality, beyond what nested functions give. For example
they can be used to "partially apply" a function, giving it some
frozen arguments, and providing the rest at call time.
There is some connestion with objects: "partial applicatin" can produce
pointer to a method compatible with usual calling convention.
--
Waldek Hebisch
[EMAIL PROTECTED]
