vlv@drux3.UUCP (Vaughn Vernon) (08/12/85)
To: drutx!ihnp4!qantel!dual!lll-crg!seismo!rochester!rocksanne!sunybcs!kitty!peter
Subject: Re: Lattice C vs Microsoft C?
In-reply-to: your article <249@kitty.UUCP>
Microsoft can already blow the socks off of Lattice! I wouldn't
worry too much about bugs. I know of several people who have written
LARGE systems with the MSC already and have also ported code from UNIX
with it and had NOOOOO PROBLEMS! This is the most complete 'C' compiler
on the market today and Microsoft is really bringing their whole line
of development tools together. Microsoft has some real Unixteers working
on there compiler which is evident. If you have come to expect performance
from a 'C' compiler from a Unix point of view, you will be pleasantly
accommodated by Microsoft.
I personally hate Lattices' attitude tord 'C' and Unix! IE.! - try
using there so-called MAKE utility. It is simply stated ... a joke!
Lattice continues to provide all of it's users with so many bugs (new
ones at that) upon each release. What a great bargin.
The bugs that may exist in the Microsoft compiler will never be confronted
by the above average programmer and/or software project! Go ahead -
beat the heck out of it ... if you can!
Vaughn Vernon
AT&T ISL
Denver, CO
ihnp4!drutx!{drux1 | drux3}!vlvnather@utastro.UUCP (Ed Nather) (08/14/85)
> If you have come to expect performance > from a 'C' compiler from a Unix point of view, you will be pleasantly > accommodated by Microsoft. > > The bugs that may exist in the Microsoft compiler will never be confronted > by the above average programmer and/or software project! Go ahead - > beat the heck out of it ... if you can! > Vaughn Vernon Well, I've had the MSC 3.0 compiler all weekend, and managed to find a few bugs without trying very hard. I installed it on my XT as per instructions, and the first compile I tried went to never-never land and died. After a lot of futzing around, I found I had to remove a "fix" that extended my type-ahead buffer to 128 bytes, since the MSC compiler uses the (teensy) environment to point to include, lib and .h files. Apparently there was a conflict, and the compiler didn't check for one. It is the only program (including two other C compilers) that has had any trouble like this. I then learned about the fun message "Out of environment space" and spent time learning to avoid it. I next learned that the compiler is happy with (modified switchar) pathnames like /bin/include, but the linker isn't, so you have to set up your environment variable pathnames with (retch) backslashes or locate things where you don't need pathnames. If this is a Unix point of view I'll eat it, raw. By the way, it is only about 4 to 5 times slower than DeSmet C to compile and link moderate-sized programs; I guess that's good. CI-C86 is about 7 times slower. I'm not really unhappy with the compiler -- it has a lot of good features, allows excellent control of optimizing, permits binary default I/O if you need it, and helps a program to expand wild card arguments. The object code is small and runs fast. If you read the manual cover to cover, you may find out, in an obscure section about re-writing earlier assembly routines to link with the (modified) calling conventions, that two (2) register variables are supported. You can also guess that from the (re-written) version of sieve.c that comes with it -- two register variables are defined, whereas the original sieve.c didn't use them. It helps: sieve runs in 6.2 seconds with them defined, 10.6 sec without. Overall, it's better than the other 2 compilers mentioned above, but it doesn't beat them on all counts, and it still tastes a lot of MS-DOS mixed in with the Unix. WHY are the environment space and the maximum command-line argument strings so small? Were they set up for 64K machines and never changed? -- Ed Nather Astronomy Dept, U of Texas @ Austin {allegra,ihnp4}!{noao,ut-sally}!utastro!nather nather%utastro.UTEXAS@ut-sally.ARPA
peter@baylor.UUCP (Peter da Silva) (08/16/85)
> lot of futzing around, I found I had to remove a "fix" that extended my > type-ahead buffer to 128 bytes, since the MSC compiler uses the (teensy) > environment to point to include, lib and .h files. Apparently there was > a conflict, and the compiler didn't check for one. It is the only program > (including two other C compilers) that has had any trouble like this. I have had this problem before, often enough that I leave the typeahead buffer at 16 bytes & used "ced" to handle multiple commands. > WHY are the environment space and the maximum command-line argument strings > so small? Were they set up for 64K machines and never changed? Probably. It's still a bad kludge, but then so is the MS-DOS environment handling generally. -- Peter da Silva (the mad Australian werewolf) UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter MCI: PDASILVA; CIS: 70216,1076