tneff@well.UUCP (Tom Neff) (04/12/89)
In article <10317@cit-vax.Caltech.Edu> tim@cit-vax.UUCP (Timothy L. Kay) writes: >I am aghast at the poor quality of *all* the 386 Unix's, and I am >going to be one of the first people to adopt GNU if we ever get the >chance. It might be useful if the above quoted poster gave some details here. "All the 386 Unix's"? Specifically which ones has he seen? What does "poor quality" mean here, and what symptoms of it do "all the 386 Unix's" display? Does this include SunOS? AIX? AT&T V/386? ENIX? SCO? Interactive? Bell Tech? Finally, why should we expect GNU to get "right" whatever it is that all these implementations got "wrong"? -- Tom Neff tneff@well.UUCP or tneff@dasys1.UUCP
terry@eecea.eece.ksu.edu (Terry Hull) (04/13/89)
In article <11307@well.UUCP> tneff@well.UUCP (Tom Neff) writes: >Finally, why should we expect GNU to get >"right" whatever it is that all these implementations got "wrong"? Well gcc produces the fastest code of any C compiler available for Suns, ggrep is the fastest grep available, and GNU Emacs is as feature filled and bug free as any Emacs available. With a track record like the FSF has put together, I expect their beta release will be higher quality than some other vendor's finished product. -- Terry Hull Department of Electrical and Computer Engineering, Kansas State University Work: terry@eecea.eece.ksu.edu, rutgers!ksuvax1!eecea!terry Play: tah386!terry@eecea.eece.ksu.edu, rutgers!ksuvax1!eecea!tah386!terry
peter@ficc.uu.net (Peter da Silva) (04/14/89)
In article <623@eecea.eece.ksu.edu>, terry@eecea.eece.ksu.edu (Terry Hull) writes: > In article <11307@well.UUCP> tneff@well.UUCP (Tom Neff) writes: > >Finally, why should we expect GNU to get > >"right" whatever it is that all these implementations got "wrong"? > Well gcc produces the fastest code of any C compiler... Biggest C compiler, too. The rest of their products are also code hogs... > With a track record like [that] I expect their beta release will be higher > quality than some other vendor's finished product. Depends on what you mean by 'higher quality'. If it won't at least run with a mere ("mere"!) 2 Megabytes of RAM, which is damned likely considering how much RAM gcc requires, I'd hardly call it an improvement. Remember when small was beautiful? There's no reason a good UNIX with all the functionality of OS/2 and then some shouldn't run on a standard AT, or at least a 1 Meg 386 box. I chose 2 Meg above because I've run System V on a 386 in that little ("little"!) RAM. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
plocher%sally@Sun.COM (John Plocher) (04/14/89)
+---- In article <623@eecea.eece.ksu.edu> Terry Hull writes: | +---- In article <11307@well.UUCP> Tom Neff writes: | | why should GNU get "right" whatever all these implementations got "wrong"? | +---- | Well gcc produces the fastest code of any C compiler available for | Suns, ggrep is the fastest grep available, and GNU Emacs is as feature +---- In compiler benchmarks Ken Chapin did at Microport on 386's, the ranking was generally as follows: (From memory...) Floating Point Integer Library Intensive Intensive Intensive (not Float or Int) GNU PCC GHC GHC GNU PCC PCC GHC GNU SVS SVS SVS Float tests included Mandelbrodt and other such things, Integer included calculating "e" to 1000 places... Libs is a catch all with Emacs, normal *stone benchmarks... GNU = Free Software Foundation gcc 1.31 GHC = Greenhills C 1.81 PCC = Sys Vr3.0 standard C compiler SVS = Silicon Valley Systems compiler for the 386 (Not sold by Microport) All of these compilers have their problems, NONE are really good enough for production work, although IF I had to choose, I'd go with the SVS compiler set (Includes C, Pascal, and Fortran). just my $.02 worth... -John Plocher
tim@cit-vax.Caltech.Edu (Timothy L. Kay) (04/15/89)
In article tneff@well.UUCP (Tom Neff) writes: >In article tim@cit-vax.UUCP (Timothy L. Kay) writes: >>I am aghast at the poor quality of *all* the 386 Unix's, and I am >It might be useful if the above quoted poster gave some details here. >"All the 386 Unix's"? Specifically which ones has he seen? What does >"poor quality" mean here, and what symptoms of it do "all the 386 >Unix's" display? Does this include SunOS? AIX? AT&T V/386? ENIX? SCO? >Interactive? Bell Tech? Finally, why should we expect GNU to get >"right" whatever it is that all these implementations got "wrong"? OK, I'll answer. I mispoke when I said "386 Unix's" because I was really thinking only of 386 AT clone Unix's (if that makes any sense). Now that you have me thinking about it, let me consider *all* 386 Unix's... I have used SunOS for 386i, and it has the features, but it is *far* from bug free. I tried to ray trace on several machines at once, and the machines kept crashing. It seems that Sun has a few minor bugs in their code. But don't worry, you'll won't find them unless you try to access the same server from several clients at the same time. :--). One of these years, Sun might fix it. I have used AIX. It isn't even at the point that we can use it for our work. IBM has slipped on the release date several times now. I haven't used AT&T V/386 directly, but I have used AT&T SYS/V on non-386 machines, and I am amazed at what little quality AT&T puts into their Unix product. Why are they so reluctant to take the work that Berkeley did and integrate it into their code? NIH, I guess. Anyway, it seems to me that a company can't stay in business unless they fix AT&Ts bugs before they ship Unix System V out the door. My guess is that many of the problems that I was refering to with respect to 386 Unix's is directly due to the fact that AT&T has a very bad base product. I have used Enix. They lied to me. The glossy said X Windows, Ethernet, etc., AND THEY DON'T HAVE IT. (Well, they did deliver X Windows, but it doesn't work! You can't run a text editor, or the xterm gets all screwed up. Bell Tech couldn't offer the features I needed when I talked to them last. Maybe that has changed. Nor could SCO. They aren't Sys V which is a requirement. I haven't tried Interactive, so you are right. Maybe there is hope. Tim
james@bigtex.cactus.org (James Van Artsdalen) (04/18/89)
In <3863@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) wrote: > [...] Depends on what you mean by 'higher quality'. "higher quality" means that the compiler generates code that works more correctly (in this case). GNU generates more correct code in the optimizer than PCC does. The result also happens to be smaller and faster, though the compiler itself is considerably bigger and slower. If one defines "higher quality" as meaning compiles faster, and generates smaller and faster code, then Greenhills probably wins (at least the version that uPort distributed with 3.0e). Of course, I had real trouble executing the output of that compiler. I also don't believe this to be nearly as useful as definition of "higher quality" as the correctness definition. > [...] If it won't at least run with a mere ("mere"!) 2 Megabytes of > RAM, which is damned likely considering how much RAM gcc requires, I'd > hardly call it an improvement. Depends on the definition of quality, and the importance of the relationship between the semantics of the C source and the behavior of the binary upon execution. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" DCC Corporation 9505 Arboretum Blvd Austin TX 78759 512-338-8789