Related articles |
---|
berkeley yacc on DOS lhhuang@jeeves.waterloo.edu (1992-07-11) |
Re: berkeley yacc on DOS epang@sfu.ca (1992-07-13) |
berkeley yacc on DOS wolff@alpha.ces.cwru.edu (Francis Wolff) (1992-07-13) |
Re: berkeley yacc on DOS tom@smart.bo.open.de (1992-07-14) |
berkeley yacc on DOS jar@cheops.HQ.Ileaf.COM (1992-07-20) |
Re: berkeley yacc on DOS moss@cs.umass.edu (1992-07-21) |
Newsgroups: | comp.compilers |
From: | jar@cheops.HQ.Ileaf.COM (Jim Roskind x5570) |
Organization: | Compilers Central |
Date: | Mon, 20 Jul 1992 18:17:30 GMT |
References: | 92-07-024 |
Keywords: | yacc, MSDOS |
Questions were asked about porting byacc to MSDOS. Several responses were
posted, but none (that I saw) mentioned the pivotal problem:
In addition to the porting required to fix GETBIT and SETBIT macros, byacc
will call malloc (potentially) with very large values. Alas, under DOS,
malloc calls are restricted to 64K. The bad news is that such requests
are silently truncated (during calculation) to a number under 64K (an
"int" under DOS is only 16 bits), and things go really badly from there
on.
To crudely correct (a.k.a., port) the program, such points of calculation
must be identified, the intermediate vars must be upgraded to size
"unsigned long", and the calls to malloc/realloc must be adjusted to use
the corresponding huge model calls. It turns out that there is one major
point of contention, and it involves allocation of a huge bit array. In
addition, pointers to such allocated regions must be typed "huge" so that
they can properly step through the array.
I have done the port in the past, but I don't have a port of the current
version. The easy way to test a port is to try to yacc my C++ grammar
(see the FAQ list for this news group). It will easily blow out (a.k.a.,
crash) a simplistic port. I don't recall whether or not my C grammar is
large enough to crash such a port, but based on the prior posting, it
probably is.
Jim Roskind- Author of a YACCable C++ grammar
Independent Consultant
(407)729-4348 or (617)290-4990 x5570
jar@hq.ileaf.com or ...!uunet!leafusa!jar
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.