Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site utastro.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!ut-sally!utastro!nather From: nather@utastro.UUCP (Ed Nather) Newsgroups: net.micro.pc Subject: Re: Microsoft vs. Lattice C Message-ID: <553@utastro.UUCP> Date: Wed, 14-Aug-85 16:16:49 EDT Article-I.D.: utastro.553 Posted: Wed Aug 14 16:16:49 1985 Date-Received: Sun, 18-Aug-85 22:16:41 EDT References: <1343@drux3.UUCP> Organization: U. Texas, Astronomy, Austin, TX Lines: 52 > 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