|PCODE Interpereters 101 firstname.lastname@example.org (Carl Dawson) (1999-01-22)|
|Re: PCODE Interpereters 101 email@example.com (Dwight Hughes) (1999-01-23)|
|Re: PCODE Interpereters 101 firstname.lastname@example.org (1999-01-31)|
|Re: PCODE Interpereters 101 email@example.com (Tom Lane) (1999-02-03)|
|Re: PCODE Interpereters 101 firstname.lastname@example.org (1999-02-05)|
|Re: PCODE Interpereters 101 email@example.com (1999-02-05)|
|Re: PCODE Interpereters 101 firstname.lastname@example.org (Chris F Clark) (1999-02-10)|
|Re: PCODE Interpereters 101 email@example.com (Sam Roberts) (1999-02-12)|
|Re: PCODE Interpereters 101 firstname.lastname@example.org (Kevin B. Smith) (1999-02-15)|
|Re: PCODE Interpereters 101 email@example.com (Chris F Clark) (1999-02-15)|
|[4 later articles]|
|From:||Tom Lane <firstname.lastname@example.org>|
|Date:||3 Feb 1999 23:51:59 -0500|
|Organization:||Netcom Online Communications Services|
email@example.com (Scott Amspoker) writes:
> One interesting aspect of P-code is the manner in which it handled the
> lexical nesting of procedures. Rather than use a "display" (an array
> of frame pointers each corresponding to a lexical level), each stack
> frame contained both a "static link" and a "dynamic link" to previous
> stack frames. The dynamic link was identical to the typical C method
> of pushing the old frame pointer when creating a new frame (i.e. it
> pointed back to the previous stack frame). The static link pointed
> back to the previous stack frame for the next outer procedure
> lexically containing the current procedure.
Right; this was a popular implementation for a lot of Pascal systems,
not only P-code. I don't think it was original with Pascal, either.
> I always felt that P-code's static links weren't a very efficient way
> to handle the problem. The PUSH and POP instructions (LOAD/SAVE,
> whatever) contained the lexical level of the variable as well as its
> offset within its stack frame. For "global" variables and variables
> in the current frame, it was reasonably efficient. However, for
> variables somewhere in between, the engine had to follow the static
> links the necessary number of steps to locate the desired frame.
It's been about twenty years since I looked at this carefully, but the
tradeoff you have to make here is the frequency of nonlocal variable
references vs. the frequency of procedure calls. Static links are
cheaper to update at procedure call & return than a "display" array
is; moreover they can be optimized away entirely for outermost-level
procedures. A display array allows cheaper access to more-than-one-
level-out nested local variables, but it offers no advantage for local
variables, global variables, or one-level-out nested locals.
Now maybe the programming styles I'm used to are hopelessly
troglodyte, but I've seen darn few programs other than
recursive-descent compilers that even *have* two-level-nested
procedures, much less programs in which such procedures' access to
their grandparents' locals are so frequent as to be worth improving at
the cost of a slowdown in all procedure calls.
I think the only reason display-style implementations were ever
popular at all is that Wirth's Pascal book described doing it that
way; for most practical purposes static link is superior.
regards, tom lane
Return to the
Search the comp.compilers archives again.