peterr@utcsrgv.UUCP (Peter Rowley) (10/17/83)
I've been teaching some second year CS students about block-structured languages and covered static links vs. displays. When two mechanisms like this coexist, one expects to find a tradeoff between them, but I am at a loss to explain the tradeoff (fortunately, the students didn't ask!). As far as I can tell, a display takes only slightly more space (one address per lexical level (the static link in the activation record is replaced by the old display entry that the invocation set)) and is always faster. So, what is the advantage to static links that I'm missing, or why are they ever used? Non-technical reasons are welcome. peter rowley, University of Toronto Department of C.S., Ontario Canada M5S 1A4 {cornell,watmath,ihnp4,floyd,allegra,ubc-vision,uw-beaver}!utcsrgv!peterr {cwruecmp,duke,linus,decvax,research}!utzoo!utcsrgv!peterr
mark@cbosgd.UUCP (Mark Horton) (10/18/83)
One advantage to static links is that, if you decide to put displays and/or links in registers (a very reasonable way to do it), if you use static links you need only 2 registers (global and static links), but if you use displays you must allocate N registers, where N is the deepest procedure nesting you can handle (or that occurs in the program, if your runtime system knows about the specific program).
kurt@fluke.UUCP (Kurt Guntheroth) (10/19/83)
[ Why are displays any better/faster/different than static links? ] If your machine supports the right addressing modes, uplevel addressing is faster with a display than it is with a static link. To get to the activation record of the procedure n lexical levels above the current function activation, you must perform n levels of indirection through the static link. With a display, you simply indirect (once) through the display at the lexical level you want. -- Kurt Guntheroth John Fluke Mfg. Co., Inc. {uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!kurt
whm@arizona.UUCP (Bill Mitchell) (10/20/83)
I believe that the primary advantage of static links is that they are easier to implement and understand. This advantage is probably only of worth from a pedagogical standpoint and thus one would hope to see displays used in "real" language implementations. The need for displays (or static links) is one of the several obvious disadvantages of "block-structured" languages. Bill Mitchell whm.arizona@rand-relay {kpno,mcnc,utah-cs}!arizona!whm
bhaskar@fluke.UUCP (K.S. Bhaskar) (10/21/83)
I found displays to be much easier to understand than static links (many years ago, I had to work through a complicated example to finally convince myself that they work). As I see it, the only advantages of static links are (a) no limit to the nesting of scope and (b) practicality. The first is obvious. For the second, most programs tend to access mainly locals and globals, most computers have a limited number of registers to expend on displays and have efficient access to locals on the stackframe, so static links tend to be quite sufficient. Personally, after reading an article (I think it was by David Hanson a couple of years ago), I became a convert to the idea that nested scoping is harmful. Besides, it doesn't solve any of the real problems in programming -- I find issues like classes, dynamic storage allocation, run-time binding, etc. to be far more important in programming than static scoping. One advantage of displays over static links not mentioned earlier is in debugging a compiler that generates code that causes a program to throw up all over itself and its stack. {allegra,lbl-csam,microsoft,sb1,uw-beaver}!fluke!bhaskar
mark@umcp-cs.UUCP (10/21/83)
Displays also have a slight runtime cost over static links during subroutine call/return, and require the compiler developer to know how to use them. -- spoken: mark weiser UUCP: {seismo,allegra,brl-bmd}!umcp-cs!mark CSNet: mark@umcp-cs ARPA: mark.umcp-cs@CSNet-Relay
chip@dartvax.UUCP (10/21/83)
To be brief, displays are better if you expect many references to variables outside the current scope; other ways are better if such references are rare. The problem with displays is that they require some amount of work for every procedure call and return. Analysis has shown that most programs use only local variables and global variables--variables declared in some intermediate nesting are seldom referenced. Probably the most efficient scheme to date is Tanenbaum's, which keeps only a local and global stack frame pointer; other frames are accessible through a static link. Modern optimizing compilers rarely use the display mechanism, since procedure calls are heavily used in current programming practice, and must be quite fast. See: "Implications of Structured Programming for Machine Architecture", A.S. Tanenbaum, CACM, March 1978. chip elliott ....decvax!dartvax!chip