Robert Dewar wrote: > Waldek Hebisch wrote: > > > 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. > > Trampolines do of course have to be handled in a stack like fashion (to > get recursion right), so you have to be very careful about allocation and > deallocation in this separate area. And you still have the cache problem, > so I don't see what it buys. >
1) the stack can be execute protected, so simple buffer overflow exploits will be detected. On i386 one can use segment register to make stack non-executable and still use trampolines 2) On machine with separate code and data areas trampolines can be in (writable) code space. Of course it does not help if all code space in non-writable. 3) One limits contention between code and data cache during calls. Of course cost of generating trampoline may be slightly higher, but the cost of call is likely to be lower. Even for for generation, one can limit number of `mprotect' call from one per tramoline to one per page (which is likely to be much smaller). 4) One gets extra functionality (partial application), which may significanlty reduce need for pointers to nested functions. Namely, trampolines for partial application may be re-used much easier then nested functions (which have to be regenerated when entering the scope) -- Waldek Hebisch [EMAIL PROTECTED]