Re: C Compiler in C++

>Dear colleagues -
>I am writing a complete C compiler in C++ as an academic exercise and
>I need an advice related to the design of parse tree data structure
>for C declarations.


>I organized the parse tree so that class PTN (Parse tree node) is a
>super-class for all node classes. Than, I derive nodes such as
>PTNBinaryOperation, PTNAssignment, PTNIf, PTNSequence (sequence of
>statements), etc. Please note that in this implementation a node can
>have 0..n children.




For an alternative approach, see


http://groups.google.com/groups?q=compiler+objects+colvin&hl=en&selm=74pbr0%242lo%241%40dartvax.dartmouth.edu&rnum=1


That compiler was built around treewalk classes that implemented
passes and subpasses. The base class just called Visit() at each node,
and provided a Walk() method to traverse subnodes. Derived classes
collected data and rewrote the program tree.


>However, I have no idea how to go about representing C variable
>declarations in the parse tree. The problem is that C grammar itself
>is very loose on rules for variable declarations. For example: extern
>int const unsigned volatile static foo; is syntactically correct, but
>semantically doesn't make sense. Also, int const const const const
>usigned bar; is both syntactically and semantically correct, but
>should emit a warning about multiple const qualifiers.


Since I wanted a simple, regularintermediate language, I just
represented types by more tree links threaded through the abstract
syntax tree. The list ran from a the name in a declaration back
through the declarators (*, [], (), etc) to the base type (int
long). For good measure I linked variable references to their
declarations. There's no new data structure, but there is an extra
link in every tree node.


Of course, type operations become messy, but I had this base class
that walks types...


My theory was that method lookup is powerful, and I wanted to use it
for the messy work, which wasn't the program representation but the
program translation. Of course that left me with lots of node type
switches, but they were often accomplished with tables
(e.g. describing whether an operator reads/writes/addresses its
operands).


I'd probably do it this way again unless I had a language that had
pattern-matching method calls.


--
mac the naïf

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