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