Re: Stack frames & static predecessors

Robert A Duff <>
Sat, 25 Aug 2007 15:50:34 -0400

          From comp.compilers

Related articles
[2 earlier articles]
Re: Stack frames & static predecessors (glen herrmannsfeldt) (2007-08-24)
Re: Stack frames & static predecessors (Tomasz Kowaltowski) (2007-08-24)
Re: Stack frames & static predecessors (Paolo Bonzini) (2007-08-24)
Re: Stack frames & static predecessors (Gene) (2007-08-24)
Re: Stack frames & static predecessors (2007-08-25)
Re: Stack frames & static predecessors (Diego Novillo) (2007-08-25)
Re: Stack frames & static predecessors (Robert A Duff) (2007-08-25)
Re: Stack frames & static predecessors (Robert A Duff) (2007-08-25)
Re: Stack frames & static predecessors (Hans-Peter Diettrich) (2007-08-26)
| List of all articles for this month |

From: Robert A Duff <>
Newsgroups: comp.compilers
Date: Sat, 25 Aug 2007 15:50:34 -0400
Organization: The World Public Access UNIX, Brookline, MA
References: 07-08-065 07-08-069 07-08-073
Keywords: code, Pascal
Posted-Date: 26 Aug 2007 10:18:52 EDT (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

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

Post a followup to this message

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