anyone played with yacc? [take two]

[Andrew Klossner]

This is a reposting of an article that went out yesterday and got
scarfed by the news bug.  Sorry about that.

	"I have a guy here at Whippany who wants to have a yacc input
	with a large number of tokens in it, but yacc barfs after 127.
	I looked through the source code and found a define for NTERMS
	to be 127.  My question is, This is a pretty suspicious-looking
	number and I am wondering if anyone has experimented with it
	and found out how it interacts with the other defines in that
	section of the file 'dextern' and also if there is any garbage
	in the code that would screw up as a result of increasing
	NTERMS to something like 255. (i.e., is there any funny
	bit-masking, etc. that would blow up)."

We had to do this to implement ANSI Basic, which has *lots* of
productions, terminals, and nonterminals.  I changed the relevant
portion of "dextern" to the following:

# define ACTSIZE 24000 /* was 12000 */
# define MEMSIZE 24000 /* was 12000 */
# define NSTATES 3000 /* was 750 */
# define NTERMS 400 /* was 127 */
# define NPROD 1500 /* was 600 */
# define NNONTERM 600 /* was 300 */
# define TEMPSIZE 3000 /* 1200 */
# define CNAMSZ 10000 /* was 5000 */
# define LSETSIZE 800 /* was 600 */
# define WSETSIZE 800 /* was 350 */

I had no problem as long as I obeyed the following comment, which
occurs later in "dextern":

	/* relationships which must hold:
	TBITSET ints must hold NTERMS+1 bits...
	WSETSIZE >= NNONTERM
	LSETSIZE >= NNONTERM
	TEMPSIZE >= NTERMS + NNONTERMs + 1
	TEMPSIZE >= NSTATES
	*/

Caveat: don't bother trying this if you have 64k processes.  The
resulting a.out file has 400k of BSS space.

  -- Andrew Klossner   (decvax!tektronix!orca!andrew)      [UUCP]
                       (orca!andrew.tektronix at rand-relay)  [ARPA]