Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site drux3.UUCP
Path: utzoo!watmath!clyde!cbosgd!cbdkc1!desoto!packard!hoxna!houxm!mtuxo!drutx!drux3!vlv
From: vlv@drux3.UUCP (Vaughn Vernon)
Newsgroups: net.micro.pc
Subject: Re:Re Microsoft vs. Lattice
Message-ID: <1354@drux3.UUCP>
Date: Mon, 26-Aug-85 18:35:14 EDT
Article-I.D.: drux3.1354
Posted: Mon Aug 26 18:35:14 1985
Date-Received: Tue, 27-Aug-85 06:45:15 EDT
Organization: AT&T Information Systems Laboratories, Denver
Lines: 92

>> 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 have an extended type ahead.  Never had a problem!

>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.

Don't blame Microsoft 'C' ... blame Microsoft DOS!  To say the least
it is a hack at best(Unix stuff)!  If you want Un*x, buy Xenix!
The nice thing about MSC and Xenix is you can run the same programs on
MS-DOS and Xenix.  MSC supports relocatable objects (.obj) between
MS-DOS and Xenix.  And about all the environment space lost.  I'm
sure glad I don't have to give full path names to all of my includes,
libs etc.  This is a Unix feature.  I think you can do without them
though and just do all that "grunt work" by hand if you like.  I've
been putting up with MS-DOS for around 3 years now!


>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.


Yep!  DeSmet is real fast.  I like the DeSmet compiler.  Used it for
two years.  Microsoft doesn't claim to be fast.  But then again I
doubt that any other compiler comes close to doing all the optimization
that MS does.  I think the DeSmet compiler says ... take the line of
'C' and make it assembler.  MSC says ... take this line of 'C' and
make it into our psuedo language; then optimize; then make it assember.
This allows Pascal and Fortran and the like the be called and visa-versa
from 'C'.  And allows fast code too.

DeSmet gives you alot of freedom.  The thing that gripps me about it
though are things like _setmem().  How hard would it have been to
write it as memset() with all the variables passed in the right order?
I know I know!  Write a macro, syyyyyyyyyyyyy!


>The object >code is small and runs fast.

That's where most of it's time is spent.  Well worth the wait.

>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.

Nice feature ... I'm sure not complaining!  pushing and poping two
more registers is not too bad.  You only have to do it if you use
them.

>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.

I totally agree!  It is a 'C' compiler that allows the most Unix
like features on MS-DOS.  It does the best that could probably be done
with what there is to work with in the first place.

>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

MS-DOS limits ... not MSC!

Disclaimmer: These opinions are just that .... opinions.

				Vaughn Vernon
				AT&T ISL - Denver, CO
				ihnp4!drutx!{drux1 | drux3}!vlv