Re: C++ parsing : what's new ?

mrak@hons.cs.usyd.edu.au (Mark Wotton)
4 Jan 2002 00:11:23 -0500

          From comp.compilers

Related articles
[2 earlier articles]
Re: C++ parsing : what's new ? loewis@informatik.hu-berlin.de (Martin von Loewis) (2001-12-22)
Re: C++ parsing : what's new ? tnixon@avalanchesoftware.com (Travis Nixon) (2001-12-29)
Re: C++ parsing : what's new ? pfroehli@ics.uci.edu (Peter H. Froehlich) (2001-12-29)
Re: C++ parsing : what's new ? gwyn@thislove.dyndns.org (2002-01-03)
Re: C++ parsing : what's new ? dr_feriozi@prodigy.net (SLK Parsing) (2002-01-03)
Re: C++ parsing : what's new ? zackw@panix.com (Zack Weinberg) (2002-01-04)
Re: C++ parsing : what's new ? mrak@hons.cs.usyd.edu.au (2002-01-04)
Re: C++ parsing : what's new ? RLWatkins@CompuServe.Com (R. L. Watkins) (2002-01-05)
Re: C++ parsing : what's new ? thp@cs.ucr.edu (2002-01-28)
| List of all articles for this month |

From: mrak@hons.cs.usyd.edu.au (Mark Wotton)
Newsgroups: comp.compilers
Date: 4 Jan 2002 00:11:23 -0500
Organization: The University of Sydney, Australia
References: 01-12-179 02-01-014
Keywords: C, parse
Posted-Date: 04 Jan 2002 00:11:23 EST

On 3 Jan 2002 16:37:58 -0500, SLK Parsing posted:
>> 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.
>
> Just to clarify, the main comparison here is between top-down and
> bottom-up parsing. Top-down is somewhat faster because more of the
> runtime work is encoded in the grammar. The trade off is its weaker
> recognition ability.
>
> From Fischer & LeBlanc "Crafting a Compiler with C", page 120:
>
> "Since the LL(1) driver uses a stack rather than recursive procedure
> calls to store symbols yet to be matched, the resulting parser can be
> expected to be smaller and faster than a corresponding recursive
> descent parser."


This is only relevant if the language you're writing the parser in
makes function calls as expensive as C does, though, right? Would it
be fair to assume that languages that optimise function calls heavily
(say, lisps and functional languages) are likely to have equivalent
performance for an LL(1) driver and a recursive descent parser?


mrak


Post a followup to this message

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