Re: Stack frames & static predecessors

Anton Ertl wrote:


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


Even C functions require multiple restorations, on exit to the caller.
IMO most of the current contributions lack to mention one ore more
required references, because these are already part of the stack
frames, or of equivalent data structures. I also suspect that the name
"trampoline" has/had a specific meaning in computing, allowing to jump
around in stack frames in random order, not only by sequentially
entering and leaving subroutines. (The latter opinion only is a
feeling, not an invitation to a sophisticated discussion ;-)


An exit from an "ordinary" subroutine, in a stack based machine, must
restore the prior execution address, and the stack and stack frame
pointers must be adjusted to their previous values, AKA stack
unwinding. Calling conventions can delegate these operations to
either the caller or to the callee. Structured exception handling (or
debugging...) already suggests to put all required information into
the frame, so that another (unrelated) procedure can interpret or
unwind the stack, without assistance of the owners of the stack
frames.


Local (nested) subroutines (A.B) must have means to access values in the
stack frame of their enclosing subroutine (A). Recursive invocations of
the local subroutines (A -> A.B -> A.B -> A.B...) can require more
explicit information in the stack frames, so that the "intermediate"
stack frames, resulting from recursive invocations, can be skipped in
the linear chain of frames.


Many more complications arise from local callback functions, whose
"function pointer" (A.B) is passed to anther subroutine, allowing that
subroutine to invoke the callback function in the scope of their parent
(A -> B(A.C) -> A.C). Obviously such pointers are volatile, they become
invalid after an exit from A, due to the destruction of the stack frame
of A. And as with recursive subroutines, A.B must have an explicit
reference to the stack frame of A, due to the lack of information about
the intermediate frames in the call stack, between the invocation of A
and the invocation of A.C.


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


My above considerations also apply to non-stackbased architectures,
which manage the local data (scopes, displays...) in an different way.
Static chain chasing will fail with local subroutines and indirect or
recursive calls.


DoDi

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