|advice needed re: parsing C decl syntax toronto.edu!tarvydas@csri (Paul Tarvydas) (1986-12-06)|
|Re: advice needed re: parsing C decl syntax harvard!rutgers!seismo!rochester!ken (SKY) (1986-12-08)|
|Re: advice needed re: parsing C decl syntax ihnp4!tektronix!tekchips.TEK.COM!stevev (Steve Vegdahl) (1986-12-09)|
|Re: advice needed re: parsing C decl syntax ihnp4!bobkat!pedz (Pedz Thing) (1986-12-10)|
|Re: advice needed re: parsing C decl syntax firstname.lastname@example.org (1986-12-10)|
|Re: advice needed re: parsing C decl syntax ihnp4!utzoo!henry (1986-12-16)|
|Cc:||(Paul Tarvydas) csri!toronto.edu!tarvydas|
|Date:||09 Dec 86 09:12:14 PST (Tue)|
|From:||Steve Vegdahl <ihnp4!tektronix!tekchips.TEK.COM!stevev>|
Paul Tarvydas writes:
>I'm still reluctant to use a straight LALR table parser for reasons of
>(ahem) efficiency. Things like expressions & statements are wonderful
>candidates for recursive-descent.
>Has anybody successfully married LR parsing with recursive-descent
>techniques? Are there any other clean tricks/techniques I could use?
At the most recent Compiler Construction Conference (SigPlan notices,
July 1986), Thomas Pennello presented a technique for "compiling" the
parse-tables directly into (assembly) code, which apparently speeds up
the parsing process by a factor of 6-10.
>[But I really don't see the point. Yacc certainly has its problems, but
>excessively slow parsing has never seemed to be one of them. -John]
In his conclusions, Pennello also echoes this opinion:
"Trying to speed up an LR parser may seem like beating as dead
horse, since LR parsers are already reasonably fast."
Still, I think the paper is worth reading.
Computer Research Lab
Return to the
Search the comp.compilers archives again.