WATCOM C7.0

Good things do get better

Figure 1: A simple function that has been optimized

  Function

            const int c= 5;

            int foo (int x)
            {
            int y;
            y=2*x+c;
            return y;
            }

            int d;

            void bar( )
            {
            d= foo(d);
            }

  Code generated by Watcom C7.0

  foo_         shl        AX,1
               add        AX,_c
               ret

  bar_         mov        AX,_d
               call       foo_
               mov        _d,AX
               ret

  Compare this with:

  foo          push       BP
               mov        BP,SP
               mov        AX,[BP+4]
               shl        AX,1
               add        AX,_c
               pop        BP
               ret

  bar          push       BP
               mov        BP,SP
               mov        AX,_d
               push       AX
               call       foo
               add        SP,2
               mov        _d,AX
               pop        BP
               ret

With optimization disabled, the code generator still generates fair code, so some simple improvements must be built into the code generator on a primitive level. Without optimization, the symbolic debug information is superb. All the line numbers and local symbol information are exactly where I would expect, without quirks. Even normal optimization is easy to follow in the debugger, with the exception of loop optimization, where invariant expressions are hoisted out.

There are numerous ways to fine-tune code generation. You can use a pragma to modify function attributes, and you can specify the calling sequence in some detail (including how parameters are passed, how the call is made, how the value is returned, who clears any parameters from the stack, which registers are not preserved by the function, what name the linker will know it by, and other information). You can even have a "function" that generates a sequence of bytes (which should correspond to some meaningful assembly language) instead of a call instruction. For example, I had a function called bios_int( ) that was written in assembly language. It took four unsigned parameters and loaded them into the AX, BX, CX, and DX registers, did an INT 10h call, and returned the value from AX. With Watcom 7.0, I can define a pragma saying that int_bios receives its parameters in AX, BX, CX, DX, returns a value in AX, and generates an INT 10h instruction when the function is called instead of calling a function. In other words, the assembly language function was completely eliminated and replaced by intrinsic code generation that does the same thing.

The amount of information that can be specified by pragmas is enormous. You can fine-tune a program's performance, call functions that were compiled by a different compiler, and fix linkage problems.

One interesting feature is that you can use a pragma to specify exactly what "cdecl," "pascal," and "fortran" modifiers mean. For example, you can have cdecl mean the Microsoft C calling convention, or you could have it mean something else if you were using libraries produced for another compiler. This can be set up to use existing assembly language routines. There is one quirk, though. In large models, the DS register is used freely and does not necessarily point to DGROUP when your assembly language function is called. A compiler switch can be used to eliminate this behavior, and DS points to DGROUP throughout the program. It would be better to allow the pragma to specify that DS be loaded before the function is called.

As I said before, errors in the source are quickly found. You can even call the compiler with a switch for syntax-check only. For the most part, the check finds mistakes in the source that you would expect a modern day compiler to find, though it can miss some. Figure 2 illustrates that it did not warn me that I was passing a far pointer where a long was expected. Neither does it always catch type errors where typedefs are involved.

Figure 2: Example demonstrating how a parameter of incorrect type is passed without warning

           typedef long BIG;

           void foo (BIG);

           void bar ()
           {
           char *buf;
           foo (buf);
           }

In addition to this compiler, the package includes an Express C integrated environment compiler, though most professional programmers would rather have a regular version.

ANSI Conformance

Because the packaging proudly proclaimed "100% ANSI," I decided to delve into the conformance issue. I tried the home version of the Plum-Hall validation suite, and found that the symbol HUGE_VAL caused a linker error because, it seems, the value is actually defined in the floating point library. The library name was not included for linking, even though a variable of type double was defined and a floating point comparison was made. This shows that you might define a double variable and call printf( ), and have it not work because the printf( ) linked in was taken from the regular library. This probably would have worked on a more realistic program. I brought this to Watcom's attention, and they indicated that they'll move the symbol into the regular library. (Watcom ought to link the floating point library in if any floating point variable is defined, as the method they are using does not catch all the cases where it is needed.)

For things like the order of translation, double-slash comments, line continuation, required headers, and even trigraphs, C7.0 came through with flying colors.

While the const and volatile key words are recognized, the semantics are not all available. A direct constant variable is treated properly, but pointers to constants are not. In a case like const char *s;, the assignment *s=c; is not caught as an error. As for volatile, it does not always prevent the kinds of optimization it is supposed to. Figure 3, which is part of a const semantics test I ran, indicates that Watcom 7.0 does not implement pointers to const values.

Figure 3: This test indicated that Watcom C7.0 does not implement pointers to const values

  void f101( )
  {
  const char *const s=g;
  *s= c;//error, but allowed by Watcom
  s= p;//error
  }

I looked at the standard library and found all the standard headers. I then checked some of the more exotic aspects of ANSI-ism. The library has locale functions (probably the single most difficult thing to implement) but only the "C" locale is supported, so you can't call setlocale( ) (or if you do call it with C, it doesn't actually have to do anything!). Likewise, localeconv( ) can be a trivial function, and any functions that depend on the current locale don't have to do anything special because the locale never changes.

There are multi-byte character handling functions like mblen( ), which gives the number of bytes in the multi-byte character pointed to, and mbtowc( ), which converts a multi-byte character to a wide character. But these functions are trivial because the library does not actually support character sets that have characters comprising more than one byte. Many of the new functions (40 to be exact) are listed in the Addendum, but not in the Library Reference nor in the quick reference card.

The standard library is rich, having all the ANSI required functions and all the DOS expected functions, like FP_SEG( ) and intdos( ). Functions like _splitpath( ), _heapchk( ), and _heap-shrink( ) (which frees any unused memory back to DOS in preparation for a system( ) call) are welcome additions to this version. The library supports most of the niceties that I've encountered on other compilers with one exception: I would like to be able to automatically expand wild card file names in the argv[ ] list passed to main( ).

Wrapping It Up

Watcom 7.0's strong suit is its code generation. With its efficient calling conventions, good optimization, and powerful pragmas, it can generate tight and fast code. It has a rich library, and is a good first cut at an ANSI-conforming implementation. The linker handles overlays well and the debugger can set up complex debugging scenarios. I would be wary of the flaws in compile time error checking, though. That Watcom 7.0 occasionally misses bad parameter types and doesn't fully implement const detracts from the overall evaluation. Watcom 7.0 is worth using for the code generator if that is what is important to you.

Product Information

Watcom C7.0: requires an IBM PC/XT/AT and PS/2 and compatibles with 512K memory, DOS 2.0, or later.

Watcom C7.0/386: is exactly the same as C7.0 but (obviously) requires a 386-based machine. C7.0/386 compiles 32-bit 80386 native code. The initial release does not include a linker or debugger, although future releases will. This release does use Phar Lap DOS Extender Tools and AI Architect's OS/386. $895. Watcom Products Inc., 415 Phillip Street, Waterloo, ON N2L 3X2, Canada; 1-800-265-4555.