Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!purdue!gatech!gitpyr!roy From: roy@pyr.gatech.EDU (Roy Mongiovi) Newsgroups: comp.sys.ibm.pc Subject: Re: WATCOM C 6.0 - soliciting opinions, posting a few of my own Summary: I tried it for a week and sent it back Keywords: C, MS C, QuickC Message-ID: <5935@pyr.gatech.EDU> Date: 15 Jun 88 16:57:43 GMT References: <1988Jun13.235444.22510@gpu.utcs.toronto.edu> Organization: Georgia Institute of Technology Lines: 66 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 ", 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!roy