BSD 9.2 [History of BSD Unix]

[Chris Torek]

In article <12285 at ncoast.UUCP> allbery at ncoast.UUCP (Brandon S. Allbery) writes:
>I have heard that Berkeley is taking the time to divide the BSD sources into
>the part that requires an AT&T license and the part that doesn't.  Which
>side will the Pascal compiler fall on?  [someone told] me ... that it
>required a modified yacc.  Is that so?  Is there a version that doesn't,
>or a way to change it so it doesn't, or a way for a non-source-licensed
>site to bring up the modified yacc?

It uses `eyacc', which is slightly hacked for error recovery, and at
the time, had larger compiled-in limits.  (It may still have larger
limits, although I believe yacc's limits were expanded in 3BSD.)  I
have reproduced below the READ_ME file and the comment from ey1.c
(which the READ_ME claims is in `y1.c').

>(This entire paragraph is irrelevant if the Pascal compiler turns out
>to have AT&T code in it.)

Probably not, but there is one small detail:  It uses the f77 code
generator, which is quite definitely derived from AT&T code.  Hence
you could make similar changes to bison (e.g.), and come up with a
working `compiler', but all it would produce would be a PCC intermediate
file.

[READ_ME:]
Copyright (c) 1980 Regents of the University of California.
All rights reserved.  The Berkeley software License Agreement
specifies the terms and conditions for redistribution.

@(#)READ_ME	5.1 (Berkeley) 4/29/85

August 28, 1977

This directory contains source for a version of yacc needed by the Pascal
parser.  The differences between this yacc and a stadard version 6 yacc
are indicated in a comment in y1.c.

Note that the standard yacc parser will not work on the tables produced
by "eyacc" and also that these changes are really useful only with
a fairly large set of error recovery routines which are part of both
"pi" and "pxp".  The routines are language independent, but the method
will only work on languages which have some redundancy in them... it is
probably ill suited for C, but would work fine in ALGOL-60, ALGOL-W,
EUCLID, LIS, SP/K, PL/1, ALPHARD, CLU, ...

Sun Apr  8 21:43:08 PST 1979

A paper describing the method used by eyacc will appear in August in the
SIGPLAN Boulder conference.

Mon May 5, 1980

The eyacc in this directory has been modified to work for
version 7.  This involved syntax fixes and changing the I/O calls
to standard version 7 calls.

[ey1.c comment:]
  /**** NB -----
   *
   * This version of yacc, known as "eyacc" has been slightly but
   * importantly modified to allow error recovery in the UNIX Pascal
   * translator "pi" and also in "pix".
   *
   * Changes here include:
   *
   * 1) Enumeration of test actions when "error" is an input token.
   *
   * 2) Change to the encoding of the action entries.  Test entries
   *    are encoded as the arithmetic inverse of the symbol being tested
   *	for.  This is an optimization that makes the parser run at the
   *	same speed even though, with error productions and enumerated
   *	lookaheads, it would normally be much slower.  Of course the
   *	same thing could be done to the regular yacc...
   *
   * 3) Different table sizes
   *
   * 4) Recognizes form feeds
   *
   * 5) Also most of the numbers for the sizes of the tables have been
   *	increased, to an extent to allow for "eyacc"ing of the Pascal grammar
   *	and of a grammar which I have for "EUCLID".
   *
   *	There seem to be subtle dependencies between the various magic
   *	numbers... I found some of them but to be safe most of the limits
   *	are very generous... for this reason "eyacc" will most likely
   *	have to run separate i/d... no matter.
   *
   *					Bill Joy
   *					Computer Science Division
   *					EECS Department
   *					University of California, Berkeley
   *					Berkeley, California  94704
   *	
   *					Office:	(415) 642-4948
   *					Home:	(415) 524-4510
   ****/
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris