Re: c to Pascal translators?

For completeness, since the moderator didn't mention it,
and C.S. seems sometimes to have "Institutional Alzheimers"...


RogerHA (RogerHA@aol.com) wrote:
: "Frank Peelo" <fpeelo@portablesolutions.com> writes:


  (about locating the right "incarnation" of variables in outer
procedures)


: I don't think you can make anything static. p2 could call p1, and then
: there would be multiple instances of v1 and v2. Except for variables
: declared outside any procedure, there can always be multiple
: incarnations of any variable. Since the order of calling procedures
: can vary at run time, you have no alternative but to put all procedure
: variables on a stack as they are created.




Or copy their values, as the moderator mentions, and as I did
for a 6502 compiler, and as I'm sure has been independantly done so
many times in the last 50 years, that it is probably due for a
software patent to extort from us all... :-)


: What you have to do at runtime is descend down the stack
: until you find the first stack frame which belongs to the correct
: procedure.


...or...


: something along the line of every inner
: procedure keeping a pointer (on the stack) to the most recent
: incarnation of the variables of all the procedures which enclose it
: might work.


  Or rather, there being a pointer to the stack-frame associated with
the most recent incarnation at each "lexical level". This was/is
called a "display", and was (IIRC) one of the principle enhancements
going from the Burroughs B5x00 to B6x00 series. I used a similar
software approach in an Algol60 compiler for the CDC6x00 (integer
subset, not complete, class project, but...) to pretty good effect.


: To see how its done (at least the compiler) when you have a run-time
: interpreter to go stack frame hunting, download the free Algol-60
: compiler from http://users.aol.com/rogerha.


You don't have to do much stack-frame hunting if each
procedure bundles its variables into a _visible_ stack-frame (e.g. a
struct) and updates the display. I _know_ I shouldn't be typing on the
fly, so please any obvious gaffes, but something like:


/* All structs "smell the same", and this may be better than "void" */
struct opaque *display[max_lex_levels];


int my_level_3_routine(params) {
struct opaque *old_level_3;
struct my_vars {
/* All the locals go here */
}


old_level_3 = display[3];
display[3] = (struct opaque*)&my_vars;


.
.
.


display[3] = old_level_3;
return myvars.whatever;
}


For those who are made _really_ nervous by that fixed
allocation, I'd point out that _hardware_ displays are of fixed size,
and that typical nested procedures rarely reference variables that are
"very far" from the extremes of the display. That is, a procedure at
LexLevel 7 will rarely access variables in levels other than
0,1,6,7. One could even imagine code-generation taking advantage of
this, using a faster display- oriented approch for the common cases
and stack-walking for the unusual ones.


I'd also point out (beating the greasy spot where once was a
dead horse) that a program with a large (>5 or so?) number of
LexLevels (highly nested source) is going to be well-nigh
incomprehensible to human readers, including the author a few weeks
later. Disregard the need for clarity of your intentions at your
peril.


The moderator wrote:


: [Shallow binding is a traditional Lisp technique where variables are
: stored in fixed places, and function prolog and epilog saves and
: restores their values in anonymous stack temporaries to allow
: recursion.


Whether this or a display would be the "best" approach will
depend on many things. Obviously, it does not suffer from the "fixed
size display" problem. OTOH, some compilers (at least the widely used
gcc, up to at least 2.7) generate sub-optimal code for structures with
"knowable" fixed addresses. As usual, YMMV.


Anyway, this does re-emphasize that "old" ideas can still prove
useful :-)


Mike
| albaugh@agames.com
--

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