Re: Q: How to preserve symbol table info through multiple pass compilation?

> > I originally preserved the symbol table by saving the contents for a
> > specific scope at the appropriate places in the parse tree, but this
> > is giving me problems when I want to insert something new into the
> > symbol table after the initial pass through the parse tree. I am
> > playing around with the idea of representing the symbol table as a
> > tree of scopes, with nested scopes being children of the scope they
> > are nested in. This, however, gives me a problem with constructs like
> > the following:
> >
> >
> > void foo () {
> > ...
> > }
> >
> > int x;
> >
> > void boo() {
> > ...
> > }
> >
> > 'x' should be visible to boo but not foo even though they have the
> > same parent scope.


One way to handle this is by indexing declarations in their containing
scope. In the above example, the first or outermost scope would be a
symbol table with three declarations. The symbol for foo could be
marked with an index of 1, x with 2, and boo with 3.


While passing through the parse tree, you would always maintain a
stack of symbol tables corresponding to the scopes you were currently
inside. >From the index of the declaration (symbol) associated with
the current scope, you could then determine which other declarations
were visible from the parent scope.


For example, while "inside" foo() you would know that you could only
"see" declarations in the outer scope with indices less than foo's
index of 1. Since x has an index of 2 it would not be visible. While
inside boo() you would be able to see x because x's index, 2, is less
than boo's index of 2.


This indexing can be used for lookups in an arbitrarily deeply nested
scope stack from any point in the parse tree (useful if your 'C'
supports nested functions). It can be used to easily re-create the
visibility state at any point in the program.


To address the requirement of adding new symbols into a symbol table
after the initial pass, you could simply use an indexing stride of
greater than 1. For example, foo() could be 100, x 200, and boo()
300, allowing for up to 99 additional symbols to be inserted between
any 2 given declarations.


-Bruce Duncan (bduncan@tiac.net)
--

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