Re: Parsing techniques

simonh@swidev.demon.co.uk (Simon Huntington)
Sat, 8 May 1993 16:30:59 GMT

          From comp.compilers

Related articles
Parsing techniques lex@prl.philips.nl (1993-05-04)
Re: Parsing techniques ipser@solomon.technet.sg (1993-05-07)
Re: Parsing techniques simonh@swidev.demon.co.uk (1993-05-08)
Parsing techniques kentr@rollinssoft.com (Kent Rollins) (1996-11-26)
Re: Parsing techniques scotts@metaware.com (Scott Stanchfield) (1996-12-01)
Re: Parsing techniques jon@mauney.com (1996-12-01)
Re: Parsing techniques miano@worldnet.att.net (1996-12-01)
Re: Parsing techniques jlilley@empathy.com (1996-12-01)
Re: Parsing techniques icedancer@ibm.net (1996-12-03)
[5 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: simonh@swidev.demon.co.uk (Simon Huntington)
Keywords: parse, performance
Organization: SoftWare Interrupt Developments
References: 93-05-034
Date: Sat, 8 May 1993 16:30:59 GMT

Ed Ipser ipser@solomon.technet.sg writes:
>The real difference between recursive a/descent parsing and stack
>automation parsing lies in this difference, however it is stated.
>Generally, though stack automation implementations result is smaller code
>but recursive a/descent parsers usually run faster. This is why Penello
>chose to implement his in assembly, to out squeeze every possible
>millisecond of speed that he could.
>...
>How does this compare to the automatic error handling methods for LR such
>as that described by Fischer and LeBlanc? Our experience is that such
>automatic error handling is very satisfying, indeed.


The parser-driver of a stack-based LR parser can easily be converted to
hand- tuned assembly language which will be easily faster than recursive
ascent. I've already done this on FLEX generated scanners and the timings
were quite unbelievable, something like 0.65 centi-seconds to scan 64k of
C++ source into tokens!


The error-recovery you describe from Fischer/LeBlanc is really
error-repair isn't it? Error-recovery a-la yacc seemed to be 'too greedy'
and the afore mentioned 'error repair' performs much better. Implementing
error-repair must be much more difficult with recursive-ascent isn't it?
Error-recovery is simple enough because it only needs to know a
'stopping-set' of tokens and this info could be passed to a
recursive-ascent function.
--
Simon Huntington
Software Interrupt Developments. Leeds, UK.
--


Post a followup to this message

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