Re: Object-oriented compiler construction: ideas?

pdonovan@netcom.com (Peter Donovan)
3 Jul 1996 23:42:50 -0400

          From comp.compilers

Related articles
[16 earlier articles]
Re: Object-oriented compiler construction: ideas? cliffc@ami.sps.mot.com (1996-06-30)
Re: Object-oriented compiler construction: ideas? compres@world.std.com (1996-06-30)
Re: Object-oriented compiler construction: ideas? jdean@cs.washington.edu (1996-06-30)
Re: Object-oriented compiler construction: ideas? solution@gate.net (1996-07-01)
Re: Object-oriented compiler construction: ideas? robison@kai.com (Arch Robison) (1996-07-01)
Re: Object-oriented compiler construction: ideas? mayan@watson.ibm.com (1996-07-02)
Re: Object-oriented compiler construction: ideas? pdonovan@netcom.com (1996-07-03)
| List of all articles for this month |

From: pdonovan@netcom.com (Peter Donovan)
Newsgroups: comp.compilers
Date: 3 Jul 1996 23:42:50 -0400
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
References: 96-06-047 96-06-064 96-06-117 96-06-134 96-07-016
Keywords: OOP, parse

In the LR parser generator and compiler skeleton system we added as few
features as possible in an attempt to avoid unnecessary complexity.


One feature was the ability to generate
sets and tests for set inclusion on AST node names.
This made it possible to easily define abstract sets of information
about specific node types.


In the grammar I'd write:


%set commutes
n_plus n_minus n_multiply;


Which generated a macro "is_commutes" that yielded true or false
on set inclusion.


The AST data structures, memory pool, debug, rewriting and
traversal primitives are generic.
However, specific attributes, such as the value of a node representing
a constant or symbolic attributes of an identifier node are
dynamically assigned to a 'decoration' field of the node.


This allows for construction of generic support functions
such as traverse, debug and iterator constructs.
It also allows for easy loading and unloading of phase specific
information. Consider, an expression operator node may have language
specific type information associated with it during semantic attribution
phases, later optimization phases may require (in addition) a global
expression dictionary entry, availability information, etc..
There really is no need for global knowledge of optimization
specific attributes and given space and complexity requirements, some
very good reasons for making such attributes phase, rather than class,
specific. The same follows for code generation and so on.


The generic debug routines need to know how to interpret
and print such dynamic attribute information, but given that, it is a very
easy system to work with.


Essentially, once the problem space is framed, the representation
of a specific set of language or phase attributes is a variation on a theme.
The system also has generic models of CFG data structures etc., again
using the same ideas of a generic framework, or skeleton.


This approach has made my job as a compiler writer much easier and has proven
to be very maintainable and understandable by others, including inexperienced
developers.














--


Post a followup to this message

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