|Desperately seeking PD lex source email@example.com (1990-11-26)|
|Re: Desperately seeking PD lex source firstname.lastname@example.org (1990-11-28)|
|Re: Desperately seeking PD lex source L.Parkes@comp.vuw.ac.nz (1990-12-03)|
|Re: Desperately seeking PD lex source markz@ssc.UUCP (1990-11-30)|
|From:||L.Parkes@comp.vuw.ac.nz (Lloyd Parkes)|
|In-Reply-To:||email@example.com's message of 28 Nov 90 11:26:55 GMT|
|Organization:||Dept. of Computer Science, Victoria Uni. of Wellington, NZ.|
|Date:||3 Dec 90 11:09:42|
In article <windy.659791615@strange> firstname.lastname@example.org (Andrew John Stuart Miller) writes:
>I am looking for a standard PD lex as C source including its library....
>[I haven't seen any other free lex than flex. What's wrong with flex?
I work With Michael. The problem is that flex complies under MINIX-PC
version 1.5.10, but crashes due to a serious lack of address space
(64K text, 64K stack and data!?!)
I have managed to get flex going under MINIX-PC version 1.5.10. It
handles my pascal.l file ok. I did have to go through flexdef.h and
reduce all the #define sizes by an order of magnitude. This doesn't
reduce your memory requirements by an order of magnitude, it does
however give flex much finer granularity when allocating memory. I
also reduced the hash tables sizes from 101 entries to 37. They could
be made smaller. Removing the #define for eight bit scanners at the
top of flexdef.h also helps.
All this reduced the BSS segment size from 16k to 8k. (Sorry my PC
with the actual numbers on it is at home).
The big problem is the DATA segment is 24k. This is the static data
used by the parser. The Minix version of Clunie (?) YACC seems to
produce slightly less data. You just have to edit y.tab.c so that
yylval is no longer defined as extern. Otherwise flex fails to link.
I found that the -v option produces lots of useful information about
how much memory flex takes to generate your scanner.
Return to the
Search the comp.compilers archives again.