|Tools for Front End. firstname.lastname@example.org (Asheesh) (2006-02-14)|
|Re: Tools for Front End. email@example.com (Michael Tiomkin) (2006-02-14)|
|Re: Tools for Front End. firstname.lastname@example.org (Tony Sloane) (2006-02-14)|
|Re: Tools for Front End. email@example.com (Asheesh) (2006-02-17)|
|Re: Tools for Front End. firstname.lastname@example.org (Asheesh) (2006-02-17)|
|Re: Tools for Front End. email@example.com (Josef Grosch) (2006-02-17)|
|From:||Tony Sloane <firstname.lastname@example.org>|
|Date:||14 Feb 2006 17:43:42 -0500|
|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  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
 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
Return to the
Search the comp.compilers archives again.