OpenWatcom

["Allan Stokes" <allan@stokes.ca>]

Hello,

I'm writing from the polygamist camp.  I've never done a project where I
compiled under a single toolchain.  I hate the idea of standing on one leg
regardless of who owns the shoe.

I used Watcom heavily starting around version 7 IIRC through to version 11
when it finally went TU.  We used it in both the PC and QNX environments.
For the most part it was excellent.  The main limitation is that it only
generates x86 code.  If there was ever another backend, I never saw it.

It started life with a superior linkage abstraction.  You could link Watcom
to anything.  The function call conventions were completely configurable,
both globally and for individual functions (using rather ugly pragmas).

The size of code generated (small) was competitive with anything from its
era.  x86 has always featured compact generated code, and Watcom was among
the best.  Code generated for size often outperformed code generated for
speed.

On the PC, size was everything, and this was probably the biggest reason so
many people used Watcom.  Even Microsoft was generating the release builds
of major applications with Watcom to reduce program size.

The stability of the code generator was excellent.  We developed in parallel
with two other compilers.  Watcom hardly ever came out on the short end of
the stick.

The Watcom C library did have some glaring weaknesses.  For example, their
first implementation of quicksort did not recurse on the small side of the
partition, so you could blow your stack rather easily.  We reported a few
instances of brain damage and it was always fixed instantly.  The library
was mostly written by co-op students so it lacked maturity in some respects
compared to the compiler itself.

Things became more difficult for Watcom as they started to focus on C++.
Their early support for templates was superb as far as it went.  With a few
very small tweaks you could actually compile the original STL from HP
successfully, and there weren't too many C++ compilers back then that could
say the same thing.

Version 10.0a was a superb C compiler, and a decent C++ compiler.  It hardly
ever bombed out.  Once I implemented the Ackermann function in templates
(heh heh) and that did elicit an "internal error" assertion (but not a hang
or a crash).  When it failed, it almost always failed gracefully.

By version 11 the lack of will internally was becoming painfully apparently.
They lost their handle on QA entirely.  Even the legendary code generation
became extremely uneven.  30% of the floating point performance vanished
from several of my key loops.  The GUI they slapped on top was almost an
insult.  You could get the job done if you closed your eyes.  The template
enhancements barely worked.

IMO cleaning up after the version 11 mess is one of the main problems that
OpenWatcom faces.  Supporting standard C++ remains a distant dream.  I don't
know what they've chosen to focus on for the first release.

The debugger always had a good reputation, but we didn't use it.  When we
had problems we went back and read our source code until the problem went
away.

gcc is written in K&R C.  Watcom is written in a more modern idiom.  The
intermediate language used at Waterloo was called MIL, machine independent
language.  IIRC it was a list of quads (dst, op, src1, src2) which was fed
into the backend generator.  I suspect that some of the modern C++
optimizations don't fit easily into this framework (type-based alias
analysis).  Works great for classless C languages though ;-)

Watcom was exceptionally good at tracking the ANSI/ISO standards.  It was
also very good at issuing diagnostics when your code was not up to snuff.
Unless you suppressed the errors, it was very picky about sloppy use of
integral types.  It was almost always worth the effort to compile clean.

The lack of a backend for other platforms would be the main concern in my
mind.  Integration of the debugging toolset could also prove to be a major
headache.  Feeding the linker is one thing; keeping the symbolic debugger
happy is another problem altogether.

There will always be a lot of userland code compiled under gcc.  ANSI does
not guarantee that binary structures are portable, and this includes binary
structures in system API calls.  Keeping all these things in sync when you
support multiple compilers is an extra-linguistic hassle.  Be careful what
you wish for.

That said, if there is a desire out there to set down another foot,
OpenWatcom is certainly worth keeping an eye on.

Allan