Re: Stack frames & static predecessors

anton@mips.complang.tuwien.ac.at (Anton Ertl)
Sat, 25 Aug 2007 14:45:05 GMT

          From comp.compilers

Related articles
Stack frames & static predecessors wollenberg@web.de (Till Wollenberg) (2007-08-24)
Re: Stack frames & static predecessors torbenm@app-3.diku.dk (2007-08-24)
Re: Stack frames & static predecessors gah@ugcs.caltech.edu (glen herrmannsfeldt) (2007-08-24)
Re: Stack frames & static predecessors tk@ic.unicamp.br (Tomasz Kowaltowski) (2007-08-24)
Re: Stack frames & static predecessors bonzini@gnu.org (Paolo Bonzini) (2007-08-24)
Re: Stack frames & static predecessors gene.ressler@gmail.com (Gene) (2007-08-24)
Re: Stack frames & static predecessors anton@mips.complang.tuwien.ac.at (2007-08-25)
Re: Stack frames & static predecessors dnovillo@acm.org (Diego Novillo) (2007-08-25)
Re: Stack frames & static predecessors bobduff@shell01.TheWorld.com (Robert A Duff) (2007-08-25)
Re: Stack frames & static predecessors bobduff@shell01.TheWorld.com (Robert A Duff) (2007-08-25)
Re: Stack frames & static predecessors DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-08-26)
| List of all articles for this month |

From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.compilers
Date: Sat, 25 Aug 2007 14:45:05 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
References: 07-08-065 07-08-069
Keywords: code, Pascal
Posted-Date: 25 Aug 2007 12:15:50 EDT

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/


Post a followup to this message

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