|Parsing techniques email@example.com (1993-05-04)|
|Re: Parsing techniques firstname.lastname@example.org (1993-05-07)|
|Re: Parsing techniques email@example.com (1993-05-08)|
|Parsing techniques firstname.lastname@example.org (Kent Rollins) (1996-11-26)|
|Re: Parsing techniques email@example.com (Scott Stanchfield) (1996-12-01)|
|Re: Parsing techniques firstname.lastname@example.org (1996-12-01)|
|Re: Parsing techniques email@example.com (1996-12-01)|
|Re: Parsing techniques firstname.lastname@example.org (1996-12-01)|
|Re: Parsing techniques email@example.com (1996-12-03)|
|[5 later articles]|
|From:||firstname.lastname@example.org (Simon Huntington)|
|Organization:||SoftWare Interrupt Developments|
|Date:||Sat, 8 May 1993 16:30:59 GMT|
Ed Ipser email@example.com 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
Software Interrupt Developments. Leeds, UK.
Return to the
Search the comp.compilers archives again.