Vitus Jensen wrote in a message to Mike Bilow:

 MB> The main reason I bought the Watcom compiler is because it is the 
 MB> only modern compiler with 16-bit OS/2 support, which is 
 MB> important for OS/2 device drivers. That would be worth the 
 MB> money to me regardless of any Windows support, so it places 
 MB> me in a fairly unusual class of Watcom customers.

 VJ> Well, I'm doing the device drivers with Microsoft C++ 7.00
 VJ> (missing OS/2-files added), this is a far better compiler
 VJ> than 6.00.

I don't have MS C 7.0, and I never saw much point to using a compiler which
has no OS/2 support at all.  MS C 6.0 is actually a very good compiler, but
it is obviously showing signs of age, and cannot do 386+ instructions or
486/586 instruction scheduling.  I do have Zortech from the days when it
supported OS/2, and it was always a far superior compiler to Microsoft,
although OS/2 support was dropped when Zortech was acquired by Symantec.

 VJ> Do you think a change to WatCom (which would be painless
 VJ> with the ported DEVHELP.LIB?) would yield any benefits in
 VJ> code size or speed? 

Actually, you don't need to use a ported DevHelp interface library.  With a
little bit of minor tweaking using Watcom's "#pragma aux" you can
use the official IBM DHCALLS.LIB unmodified.  All DHCALLS.LIB does is
convert stack-based C calling conventions to register-based ASM calling
conventions in a way appropriate to MS C, something which the Watcom
compiler can do with "#pragma aux" and no library if someone sat
down and wrote the header file.

The magic incantation to use IBM's DHCALLS.LIB is nothing more than:

#ifdef __WATCOMC__

/* Suppress warnings about redundant typedefs in IBM header files */
#pragma disable_message(108)

/* Emulate Microsoft C 6.0 calling conventions */
#pragma aux default "_*" parm caller []                           \
                         value struct float struct routine [ax]   \
                         modify [ax bx cx dx es];

#endif /* __WATCOMC__ */


Unfortunately, both of the above statements are undocumented.  While
"#pragma aux" is well documented, the name "default" is
not; it applies to all functions not explicitly given a different calling
tag name.  There are some other subtle things that change when you use
Watcom to make OS/2 device drivers, such as the compiler assuming that
segments are paragraph aligned rather than dword aligned, so some slight
modifications are needed in the ASM stub used to declare the segment
combine rules.

Watcom 10.0 generates far superior code than any Microsoft compiler,
although I have yet to investigate Watcom 10.5 closely.  Simply providing
intelligent instruction scheduling can better than double performance on a
high-end processor by keeping the pipeline flowing.  Watcom 10.0 does seem
to generate larger executables than MS C 6.0 by about 15%, although quite a
lot of that may be a result of enabling aggressive speed optimizations such
as loop unrolling and function inlining.  When you are dealing with a
device driver that grows from 20 KB to 23 KB, however, the trade seems
desirable.

At some point, I will collect all of this neat stuff I have learned by
experiment and make it available.  Maybe I will do a book.  :-)
 
-- Mike


---