Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uwm.edu!psuvax1!news From: melling@cs.psu.edu (Michael D Mellinger) Newsgroups: comp.sys.next Subject: Re: Freeware and the collapse of capitalism Message-ID: Date: 3 Apr 91 06:20:04 GMT References: <9103310821.AA09756@nextasy2.eecs.wsu.edu> Sender: news@cs.psu.edu (Usenet) Organization: Penn State Computer Science Lines: 29 In-Reply-To: scott@texnext.gac.edu's message of 2 Apr 91 11:41:11 Nntp-Posting-Host: sunws5.sys.cs.psu.edu In article scott@texnext.gac.edu (Scott Hess) writes: I have to quibble on that last point. gcc is not fast. Well, yes, it is fast compared to most Unix compilers, but I mean fast compared to TurboC running on PCs. I used to have shorter compile times on old PS/2 (8086 at 10Mhz) than on the NeXT. This isn't all that bad (if it were, I'd have already begun work on the faster version :-), but it is true. Using Turbo C? How many lines of code are we talking? How well does Turbo C do once you can't keep everything in memory? BTW: If anyone out there wants to write a fast C compiler/development environment for the NeXT, give me a call. I'd help, or at the least give a list of what I want. Compilation speed is what I'm looking for - code space/speed is not such a big deal when gcc can whip that. Why not just hack GCC? Most of the compile time is spent parsing the source. I'm sure something can be done to speed up compilations. Perhaps someone could write an optimized recursive decent parser to replace the YACC routines? Alternately, drop me a line so I can see what the interest in the community is . . . and what acceptable pricing for such a beast is. I would love to see an incremental compiler for the NeXT. -Mike