Re: Stack frames & static predecessors

Till Wollenberg wrote:


> I'm currently preparing for an exam in 'compiler construction' and
> wondered how the following problem is solved in real world compilers:
> if some code of an inner function ('bar') accesses a local variable
> ('x') of an outer function ('foo') how is the address (on the stack)
> of this variable determined?


If I understand your question right, it gets more complicated if
you allow what C calls function pointers and PL/I calls ENTRY variables,
in addition to recursion.


http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/ibmol004/9.1.6


has the statement regarding ENTRY data:


        "When an entry constant which is an entry point of an internal
        procedure is assigned to an entry variable, the assigned value
        remains valid only for as long as the block that the entry constant
        was internal to remains active (and, for recursive procedures,
        current)."


Also, for Fortran 2003, which finally allows both internal procedures
and procedure pointers there are many restrictions on how they can
be used. Fortran 2003 does not allow internal procedures to be
nested. It also doesn't allow them to be assigned to procedure
pointers or as actual arguments. I believe some of the restrictions
are to avoid the problems that can occur finding the stack frame.


(Though IBM for PL/I on mainframe OSs doesn't use a stack, but
instead a linked list of dynamic save areas.)


-- glen
[Good point. See subsequent note about trampolines. -John]

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