parora@gpu.utcs.toronto.edu (Pavneet Arora) (06/14/88)
WATCOM seems to have come out of nowhere to be a contender in the C compiler
game. I was wondering if anyone had started using this product and had opinions
about it.
Some observations of my own:
1. I called up WATCOM to find out how good the runtime library was compared
to MS. I was told that it was fully compatible (I got the impression that
this meant that there are equivalent routines for all of MS's). Then when
I had questions about memory models, using MASM in conjunction with it
etc. I was told that someone would call me back. AND BY GOLLY THEY DID,
unlike MS who have told me the same thing at least 6 or 7 times in
the past 3 months and never bothered. Friendly, informative people.
2. According to Computing Canada and PC TECH, the editor used in their
Express C (WATCOM's version of Quick C) leaves a lot to be desired. Well
I could live with that especially since I have recently got hooked onto
Brief.
3. WATCOM C 6.5 is to come out within a couple of weeks. This was to have
a better runtime library. I didn't really pursue what enhancements this
version is to have because I haven't had a chance to play with the original.
The person I spoke with didn't seem to know whether some of the dead code
instructions that WC tripped up on in the PC TECH article were being
addressed in this version, BUT DID SAY THAT THEY WERE DEFINITELY
BEING ADDRESSED. She actually knew which instructions that WC did poorly on
Also, this release is supposed to be free to all 6.0 owners.
My god, a developer that not only reads what other people have to say
about their stuff but actually listens.
Looks like they looked at where MS was tripping up i.e. support, bugs etc.
and tried to offer something better.
pavneet arora
parora@utgpuroy@pyr.gatech.EDU (Roy Mongiovi) (06/15/88)
I ordered WATCOM C 6.0 about a month and a half ago, and sent it back
a week later. Let me start by saying that the folks at WATCOM were
VERY cooperative - I really wish I could have stuck with their compiler.
I'm using the Microsoft C 5.0 compiler today, and I still believe in
the reasons that I chose it, but I really wish my decision could have
been different.
Anyway, Microsoft seems to have far and away the most complete library.
WATCOM doesn't have nearly as many functions for interfacing with MSDOS
(but it seems kind of reasonable that MSC is better considering who
wrote DOS).
I have an old XT, and WATCOM is SLOW SLOW SLOW. A 2000+ line program
required 15 minutes to compile. Also, WATCOM does its optimizations
in memory, it doesn't use disk files. If you have a function that is
more than 100-200 lines long, the compiler will issue an insufficient
memory error message and the optimizations will be degraded. It still
generates code, but since its big feature is register allocation if it
runs out of memory the generated code is much worse. There is a large
version of the code generator which uses all available memory (rather
than the 64K that the normal one uses), but I found that on my 640K
machine it didn't help at all (and it compiled at least twice as slowly).
I don't like having to recode my programs to make the compiler happy.
A major gripe for me is that you absolutely HAVE to convert your program
to ANSI-C (at least to some extent). If you use the old-style C function
declarations (if you have no function prototypes), WATCOM passes arguments
on the stack (the standard way), but if you DO have function prototypes
it passes arguments in registers. This would be fine for the functions
in your program - no prototype would work the Microsoft way, with proto-
type would work the WATCOM way - but all the library routines expect
their arguments in registers. If you don't "#include <malloc.h>", don't
expect to call malloc; your program will pass the number of bytes to
allocate on the stack, and the library routine will expect it to be
in AX. So you at the very least have to look through your code and
add in all the new ANSI-C include files needed to access the library
routines.
I did find a couple of bugs, but nothing nearly as bad (or damaging)
as the numerous code generation bugs in MSC 5.0. And given the
attitude exhibited by WATCOM I'd expect them to fix the bugs in a
timely fashion (unlike some other companies I can think of).
On the plus side, it really does generate fast code. The executables
are much smaller than MSC. It has some really powerful (and, of course,
terribly cryptic) pragmas that you can use to control what registers
are used to pass arguments to a function, what registers are used and
not restored by the function, and what instructions are used to invoke
the function. This can be used to call your own assembly routines, or
to generate inline code (unfortunately you have to do this in hex rather
than in symbolic assembly).
I didn't really mess with the Quick-C equivalent. I feel that software
must be debugged with the compiler and options with which the final
version will be compiled (we all know that code generation errors DO
exist); so the quick compilation compilers are only useful to me for
finding syntax errors.
If you have a fast enough machine, and don't mind having to do some
conversions on your existing source code, I'd recommend trying the
compiler. You can, after all, return it within 30 days for a complete
refund (a remarkably enlightened attitude that I think should be
encouraged in all vendors).
--
Roy J. Mongiovi System Support Specialist Office of Computing Services
Georgia Institute of Technology Atlanta GA 30332. (404) 894-4660
...!{allegra, amd, hplabs, masscomp, ut-ngp}!gatech!gitpyr!royttims@watdcsu.waterloo.edu (Tracy Tims) (06/26/88)
In article <5935@pyr.gatech.EDU> roy@pyr.gatech.EDU (Roy Mongiovi) writes: >A major gripe for me is that you absolutely HAVE to convert your program >to ANSI-C (at least to some extent). If you use the old-style C function >declarations (if you have no function prototypes), WATCOM passes arguments >on the stack (the standard way), but if you DO have function prototypes >it passes arguments in registers. This is not actually true. Watcom C will pass arguments in registers whether the function definitions are ANSI style or not. It passes arguments on the stack if it comes across an ANSI style varargs function. This means that all varargs functions must be declared using the ANSI style, or a pragma must be used to tell the compiler that a specific function should have arguments passed on the stack. Varargs functions break if one of these two things is not done. In general, you can make code compile correctly by adding pragmas that change any inappropriate calling conventions. The pragmas do not have to be added to the source files themselves, because there is a compiler option to force a file inclusion that isn't given as a #include in the program source. I played around with a copy of Watcom C on an IBM PC, and other than that, I have no connection with Watcom (even though I come from Waterloo!). Tracy Tims