Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| From: | John Levine <johnl@taugh.com> |
| Newsgroups: | comp.compilers |
| Date: | Tue, 6 Mar 2018 04:31:01 -0000 (UTC) |
| Organization: | Taughannock Networks |
| References: | 18-02-009 18-03-002 18-03-012 18-03-020 |
| Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="73676"; mail-complaints-to="abuse@iecc.com" |
| Keywords: | code, Pascal |
| Posted-Date: | 06 Mar 2018 00:24:45 EST |
| Cleverness: | some |
>>>>This is because displays were found to be more costly for Algol-like
>>>>languages ...
>>
>>>> IIRC the additional cost is in updating the display on calls
>>>>and returns.
I get the impression that displays describe two different things.
One is a static array that has one entry for each level of lexical
scoping. In a routine declared N levels (zero based) down, its prolog
saves the Nth entry in the display and replaces it with a pointer to
the current stack frame, and the epilog restores it. It can assume
that higher level routines have correctly set entries 0:N-1. That
seems pretty efficient. Assuming the saved pointer is at a known
location in each stack frame you can do a longjmp and unwind stacks
without too much pain.
The other is the same array, but with a copy of the current display in
each routine's stack frame. This is slower at call time but probably
faster to use on machines like S/360 without direct addressing
since the display on the stack is addressable from the frame pointer,
but static data needs to load a pointer from a constant pool. A
longjmp doesn't need anything special since stacked displays go away
when the stack frames go away.
R's,
John
Return to the
comp.compilers page.
Search the
comp.compilers archives again.