Re: LL(1) vs LALR(1) parsers

ddean@dynastar.cs.princeton.edu (Drew Dean)
Tue, 28 Nov 1995 22:40:18 GMT

          From comp.compilers

Related articles
[5 earlier articles]
Re: LL(1) vs LALR(1) parsers simmons@bnr.ca (steve (s.s.) simmons) (1995-11-15)
Re: LL(1) vs LALR(1) parsers parrt@parr-research.com (Terence John Parr) (1995-11-20)
Re: LL(1) vs LALR(1) parsers bill@amber.ssd.hcsc.com (1995-11-22)
Re: LL(1) vs LALR(1) parsers elliottc@logica.com (1995-11-24)
Re: LL(1) vs LALR(1) parsers jgj@ssd.hcsc.com (1995-11-28)
Re: LL(1) vs LALR(1) parsers will@ccs.neu.edu (1995-11-28)
Re: LL(1) vs LALR(1) parsers ddean@dynastar.cs.princeton.edu (1995-11-28)
Re: LL(1) vs LALR(1) parsers napi@ms.mimos.my (1995-11-28)
Re: LL(1) vs LALR(1) parsers ok@cs.rmit.edu.au (1995-11-29)
Re: LL(1) vs LALR(1) parsers mparks@oz.net (1995-11-29)
Re: LL(1) vs LALR(1) parsers jmccarty@spdmail.spd.dsccc.com (1995-11-29)
Re: LL(1) vs LALR(1) parsers pardo@cs.washington.edu (1995-11-29)
Re: LL(1) vs LALR(1) parsers CSPT@giraffe.ru.ac.za (Pat Terry) (1995-11-30)
[11 later articles]
| List of all articles for this month |
Newsgroups: comp.compilers
From: ddean@dynastar.cs.princeton.edu (Drew Dean)
Keywords: parse, LALR, LL(1)
Organization: Computer Science Department, Princeton University
References: 95-11-051 95-11-138 95-11-195
Date: Tue, 28 Nov 1995 22:40:18 GMT

Bill Leonard <Bill.Leonard@mail.hcsc.com> wrote:
>If I were in charge of a compiler project (and I have been), I'd much
>rather devote engineering resources to making the generated code better or
>the compiler faster or any of a number of other improvements than in coding
  ^^^^^^^^^^^^^^^^^^^
>a parser.


Bingo! You've just answered why recursive descent parsing is making a
comeback. I don't have the papers handy, but if you look at Ken
Thompson's paper on the Plan 9 C compiler (New C), he says (now that
the language has stablized) he'd write a recursive descent parser,
because the compiler was spending 35% - 40% of its time in the yacc
generated parser. Niklaus Wirth's Oberon compilers (and single pass
Modula-2, for that matter) are quite fast (on slow hardware, by
contemporary standards) partly because they parse quickly. (We're
talking speeds of 5 KLOC/second if I remember properly. On 1-2 MIPS
CPUs...) You may object that Wirth's compilers are not
highly-optimizing, but non-optimized compile/link times are on just
about every programmer's critical path.


--
Drew Dean
<ddean@cs.princeton.edu> http://www.cs.princeton.edu/~ddean PSTN: 609-258-1797
--


Post a followup to this message

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