Re: Object-oriented compiler construction: ideas?

dotw@centauri.cadre.nl (Douwe van Twillert)
8 Jun 1996 18:27:20 -0400

          From comp.compilers

Related articles
Object-oriented compiler construction: ideas? op@esec.ch (Oliver Plohmann) (1996-06-01)
Re: Object-oriented compiler construction: ideas? Malcolm_Crowe@msn.com (Malcolm Crowe) (1996-06-08)
Re: Object-oriented compiler construction: ideas? Arthur.Chance@Smallworld.co.uk (1996-06-08)
Re: Object-oriented compiler construction: ideas? dotw@centauri.cadre.nl (1996-06-08)
Re: Object-oriented compiler construction: ideas? bnm@indica.bbt.com (1996-06-08)
Re: Object-oriented compiler construction: ideas? nick@an-teallach.com (Nick Rothwell) (1996-06-08)
Re: Object-oriented compiler construction: ideas? darius@phidani.be (Darius Blasbans) (1996-06-08)
Re: Object-oriented compiler construction: ideas? poe@theory.lcs.mit.edu (1996-06-13)
Re: Object-oriented compiler construction: ideas? euahjn@eua.ericsson.se (1996-06-14)
Re: Object-oriented compiler construction: ideas? kalsow@winternet.com (1996-06-14)
[13 later articles]
| List of all articles for this month |

From: dotw@centauri.cadre.nl (Douwe van Twillert)
Newsgroups: comp.compilers
Date: 8 Jun 1996 18:27:20 -0400
Organization: Cadre Technologies B.V.
References: 96-06-010
Keywords: OOP

Oliver Plohmann (op@esec.ch) wrote:
: When I first looked into a book about compilers I saw a parse tree with
: integers representing the respective keyword. I thought you could
: alternatively make up the parse tree of objects, like Statement,
: ConditionalBlock, Loop, etc. A ConditionalBlock would contain the
: condition and the respective code to be executed. Then you could put the
: knowledge of how the assembler code would look like for
: aConditionalBlock into that class. Same with the other classes to
: distribute responsabilities among objects to reduce complexity. This
: would also greatly reduce the amount of case switches.


Except for optimization, where one would use knowledge of what is inside
a branch to determine further tree transformations (Expressions are a
fine example where constant folding and add/subtract and multiply/divide
give different kinds of optimization possibilities for the same kind of
tree elements). While constructing such a compiler, you will probably
find such occurences yourself. With the current C++ standard (RTTI) these
switches could be eliminated relatively easy. (You can always resort to
your own RTTI.)


: Then I thought that kind of parser would require much more memory than
: with the traditional approach and much more function calls would have to
: be made to build the tree. At the end, only the performance of the
: compiler counts and this approach would make everything slow. So I
: forgot about the idea.


Slow? The switch is a kind of virtual call. The parser itself isn't slow
and tree transformations are easy. It isn't the fastest compiler, but
does the job adequately. If your purpose is to parse e-mail headers and
process as much as you can per second, stick to the old techniques. The
major advantage is maintainance. (It also seems to code more easily, but
that is a subjective remark.)


: Does anybody know whether that kind of techiques are being applied
: meanwhile? Wat do you think about it? Bogus or not ?


I have implemented a yacc compiler with a class based AST as part of
a trainee period. It was fun to do (my first encounter with OO) and
the level of control much larger that for compilers I had previously
made. I didn't notive any speed difference! (I know there should be,
but then, why building a compiler twice?)


--
    Douwe A. van Twillert
    Escamplaan 697
    2547 EG 's-Gravenhage
    tel: 070-3234234
    email: dotw@cadre.nl
--


Post a followup to this message

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