Re: Tools for Front End.

Tony Sloane <asloane@ics.mq.edu.au>
14 Feb 2006 17:43:42 -0500

          From comp.compilers

Related articles
Tools for Front End. asheeshc@noida.hcltech.com (Asheesh) (2006-02-14)
Re: Tools for Front End. tmk@netvision.net.il (Michael Tiomkin) (2006-02-14)
Re: Tools for Front End. asloane@ics.mq.edu.au (Tony Sloane) (2006-02-14)
Re: Tools for Front End. asheeshc@noida.hcltech.com (Asheesh) (2006-02-17)
Re: Tools for Front End. chads_in@yahoo.com (Asheesh) (2006-02-17)
Re: Tools for Front End. grosch@cocolab.de (Josef Grosch) (2006-02-17)
| List of all articles for this month |

From: Tony Sloane <asloane@ics.mq.edu.au>
Newsgroups: comp.compilers
Date: 14 Feb 2006 17:43:42 -0500
Organization: Compilers Central
References: 06-02-102 06-02-105
Keywords: parse, tools, performance
Posted-Date: 14 Feb 2006 17:43:42 EST

> Currently I planning to write a compiler for a very complex grammaer
> and I am investigating tools.
>
> There are different tools available in the market .e.g yacc, bisson,
> gold, lemnon ,cocoR and more.
>
> The other option I am planning is writting compiler without tools so
> that we can get good performnce.


I'm not sure why you conclude that using tools yields worse
performance. There is reasonable evidence that tools can embody
efficient implementation techniques that many (most?) users are not
aware of, so the result is often more efficient than the user would
have produced. Even if the user can read up on efficient techniques
and implement them, a tool often gets you to the same point much
faster with less knowledge required. If I may be permitted a self
citation, see [1] for a study of the efficiency of generated compilers
compared to hand-coded ones.


There are many tools that enable easy creation of various kinds of
parsers (some of which you cite above). However, a more important
aspect is what other processing you plan to do. The parser usually
constitutes a fairly minor part of a full compiler, so I would advise
you to consider carefully what other tasks you plan to do (e.g. name
and type analysis, optimisation, code generation) and look at tools in
terms of the support they provide for those tasks.


On the other hand, if you plan to do mostly parsing, then there is not
much to choose between the many tools out there. Two points for
comparison that might be relevant are:


- the method used by the parser generator (e.g., bottom-up table
driven vs top-down recursive descent), some folks prefer the latter
since the generated parsers are easier to understand, although many
of us never plan to read the generated code anyway


- the target language of the generator


Tony Sloane


[1] An evaluation of an automatically generated compiler, A M Sloane
          ACM Transactions on Programming Languages and Systems (TOPLAS)
          Volume 17, Issue 5 (September 1995), 691 - 703
          http://doi.acm.org/10.1145/213978.213980


Post a followup to this message

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