Related articles |
---|
[3 earlier articles] |
Re: c to Pascal translators? pdbaylie@eos.ncsu.edu (Peter D Baylies) (1998-02-20) |
Re: c to Pascal translators? ssu95atc@reading.ac.uk (Tony Curtis) (1998-02-20) |
Re: c to Pascal translators? derek@knosof.co.uk (1998-03-03) |
Re: c to Pascal translators? bweinra@uswest.com (Bret D Weinraub) (1998-03-05) |
Re: c to Pascal translators? bear@sonic.net (Ray Dillinger) (1998-03-06) |
Re: c to Pascal translators? fpeelo@portablesolutions.com (Frank Peelo) (1998-03-07) |
Re: c to Pascal translators? RogerHA@aol.com (RogerHA) (1998-03-08) |
Re: c to Pascal translators? joachim.durchholz@munich.netsurf.de (Joachim Durchholz) (1998-03-12) |
Re: c to Pascal translators? albaugh@agames.com (1998-03-12) |
Re: c to Pascal translators? anton@mips.complang.tuwien.ac.at (1998-03-15) |
Re: c to Pascal translators? torbenm@diku.dk (1998-03-18) |
From: | RogerHA <RogerHA@aol.com> |
Newsgroups: | comp.compilers |
Date: | 8 Mar 1998 12:15:11 -0500 |
Organization: | Compilers Central |
References: | 98-03-068 |
Keywords: | C, Pascal, translator, comment |
"Frank Peelo" <fpeelo@portablesolutions.com> writes:
>What about local variables? as in
>
>Procedure p1;
>Var
> v1 : integer;
> v2 : boolean;
>
> Procedure p2;
> begin
> ... { v1 and v2 are visible here }
> end;
>Begin
> ...
>End;
>
>presumably p2 has to be moved to outside p1 and renamed, but the
>variables v1 and v2 cannot be moved out like that - what if procedure
>p1 is recursive?
>
>Do you make local variables into a struct, and pass a pointer to that
>when calling p2?
>
>FP
>[You could, or you could shallow bind them and make them file-scope statics.
>-John]
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. The compiler does know which
procedure each variable belongs to, because it keeps a stack of
variables which are in scope, which automatically looks after
visibility. 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.
Passing a pointer to a struct which contains the local variables
sounds more promising, because the C compiler will generate a new
stack frame for you when the procedure is invoked. I have not thought
it through in detail, but 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.
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.
BTW, could someone please explain exactly what "shallow binding" is?
Roger Abbott,
RHA (Minisystems) Ltd.
[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. You can think of it as the names hold still and the values
move. The more common compiled code approach where you rename locals
to refer to locations in the current stack frame is known as deep
binding. Both work, and have different tradeoffs. There the values
hold still and the names move. So, yes, you really can make the local
variables file scope statics if you have suitable code in your procedures.
-John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.