Re: Stack frames & static predecessors

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:


> Trampolines are a way to compress this two-address representation into
> a single code pointer, to comply with C-inspired calling conventions
> (C functions only have the global scope as environment and therefore
> don't need a static chain pointer).


Trampolines are problematic, for a couple of reasons:


They are slow. Modern hardware requires all kinds of cache flushing,
after writing code into memory, and before executing that code. Not
only is that slow, but it's highly machine and OS dependent.


Many recent machines (windows, perhaps others?) have DEP enabled by
default. That stands for "Data Execution Prevention" or something like
that, and it is used as a security measure, which is useful for programs
written in languages like C that don't typically do array-bounds
checking. DEP prevents executing data, and therefore needs to be turned
off for trampolines to work.


I am planning to remove trampolines from the code generated by GNAT
(that's the gcc Ada compiler) in most cases. At AdaCore, measurements
show that some examples with heavy use of function pointers are 10 times
faster without trampolines. The alternative is to represent a function
pointer as a pair (address-of-code, static-link) instead of a single
address-of-trampoline-code (with the static link encoded in the
trampoline).


Of course, trampolines make perfect sense for the gcc dialect of C.
Nested functions are not allowed in C, but they are allowed in gcc, but
you don't want those nested functions to pollute standard C code.


The rules of Ada allow the compiler to know whether a given function
pointer might be pointing to a nested function, so it can choose to use
a single address-of-code versus a pair. There are no such rules in the
gcc dialect of C, so avoiding trampolines for gcc C would require ALL
function pointers to be a pair -- bad.


> Concerning displays, I don't know how calling a passed-around closure
> affects implementation that use displays. If all else fails, one can
> still construct the display from scratch from the static chain on
> calling and after returning from the closure.
>
> AFAIK displays have fallen out of use, because in most programs
> maintaining the display is more expensive than the static chain
> chasing that has to be done without the display.


Yes. I've worked on many compilers, and only one used displays. All
the rest used static links (or else the issue didn't arise, because in
languages like C there is no nesting).


- Bob

Return to the comp.compilers page.
Search the comp.compilers archives again.