Re: Stack frames & static predecessors

Paolo Bonzini <bonzini@gnu.org> writes:
>> [The calling procedure passes in pointers to the stack frames of all
>> of the lexically enclosing procedures, a structure known as a display.
>> The code to create the display at each call point is tedious but not
>> complex, and the techniques have been known since Algol 60, if not
>> longer. This used to be a standard topic in compiler texts, at least
>> until the academic world switched from Pascal to C. Take a look at the
>> x86 ENTER instruction, which is specifically designed to create stack
>> frames with displays. -John]
>
>If you are passing the inner function around using a function pointer
>(or in Pascal a function parameter), this is not possible, because
>your "procedure Bar" is actually a "procedure Bar (var x: integer)" so
>to speak. Therefore, the compiler will build on-the-fly (on the stack
>likely) the executable code to "add" the initial parameter, and pass a
>pointer to the "trampoline" that it has built on the stack.


Trampolines are a variation on the normal representation of a closure
as a pair, consisting of:


1) the address of the executable code of the called function


2) pointer to the frame of the function that statically encloses the
called function (i.e., the environment of the called function), aka
the static chain pointer.


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).


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.


- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/

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