Re: Object-oriented compiler construction: ideas?

Darius Blasbans <darius@phidani.be>
8 Jun 1996 18:34:16 -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)
Regarding OO Compiler Implementation p.froehlich@amc.cube.net (1996-06-21)
Re: Object-oriented compiler construction: ideas? darius@phidani.be (Darius Blasband) (1996-06-21)
Re: Object-oriented compiler construction: ideas? rwatson@CAM.ORG (Richard Edward Watson) (1996-06-23)
[11 later articles]
| List of all articles for this month |

From: Darius Blasbans <darius@phidani.be>
Newsgroups: comp.compilers
Date: 8 Jun 1996 18:34:16 -0400
Organization: PHIDANI Software, Bruxelles, Belgium
References: 96-06-010
Keywords: OOP

Oliver Plohmann 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.


You can even take this idea further by having a NonTerminal root
class, a Statement class derived from NonTerminal, an IfStatement
class derived from Statement, etc...


You can then have semantical analysis and code generation methods
defined as virtual (deferred) in the intermediate classes, and
redefined in the leafs.


You are entirely right when stating that this approach would
reduce complexity. It does match whet we gained from our own
experience in the field.


>
> 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.


In practice, with modern environments, this seldom is an issue.
Our YAFL compiler is entirely built upon this construction, and
it happens to work just fine. At least, the gain in terms of
abstraction is considerable and worth the memory consumption,
IMHO. I also believe that there is more to gain in terms of
performance when dealing directly with the parse tree at a very
high level than by handling bits and bytes casted onto pointers
to structures referring to sets of unions with trees.


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


We also applied a similar scheme to a complete PL/1 source code
analysis project, and the results where excellent, specially
when considering the complexity of the language.


Regards,


Darius


--


Post a followup to this message

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