|C++ parsing : what's new ? email@example.com (Patrice Gahide) (2001-12-20)|
|Re: C++ parsing : what's new ? firstname.lastname@example.org (Ira D. Baxter) (2001-12-22)|
|Re: C++ parsing : what's new ? email@example.com (Martin von Loewis) (2001-12-22)|
|Re: C++ parsing : what's new ? firstname.lastname@example.org (Travis Nixon) (2001-12-29)|
|Re: C++ parsing : what's new ? email@example.com (Peter H. Froehlich) (2001-12-29)|
|Re: C++ parsing : what's new ? firstname.lastname@example.org (2002-01-03)|
|Re: C++ parsing : what's new ? email@example.com (SLK Parsing) (2002-01-03)|
|Re: C++ parsing : what's new ? firstname.lastname@example.org (Zack Weinberg) (2002-01-04)|
|Re: C++ parsing : what's new ? email@example.com (2002-01-04)|
|Re: C++ parsing : what's new ? RLWatkins@CompuServe.Com (R. L. Watkins) (2002-01-05)|
|Re: C++ parsing : what's new ? firstname.lastname@example.org (2002-01-28)|
|From:||Zack Weinberg <email@example.com>|
|Date:||4 Jan 2002 00:09:35 -0500|
|Organization:||PANIX -- Public Access Networks Corp.|
|Posted-Date:||04 Jan 2002 00:09:35 EST|
Peter H. Froehlich <firstname.lastname@example.org> writes:
>On Saturday, December 29, 2001, at 10:30 , Travis Nixon wrote:
>> "Martin von Loewis" <email@example.com> wrote in message
>>> The gcc grammar is currently being rewritten, from a bison-based one
>>> to a hand-written recursive-descent parser.
>> Is there a discussion online anywhere about the reasons for doing
>As I recall the motivation is performance. The people doing the
>rewrite expect the recursive descent parser to be way faster than
>the table-driven one they have now. However, I sure would *not*
>want to write a parser like that for a grammar as hairy as
The motivations are correctness, performance, and better error
recovery, in that order.
The existing gcc grammar for C++ does not interpret all language
constructs correctly; this has been judged unfixable while continuing
to use yacc. There are already horrible kludges to get certain
constructs mostly right (look at cp/spew.c, if you want to know) that
become unnecessary with a recursive descent parser.
A hand-rolled recursive descent parser has a lot more information
accessible to it. This should permit it to make better backtracking
decisions. Bad backtracking is the major cause of bad performance in
the existing parser. It will certainly permit better error recovery.
Note that this approach is known to work - the Edison Design Group
(EDG)'s C/C++ front end uses a hand-written recursive descent parser,
and it does all the above things better than g++. As someone who's
worked on both front ends, I can also say that I found it _easier_ to
work with the recursive descent parser.
Return to the
Search the comp.compilers archives again.