|[3 earlier articles]|
|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:||"R. L. Watkins" <RLWatkins@CompuServe.Com>|
|Date:||5 Jan 2002 01:44:36 -0500|
|References:||01-12-179 02-01-014 02-01-025|
|Posted-Date:||05 Jan 2002 01:44:36 EST|
----- Original Message -----
From: "Mark Wotton" <email@example.com>
> <GCC parser discussion>
> > "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?
It's been a while since I've dug around in ICode and disassembled
machine code for some of these languages, but for $0.02 it seems:
Languages that have to do a lot of work creating and destroying stack
frames have to do less work in the function bodies (e.g. C), and vice
versa (e.g. Lisp). Then there are the exceptions where the generated
code is more compact for both, but the language is less expressive so
you wind up having to write more of it (e.g. Forth).
It seems to even out.
R. L. Watkins
Return to the
Search the comp.compilers archives again.