michael@stb.UUCP (Michael) (08/05/88)
In article <62170@sun.uucp> swilson@sun.UUCP (Scott Wilson) writes: > >> Is Bison any better ... > >My main complaint with Bison was that both the source for Bison (last I >looked) and the parser it produces rely on alloca - a method for allocating > >available (the manual page states: "alloca() is both machine- and >compiler-dependent; its use is discouraged"). I had a rather protected > >replies I recieved was that it is "impossible" to write code that is worth >anything without taking advantage of nifty features like alloca. I >completely disagree. Actually, alloca() isn't that big of a problem. Annoyance, yes, but you can get a PD version of alloca that is nearly identical and 98%+ portable, and I've seen completely compatible subroutines for ibm's, 68K's, pdp's, etc. What really gets me in all the FSF software I've looked at is... "Memory is cheap, and always will be. If they don't have at least 8 megs of virtual space with reasonable performace times, they don't count". The C compiler takes 500K+ ==== The C preprocessor takes up rediculous amounts of memory (200K+) for something the standard preprocessor does in 50K. Why? They want to keep everything in memory. They want to keep everything in memory. And, they want to keep everything in memory. (As in: Well, we need 2 more bytes of memory, so call realloc(). Realloc() cant get it from free space, so call sbrk() for the full amount, then copy it there. Repeat as needed.). Of course, it does have some benefits. You can preprocess the recursion winner of the C contest in finite time. : --- : Michael Gersten uunet.uu.net!denwa!stb!michael : sdcsvax!crash!gryphon!denwa!stb!michael : What would have happened if we had lost World War 2. Well, the west coast : would be owned by Japan, we would all be driving foreign cars, hmm...
cudcv@warwick.ac.uk (Rob McMahon) (08/08/88)
In article <10501@stb.UUCP> michael@stb.UUCP (Michael) writes: >Actually, alloca() isn't that big of a problem. Annoyance, yes, but you >can get a PD version of alloca that is nearly identical and 98%+ portable, >and I've seen completely compatible subroutines for ibm's, 68K's, pdp's, etc. If this is the same alloca() that Gould supply with their Unix, UTX-32, it has big problems with the GNU software. When you call this version, it frees any memory that was allocated from further up the stack. Quite often, though, it is called repeatedly at the same level, and the memory is never freed, as in: for (long loop) { ... func (); } func () { alloca (much memory); ... } Compiling the gcc parser using this alloca, the compiler ran out of swap space space and died. (We had ~40M swap space, and there was one other large (10M) job running and not much else.) Rob -- UUCP: ...!mcvax!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick ARPA: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
shankar@hpclscu.HP.COM (Shankar Unni) (08/09/88)
> ............................................. I had a rather protected ^^^^^^^^^ > mail war with several people associated with Bison and/or FSF regarding > this. Protected? By an asbestos suit, maybe? :-) ("The flames! The flames! Aaaarrgh! (Gasp!)") -- Shankar.