Are the criteria for Unix and PC compilers different?

[Dave White]

In article <5847 at bellcore.bellcore.com> tr at wind.UUCP (tom reingold) writes:
>How come compilers for the PC keep improving and make last year's
>obsolete while we are totally satisfied with the one on Unix?  The
>Unix ones has not been significantly changed in a long time.
>
>Is it because we want hardware access to the PC, e.g. graphics,
>keyboard, etc.?  Or is it because the PC compilers are only now
>approaching the quality and completeness of the Unix ones?
MS-DOS C compilers keep improving because of competition:  no vendor can
assume that the competition won't come out with a product that will do
something it can't.

DOS-world compilers don't exist in the same
world as Unix compilers:  there's considerable competition.  Many
were released incomplete -- they generate lousy code, or their libraries
are incomplete, or they don't support every single canonical variation
of code generation for the segmented architecture.  They might be buggy,
too.

It used to be possible to release a lousy compiler because there was no
standard for libraries and such, and because the operating system didn't
suffer from a lousy code generator or slow libraries.  Microsoft
deserves credit for bringing out a DOS compiler that accepts Unix-style
C, and that comes with a fairly complete library.  The compiler that
comes with IBM Xenix 2.0 (SCO 2.06?  it's out of date, now) generated
lousy code, but I was able to cross-compile compress 4.0 for DOS;  Turbo
C 1.5 doesn't like it!

The PC compiler vendors broke down and developed support for arcane
memory models -- even huge model, with arrays >64K bytes, which involve
a subroutine call to handle pointer manipulation.  When will they
realize that some of us really want the option of using 32-bit ints to
port Unix-born code?  Yes, the code would be slow, but that'd be better
than not having the resulting program run without weeks of debugging!
--
backstro at silver.bacs.indiana.edu