9f36c7f497
In case you're wondering, the gcc-2.7.2.1 import uses this to generate code. The size of the generated code is bigger than the entire bison release, making this a saving. The bison doc is pretty good apparently.
31 lines
1.2 KiB
Plaintext
31 lines
1.2 KiB
Plaintext
From phr Tue Jul 8 10:36:19 1986
|
|
Date: Tue, 8 Jul 86 00:52:24 EDT
|
|
From: phr (Paul Rubin)
|
|
To: riferguson%watmath.waterloo.edu@CSNET-RELAY.ARPA, tower
|
|
Subject: Re: Bison documentation?
|
|
|
|
The main difference between Bison and Yacc that I know of is that
|
|
Bison supports the @N construction, which gives you access to
|
|
the starting and ending line number and character number associated
|
|
with any of the symbols in the current rule.
|
|
|
|
Also, Bison supports the command `%expect N' which says not to mention
|
|
the conflicts if there are N shift/reduce conflicts and no reduce/reduce
|
|
conflicts.
|
|
|
|
The differences in the algorithms stem mainly from the horrible
|
|
kludges that Johnson had to perpetrate to make Yacc fit in a PDP-11.
|
|
|
|
Also, Bison uses a faster but less space-efficient encoding for the
|
|
parse tables (see Corbett's PhD thesis from Berkeley, "Static
|
|
Semantics in Compiler Error Recovery", June 1985, Report No. UCB/CSD
|
|
85/251), and more modern technique for generating the lookahead sets.
|
|
(See "Efficient Construction of LALR(1) Lookahead Sets" by F. DeRemer
|
|
and A. Pennello, in ACM TOPLS Vol 4 No 4, October 1982. Their
|
|
technique is the standard one now.)
|
|
|
|
paul rubin
|
|
free software foundation
|
|
|
|
|