tsc2597@acf4.UUCP (Sam Chin) (04/18/85)
<>
Here is a review of the new Microsoft C Compiler version 3.0. This compiler
is not a repackaging of Lattice as previous versions were but a port from
their XENIX compiler. An attempt was made to use this compiler to port the
front end of the NYU ADA/Ed compiler to the IBM PC. This port had already
been done with the Lattice and Metaware compilers and I wanted to see how
much faster MSC would be. Using Lattice to port the ADA front end meant an
extensive rewriting of the code and was unsatisfactory due to our desire to
maintain a single source file for Unix and MS-DOS. We eventually were able
to do that with the Metaware (a beta test version) compiler. I will also note
here that in addition to the Lattice compiler, the Mark Williams and CIC86
compilers had sufficient bugs and problems that we gave up on them too. When
I got the compiler I did a sieve test with register variables. The times were:
Metaware Aztec 2.12 Lattice 2.12 MSC 3.0
13 10 (4.8K) 10.5 (~12K) 7 (5.8K)
MSC seems a real winner here. Stangely Realia COBOL still seems the winner
in these sieve benchmarks. Maybe all we C programmers should switch to
COBOL for true performance!
I compiled XLISP with Aztec, Lattice and MSC. Aztec and MSC required no
changes to XLISP but Lattice required a minor modification to one file. The
final code sizes were (I used maximum optimization on MSC)
Aztec Lattice MSC
38K 44K 38K
Again MSC seems to be a winner. Not everything is peachy with this compiler
though as you will read if you get to the "Bad Parts" section of this review.
Below I am listing three sections. A "Good Parts" section, a "Bad Parts"
section and a "Technical Features" section listing points about the MSC
compiler.
Good Parts
----------
1. Well implemented argc and argv functions actually expand wildcard
filenames into a list of the actual filenames.
2. They provide library routines for compatibility with XENIX (system III)
and System V Unix. The library routines seem to be extremely compatible and
they provide more esoteric include files (such as signal.h) than any other
compiler.
3. They have a cl command which does a complete compile and link and has
almost exactly the same switches as the standard Unix cc function. If you
don't like that way of using the compiler there is another root file which
uses the standard Microsoft interface (as in MASM, LINK, LIB etc)
4. They implement many optimizations (more in Technical Features section)
5. They conform with K&R and the proposed ANSI C standard.
6. Listing features include production of MASM compatible input and Assembly
Language and C source interspersed.
7. Can generate code for 8086/88, 80186/88, 80286
8. Various controls over the optimizer - favor code size, execution time,
disable aliasing or turn optimizer off completely
9. Ability to compile very large procedures and switch statements ( a
procedure with a switch statement that was 100K long. Lattice for example
can't)
10. Small, Medium and Large models. There is no large data, small code model
but in practice that offers very little advantage over the large model in
terms of execution speed.
11. Their large model uses multiple data segments with no restriction on the
interspersal of static or auto data items (unlike Lattice where all static
data has to be in a single data segment). The largest object that can be
created is 64K. They also provide the ability to mix memory models.
12. They provide a new version of LINK which automatically searches the
correct model libraries depending on how you set the compile time swithces.
13. Perhaps the best part of this package is the extensive, well written
documentation of over 800 pages. It looks typeset but from the quality of
the characters I would think that it was just printed through a laser. The
sections are divided into a User Guide (297 pages) a Language Reference
Manual (217) pages and the Library Reference Manual (400+ pages). All of
them have tables of contents and extensive indexes.
Bad Parts
1. If code is written using the 8087 libraries, they may be incompatible
across machines because they handle 8087 exceptions. On some machines the
8087 interrupt is wired to the 8259. On others it may be the Non Maskable
Interrupt. This may actually be a feature as they correct 8087 errors. As
long as you stick to IBM PC's and compatibles this isn't a problem
2. In trying to compile the ADA front end, the compiler crashed with these
messages:
Compiler error (assertion) : file @(#)MDmisc.c:1.31 line 279 source = 254
This is a compiler internal error which should never happen but it does on
two of my files. It is also impossible to correct because "line 279" above
is the same for both errors (across different files) and is evidently
garbage. We will be reporting this to Microsoft Technical support. It will
be interesting to compare the support for the various compilers we have used.
3. Will not take long uncomplicated expression such as 40 items ored
together.
4. Messages are quite typical of most C compilers. Not very informative.
Incidentally the Metaware compiler actually shows you the line on which the
error occurs and *underlines* the error.
5. It is a *slow* compiler. Slower than Lattice or Aztec but that can be
expected given the amount of optimization it does.
6. It destroyed a memory resident program (filefac)
7. It failed to chain to the linker properly when given :
cc *.obj -o xlisp
Technical Features (from IBM systems Journal)
It keeps a pool of register variables (SI and DI).
They use the same code generator that they use for their Pascal and Fortran
compilers. You can also call fortran and pascal routines
They use a parser generator and what looked like some form of attribute
grammar which is called XACC.
Optimizations: Constant Folding
Strength reduction
Type optimization
Common Subexpression Folding (although one of their
competitors told us that they disassembled MSC code and
found that they don't actually do it!)
Value Propogation
Code Generation: Basic Peephole optimizations
Some flow analysis
In conclusion, MSC is a good product - better than Lattice, MWC or CIC86 in
my opinion. It can compile large programs and produce very fast optimized
code and has support for all necessary memory models. It did however fail to
compile our ADA compiler front end and the errors seem to indicate an
large amount of conversion to get it to compile our C code (currently it can
be compiled directly with the BSD 4.2 compiler and the PC-DOS Metaware
compiler) MSC's documentation is by leaps and bounds the best in the
industry and I am sure it will be a leader in what I think will be a big "C
compiler industry shakeout" soon.
Sam Chin
ARPA: tsc2597.acf4@nyu
UUCP: allegra!cmcl2!acf4!tsc2597
A good article on this compiler for the technically inclined is "The C
programming language and a C compiler" in the IBM Systems Journal Vol 24, No
1 - 1985 by two of the people who helped design and implement MS C.