V61%DHDURZ1.BITNET@cunyvm.cuny.edu (Ronald Lamprecht) (06/28/89)
Yesterday I downloaded and unshared the new Flex sources -- and I couldn't
believe it !!
All old non ANSI and compiler dependencies have been eliminated -- it compiled
without changes and whats more important the resulting version seems to be OK !
What you need is YACC to compile parse.y to parse.c/parse.h and to make some
system dependent makefile changes, that's all.
I will eliminate a bug which I detected a year ago and didn't report to the
author; add some help information, the few patches that are necessary to
compile it under TOS, and test it again with all options.
Should I post the cdiffs and parse.c/parse.h only, or the complete sources ?
Who is working on a 'restricted' PC port ? The ST sizes are:
73354 flex
>85000 , <90000 data + stack necessary to flex scan.l to scan.c
Bitnet: V61@DHDURZ1 Ronald Lamprecht
UUCP: ...!unido!DHDURZ1.bitnet!V61 Theoretische Physik
ARPAnet: V61%DHDURZ1.BITNET@CUNYVM.CUNY.EDU (Heidelberg, West Germany)hall@cod.NOSC.MIL (Robert R. Hall) (06/29/89)
Why does MINIX need YAAC? Yes I had to use the UNIX version to convert flex/parse.y in the the file parse.h and parse.c for a one time pass but now it is done I intend to work with the file parse.h and parse.c and delete the file parse.y. I was able to get flex to compile and link using the Minix C compiler but I can't get it to run, it runs out of stack space. To get it to compile I had to make several identifiers unique in the first 7 characters, otherwise the port was straight forward. MINIX> ls -l flex -rwxr-xr-x 1 hall 57492 Jun 27 07:45 flex MINIX> size flex text data bss stack memory 35344 22116 30558 12862 100880 flex MINIX> flex flex: fatal internal error memory allocation failed in allocate_array()
steve@basser.oz (Stephen Russell) (07/01/89)
In article <1568@cod.NOSC.MIL> hall@cod.NOSC.MIL (Robert R. Hall) writes: > > >I was able to get flex to compile and link using the Minix >C compiler but I can't get it to run, it runs out of stack >space. > >MINIX> size flex > text data bss stack memory > 35344 22116 30558 12862 100880 flex > >MINIX> flex >flex: fatal internal error memory allocation failed in allocate_array() As I mentioned in an earlier posting, some of the flex data can be shrunk considerably. For example, much of the bss space is in the input buffers defined in scan.c (actually, they're defined in the skeleton scanner). These could be much smaller, although this limits the maximum size of a token. There is also a state stack which chews up some space, and could be shrunk. In fact, I believe only two files are responsible for most of the bss. As well, there are various initial sizes for dynamically allocated tables defined in flexdef.h. Some of these can be shrunk, particularly as flex resizes tables as needed. Even running flex on its own scanner definition (which is quite complex) doesn't need these tables to be as large as they are. Don't give up yet. Changing a few #define's may make it squeeze in.