Re: Am I parsing this correctly? (when do I build the symbol table)

Paul Robinson <paul@paul-robinson.us>
31 May 2007 17:00:20 -0700

          From comp.compilers

Related articles
[6 earlier articles]
Re: Am I parsing this correctly? (when do I build the symbol table) gneuner2@comcast.net (George Neuner) (2007-05-19)
Re: Am I parsing this correctly? (when do I build the symbol table) 148f3wg02@sneakemail.com (Karsten Nyblad) (2007-05-20)
Re: Am I parsing this correctly? (when do I build the symbol table) ulimakesacompiler@googlemail.com (Uli Kusterer) (2007-05-20)
Re: Am I parsing this correctly? (when do I build the symbol table) chris.dollin@hp.com (Chris Dollin) (2007-05-21)
Re: Am I parsing this correctly? (when do I build the symbol table) ulimakesacompiler@googlemail.com (Uli Kusterer) (2007-05-22)
Re: Am I parsing this correctly? (when do I build the symbol table) gah@ugcs.caltech.edu (glen herrmannsfeldt) (2007-05-23)
Re: Am I parsing this correctly? (when do I build the symbol table) paul@paul-robinson.us (Paul Robinson) (2007-05-31)
| List of all articles for this month |

From: Paul Robinson <paul@paul-robinson.us>
Newsgroups: comp.compilers
Date: 31 May 2007 17:00:20 -0700
Organization: Compilers Central
References: 07-05-067
Keywords: parse, symbols
Posted-Date: 31 May 2007 23:05:23 EDT

On May 18, 12:43 am, Ryan Dary <iecc AT ryandary.com> wrote:


> Sub do_something_else( byRef i As Integer )
> i = i * 10
> End Sub
>
> Function do_something( i As Integer ) As Integer
> Dim a As Integer = i + 10
> do_something_else i
> Return a * 5
> End Function
>
> My understanding of the syntax tree is that I'm not supposed to be
> worried about the "meaning" of the code, but rather the "structure" of
> the code. So, I'm not building a symbol tree at this phase... the
> problem with that seems to be that I'm unable to make heads or tails
> of the lines of code within the function declaration.


Well, personally I'm a bit of a procrastinator, but when I've written
compilers I've always been a fan of the "do it now" philosophy, also
because I tend to like to write compilers as one pass whenever I can
get away with it. The sooner you do anything the less you have to
fuss with it and the faster you get rid of it.


Note that in the following I use "procedure" to refer to both the sub
and the function. This is so I don't have to remember which is which,
because, for the purposes of this discussion it doesn't matter whether
these are subs or functions.


So, given the above code, in the first procedure (do_something_else),
you define i as a (writable) parameter passed to you from the caller,
I would create the identifier table as soon as I see the identifier.
The variable i then becomes a kind of global variable, say an
internediate variable, so that if there is a global variable named i
the parameter overrides it,or however you would handle a parameter
variable as opposed to a local variable or a global one (if you handle
them differently).


Now, in the second procedure (do_something), what I would do is change
the name of the parameter i to something else with a name that is only
available for internal use. Now, you do a create of a local variable
named i of the same type as this internal variable that parameter i
was named to (integer in this case). Now, I would set up a "prefix
code" array or table, that says, before you write the executable code
for this procedure, you generate this code at the beginning of the
procedure, e.g. you prefix this code ahead of any code in the
procedure. And in that prefix code, I would do an assignment of
parameter i to local i (because your parameter here is non-
writable). By translating the parameter into a local variable and
copying it, you don't have to worry if the procedure trashes it or
what it does with the variable, it's a local variable, instantiated
when the procedure is invoked and is destroyed when the procedure
ends.


Now, when you get to the statement Dim a As Integer = i + 10 you
create a local variable a, and in the prefix code table, as the second
thing to do before generating any code for this procedure, is a
statement assigning the value of I+10 to a. Since the first thing in
the prefix code is to copy parameter i to local i, you're done
worrying about it.


What you could do is, to make it simpler and push the code generation
to later, is have the "prefix code" table consist of statments in the
language, and the compiler simply does this: when it reaches the first
executable line of code in a procedure, if the prefix code table is
not empty, it reads those first (until exhausted) as if the table was
a form of an include file immediately before the first line of
executable code. The compiler won't care, all it's doing is compiling
valid code, and the result provides what you need.


Now, that's how I would do it. Maybe that's not the "best" way, but
it is fairly simple - at least I think it's simple - and I like simple
ways to solve problems.


Paul Robinson - http://paul-robinson.us (My Blog)
"The lessons of history teach us - if they teach us anything - that
nobody learns the lessons that history teaches us."


Post a followup to this message

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