tcm@moscom.UUCP (Tom Maszerowski) (09/05/90)
I was wondering if anyone has had problems with yacc on 386 machines. We
are running UNIX System V/386 Release 3.2.2 from Microsoft on a 25 Mhz
386 PC. This is our target machine. We do most of our development on a
Sun4 and then copy sources over to the smaller machine to build release
software. This has not been a problem until recently when a .y file that
yacc on the Sun handles fine bombs on the 386. The output looks like
this:
conflicts: 17 shift/reduce, 89 reduce/reduce
fatal error: out of space, line 441
conflicts: 17 shift/reduce, 89 reduce/reduce
This file was originally purchased from AT&T as part of the source for
nawk and then modified. The original does make it through 386 yacc with
output like this:
conflicts: 16 shift/reduce, 79 reduce/reduce
We would like to know what space yacc is referring to here ( yes we RTFM
but it doesn't have anything on errors ). None of us here are yacc experts
so if there is something in the system we could tweek it would be a lot
easier. BTW, 386 bison handles this just fine, we can't use it due to
it's licensing requirements.
Thanks in advance.
--
Tom Maszerowski tcm@moscom.com
{rutgers,ames}!rochester!ur-valhalla!moscom!tcm
**NOTE changed addresses!!rob@dutncp8.tudelft.nl (Rob Kurver) (09/05/90)
In <2253@moscom.UUCP> tcm@moscom.UUCP (Tom Maszerowski) writes: >I was wondering if anyone has had problems with yacc on 386 machines. We >are running UNIX System V/386 Release 3.2.2 from Microsoft on a 25 Mhz >386 PC. This is our target machine. We do most of our development on a >Sun4 and then copy sources over to the smaller machine to build release >software. This has not been a problem until recently when a .y file that >yacc on the Sun handles fine bombs on the 386. The output looks like >this: >conflicts: 17 shift/reduce, 89 reduce/reduce > fatal error: out of space, line 441 >conflicts: 17 shift/reduce, 89 reduce/reduce Some yacc's for 386s apear to be compiled with rather small tables (yes, they appear to not allocate memory dynamically... heck, even the output file name is fixed!). I had this same problem a few years back with my Microport UNIX, at which time Microport was kind enough to offer a version compiled with bigger tables. I now run Esix and have no problems with the table sizes anymore. My guess is that this is your 'out of space' problem: one of the internal tables is full. Perhaps you can talk your UNIX vendor into giving you a yacc binary compiled with bigger tables. Cheers. - Rob -- Rob Kurver rob@dutncp8.tudelft.nl Computational Physics Group rob@pact.nl Faculty of Applied Physics, Delft University of Technology Beware of low-flying butterflies.
tore@ifi.uio.no (Tore Solvar Karlsen) (09/06/90)
In article <rob.652549702@dutncp8>, rob@dutncp8.tudelft.nl (Rob Kurver) writes: > > Some yacc's for 386s apear to be compiled with rather small tables (yes, > they appear to not allocate memory dynamically... heck, even the output > file name is fixed!). I had this same problem a few years back with my > Microport UNIX, at which time Microport was kind enough to offer a version > compiled with bigger tables. I now run Esix and have no problems with the > table sizes anymore. > > My guess is that this is your 'out of space' problem: one of the internal > tables is full. Perhaps you can talk your UNIX vendor into giving you a > yacc binary compiled with bigger tables. Yesteday, I ran into almost the same problem, trying to compile the last version of sc (scalc). The command "yacc -d foo.y " failed with an error message hinting about increasing some buffer space with a "-Sm#" option . Anyway, changing the command to "yacc -d -Sm10400 foo.y " made it, in this case... The "-S" option in yacc seems not to be documented in the manfile. OS: SCO unix 3.2 with development kit. Perhaps someone with more experience can give an explanation. -- Tore Solvar
staff@cadlab.sublink.ORG (Alex Martelli) (09/06/90)
rob@dutncp8.tudelft.nl (Rob Kurver) writes: ... about out-of-space problems with yacc of Tom Maszerowski ... >My guess is that this is your 'out of space' problem: one of the internal >tables is full. Perhaps you can talk your UNIX vendor into giving you a >yacc binary compiled with bigger tables. I'd guess the same. However as a fix I'd try "Berkeley yacc", which is source-distributed but freely usable (no gnu-like restrictions); I got it from Austin Codeworks on the same diskette as Bison (and, who knows, FSF may be about to change their policy on libraries...?). -- Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 45, Bologna, Italia Email: (work:) staff@cadlab.sublink.org, (home:) alex@am.sublink.org Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; Fax: ++39 (51) 366964 (work only; any time of day or night).