Optimizations

When specified on the command line, optimization options may be specified individually (for example, oa or, oi), or the letters may be strung together (for example, oailt).

The following options are defined:

oa
oc
od
oe=num
of
of+
oi
ol
ol+
om
on
oo
op
or
os
ot
ou
ox
oz

When ox is combined with the on, oe, oa and ot options (oneatx) and the zp4 option, the code generator attempts to give you the fastest executing code possible irrespective of architecture. Other options can give you architecture specific optimizations to further improve the speed of your code. Note that specifying oneatx is equivalent to specifying oneatilmr and s. See ``Benchmarking Hints'' in the C/C++ Compilers chapter for more information on generating fast code.

oa

Alias checking is relaxed. When this option is specified, the code optimizer assumes that global variables aren't indirectly referenced through pointers. This assumption may reduce the size of the code that's generated. The following example helps to illustrate this point:

extern int i;

void rtn( int *pi )
{
    int k;
    for( k = 0; k < 10; ++k ) {
      (*pi)++;
      i++;
    }
}

In the above example, if i and *pi reference the same integer object then i is incremented by 2 each time through the for loop, and we would call the pointer reference *pi an alias for the variable i. In this situation, the compiler can't bind the variable i to a register without making sure that the in-memory copy of i is kept up-to-date.

In most cases, the above situation doesn't arise. Rarely would we reference the same variable directly by name and indirectly through a pointer in the same routine. The oa option instructs the code generator that such cases don't arise in the module to be compiled. The code generator is able to produce more efficient code when it doesn't have to worry about the alias problem.

The macro __SW_OA is predefined if oa is selected.

oc

This option may be used to disable the optimization where a CALL followed by a RET (return) is changed into a JMP (jump) instruction.

(wcc/wpp only) This option is required if you wish to link an overlaid program using the Microsoft DOS Overlay Linker. The Microsoft DOS Overlay Linker creates overlay calls for a CALL instruction only. This option isn't required when using the Watcom Linker.

The macro __SW_OC is predefined if oc is selected.

od

Non-optimized code sequences are generated. The resulting code is much easier to debug when using the Watcom Debugger. By default, the compiler selects od if d2 is specified. If d2 is followed by one of the other o options then od is overridden, such as in the following example:

wcc report -d2 -os
wpp report -d2 -os
wcc386 report -d2 -os
wpp386 report -d2 -os

The macro __SW_OD is predefined if od is selected.

oe=num

Certain user functions are expanded in-line. The criteria for which functions are selected for in-line expansion is based on the size of the function in terms of the number of quads generated by the function. A quad (quadruple) consists of four components: an operator, two arguments and a result (hence the name). All expressions can be decomposed into a series of quads. For example, the statement a = -b * (c + d) can be broken down into the following quads:

The number of quads generated corresponds closely to the number of operators used in an expression. Functions that require more than num quads aren't expanded in-line. The default number is 20. This optimization is useful when locally-referenced functions are small in size.

For example,

wcc dhrystone -oe
wpp dhrystone -oe
wcc386 dhrystone -oe
wpp386 dhrystone -oe

of

This option selects the generation of traceable stack frames for those functions that contain calls or require stack frame setup.

(wcc/wpp only) To use Watcom's Dynamic Overlay Manager (DOS only), you must compile all modules using one of the of or of+ options (of is sufficient).

For near functions, the following function prologue sequence is generated:

(wcc/wpp only)
    push BP
    mov  BP,SP

(wcc386/wpp386 only)
    push EBP
    mov  EBP,ESP

For far functions, the following function prologue sequence is generated:

(wcc/wpp only)
    inc  BP
    push BP
    mov  BP,SP

(wcc386/wpp386 only)
    inc  EBP
    push EBP
    mov  EBP,ESP

The BP or EBP value on the stack is even or odd, depending on the code model.

For 16-bit DOS systems, the Dynamic Overlay Manager uses this information to determine if the return address on the stack is a short address (16-bit offset) or long address (32-bit segment:offset).

    wcc toaster -of

The macro __SW_OF is predefined if of is selected.

of+

This option selects the generation of traceable stack frames for all functions, regardless of whether they contain calls or require stack frame setup. This option is intended for developers of embedded systems (ROM-based applications).

To use Watcom's Dynamic Overlay Manager (16-bit DOS only), you must compile all modules using one of the of or of+ options (of is sufficient).

For near functions, the following function prologue sequence is generated:

(wcc/wpp only)
    push BP
    mov  BP,SP

(wcc386/wpp386 only)
    push EBP
    mov  EBP,ESP

For far functions, the following function prologue sequence is generated:

(wcc/wpp only)
    inc  BP
    push BP
    mov  BP,SP

(wcc386/wpp386 only)
    inc  EBP
    push EBP
    mov  EBP,ESP

The BP or EBP value on the stack is even or odd, depending on the code model.

For 16-bit DOS systems, the Dynamic Overlay Manager uses this information to determine if the return address on the stack is a short address (16-bit offset) or long address (32-bit segment:offset).

    wcc toaster -of+

oi

Certain library functions are generated in-line. You must include the appropriate header file containing the prototype for the desired function so that it's generated in-line. The functions that can be generated in-line only for wcc/wpp are:

memset()
strcmp()

The functions that can be generated in-line only for wcc386/wpp386 are:

inpd()
ldiv()
_lrotl()
_lrotr()
outpd()

The functions that can be generated in-line for all the compilers are:

abs()
_disable()
div()
_enable()
fabs()
_fmemchr()
_fmemcmp()
_fmemcpy()
_fmemset()
_fstrcat()
_fstrcmp()
_fstrcpy()
_fstrlen()
inp()
inpw()
labs()
memchr()
memcmp()
memcpy()
movedata()
outp()
outpw()
_rotl()
_rotr()
strcat()
strchr()
strcpy()
strlen()

The macros __INLINE_FUNCTIONS__ and __SW_OI are predefined if oi is selected.

ol

Loop optimizations are performed. This includes moving loop-invariant expressions outside the loops. The macro __SW_OL is predefined if ol is selected.

ol+

Loop optimizations are performed, including loop unrolling. This includes moving loop-invariant expressions outside the loops, and turning some loops into straight-line code. The macro __SW_OL is predefined if ol+ is selected.

om

Generate in-line 80x87 code for math functions such as sin(), cos() and tan(). If this option is selected, it's your responsibility to make sure that arguments to these functions are within the range accepted by the corresponding in-line instructions (fsin(), fcos(), and so on), since no runtime check is made. For 16-bit machines, you must also include the fp3 option to get in-line 80x87 code (except for fabs()). The functions that can be generated in-line are:

atan()
cos()
exp()
fabs()
log10()
log()
sin()
sqrt()
tan()

If the ot option is also specified, the exp() function is generated in-line as well.

The macro __SW_OM is predefined if om is selected.

on

This option allows the compiler to replace floating-point divisions with multiplications by the reciprocal. This generates faster code, but the result may not be the same because the reciprocal may not be exactly representable. The macro __SW_ON is predefined if on is selected.

oo

By default, the compiler aborts compilation if it runs low on memory. This option forces the compiler to continue anyway.

This can result in the generation of very poor code.

The macro __SW_OO is predefined if oo is selected.

op

This option causes to compiler to store intermediate floating-point results in memory, in order to generate consistent floating-point results, rather than keeping values in the 80x87 registers, where they have more precision. The macro __SW_OP is predefined if op is selected.

or

This option enables the reordering of instructions (instruction scheduling) to achieve better performance on pipelined architectures such as the Intel 486 and Pentium processors. This option is essential for generating fast code for the Intel Pentium processor.

Selecting this option makes it slightly more difficult to debug because the assembly language instructions generated for a source statement may be intermixed with instructions generated for surrounding statements.

The macro __SW_OR is predefined if or is selected.

os

Space is favoured over time when generating code (smaller code but possibly slower execution). By default, the compiler selects a balance between space and time. The macro __SW_OS is predefined if os is selected.

ot

Time is favoured over space when generating code (faster execution but possibly larger code). By default, the compiler selects a balance between space and time. The macro __SW_OT is predefined if ot is selected.

ou

This option forces the compiler to make sure that all function labels are unique. Thus the compiler won't place two function labels at the same address even if the code for the two functions is identical. This option is automatically selected if the za option is specified. The macro __SW_OU is predefined if ou is selected.

ox

The oilmr and s (no stack overflow checking) options are selected.

oz

This option prevents the compiler from omitting NULL pointer checks on pointer conversions. By default, the compiler omits these checks when it's safe to do so. Consider the following example:

struct B1 {
    int b1;
};
struct B2 {
    int b2;
};
struct D : B1, B2 {
    int d;
};

void clear_D( D *p )
{
    p->d = 0;
    B1 *p1 = p;
    p1->b1 = 0;
    B2 *p2 = p;
    p2->b2 = 0;
}

In this example, the C++ compiler must ensure that p1 and p2 become NULL if p is NULL (since no offset adjustment is allowed for a NULL pointer). However, the first executable statement implies that p isn't NULL since, in most operating environments, the executing program would crash at the first executable statement if it were. The oz option prevents the compiler from omitting the check for a NULL pointer.

The macro __SW_OZ is predefined if oz is selected.

p{e,l,c,w=num}

The input file is preprocessed and, by default, is written to the standard output file. The fo option may be used to redirect the output to a file with default extension .i.

When only p is specified, source comments and #line directives aren't included. You must request these using the c and l suffixes.

Specify pc if you wish to include the original source comments in the Watcom C/C++ preprocessor output file.

(C++ Only) Specify pe if you wish to encrypt the original identifiers when they're written to the Watcom C/C++ preprocessor output file.

Specify pl if you wish to include #line directives. When the output of the preprocessor is fed into the compiler, these directives enable the compiler to issue diagnostics in terms of the line numbers of the original source file.

Specify pcl or plc if you wish both source comments and #line directives.

Use the w=num suffix if you wish to wish output lines to wrap at num columns. Zero means no wrapping.

For example,

wcc report -pclw=80
wpp report -pcelw=80
wcc386 report -pclw=80
wpp386 report -pcelw=80

The following compiler options are supported when the Watcom C/C++ preprocessor is requested: d, fi, fo, i, m{f,s,m,c,l,h}, and u.

r

This option instructs the compiler to generate function prologue and epilogue sequences that save and restore any segment registers that are modified by the function.

---

Be careful when using this option. If the value of the segment register being restored matches the value of a segment that was freed within the function, a general protection fault occurs in protected-mode environments.

---

By default, the compiler doesn't generate code to save and restore segment registers. This option is provided for compatibility with the version 8.0 release. The macro __SW_R is predefined if r is selected.

ri

Functions declared to return integral types, such as chars and shorts, are promoted to returning ints. This allows non-ANSI-conforming source code that doesn't properly declare the return types of functions to work correctly.

---

Avoid using this option; fixing the code is a better idea.

---

s

Stack overflow checking is omitted from the generated code. By default, the compiler emits code at the beginning of every function that checks for stack overflow. This option can be used to disable this feature.

The macro __SW_S is predefined if s is selected.

---

QNX interrupt handlers must be compiled with the s and zu options; see the description of the qnx_hint_attach() function in the C Library Reference.

---

sg

This option is useful for 32-bit OS/2 multi-threaded applications. It requests the code generator to emit a runtime call at the start of any function that has more than 4K bytes of automatic variables (that is, variables located on the stack).

Under 32-bit OS/2, the stack is grown automatically in 4K pages for any threads, other than the primary thread, using the stack guard page mechanism. The stack consists of in-use committed pages topped off with a special guard page. A memory reference into the 4K guard page causes the operating system to grow the stack by one 4K page and to add a new 4K guard page.

This works well when there's less than 4K of automatic variables in a function. When there's more, the stack must be grown in an orderly fashion, 4K bytes at a time, until it's big enough to accommodate all the automatic variable storage requirements. This requires a stack-growing runtime routine, which is called __GRO().

The macro __SW_SG is predefined if sg is selected.

---

This option doesn't apply to QNX.

---

st

This option causes the code generator to ensure that the first reference to the stack in a function is to the stack bottom using the SS register. If the memory for this part of the stack isn't mapped to the task, a memory fault occurs, involving the SS register. This permits an operating system to allocate additional stack space to the faulting task.

Suppose that a function requires 100 bytes of stack space. The code generator usually emits an instruction sequence to reduce the stack pointer by the required number of bytes of stack space, thereby establishing a new stack bottom. When the st option is specified, the code generator ensures that the first reference to the stack is to a memory location with the lowest address. If a memory fault occurs, the operating system can determine that it was a stack reference (since the SS register is involved) and also how much additional stack space is required.

See the description of the sg option for a more general solution to the stack allocation problem. The macro __SW_ST is predefined if st is selected.

---

This option doesn't apply to QNX.

---

t=num

(C++ only) The t option is used to set the tab stop interval. By default, the compiler assumes a tab stop occurs at multiples of 8 (1+n x 8 = 1, 9, 17, ... for n=0, 1, 2, ...). When the compiler reports a line number and column number in a diagnostic message, the column number has been adjusted for intervening tabs. You should use this option if the default tab stop setting for your text editor isn't a multiple of 8.

For example,

wpp report -t=4
wpp386 report -t=4

uname

The u option turns off the definition of a predefined macro. If no name is specified then all predefined macros are undefined, with the exception of the memory model macros.

For example,

wcc report -uM_I86
wpp report -uM_I86
wcc386 report -uM_I86
wpp386 report -uM_I86

v

This option causes Watcom C to write function declarations to a file with the same filename as the C source file, but with extension .def. This definition file may be used as an include file when compiling other modules, in order to take advantage of the checking that the compiler does on function and argument types. See also the zg option.

wnumber

The compiler issues only warning type messages of severity number or below. Type 1 warning messages are the most severe, while type 3 warning messages are the least. Specify w0 to prevent warning messages from being issued. Specify wx to obtain all warning messages.

wcd=number

This option disables the compiler message with the given number.

wce=number

This option enables the compiler message with the given number.

we

By default, the compiler continues to create an object file when there are warnings produced. This option can be used to treat all warnings as errors, thereby preventing the compiler from creating an object file if there are warnings found within a module.

wo

(16-bit only, C only) This option tells the compiler to emit warnings for things that cause problems when compiling code for use in overlays.

wx

This option sets the warning level to its maximum setting. The wnumber option can be used to set the warning level to other values.

xd, xdt

(C++ only) This option disables exception handling. It's the default option if no exception handling option is specified.

---

The xd and xdt options are the same.

---

When this option is specified (explicitly or by default):

• Destruction of objects is caused by direct calls to the appropriate destructors
• Destructor functions are implemented with direct calls to appropriate destructors to destroy base classes and class members.

---

The xd... options disable exception handling. Consequently, it isn't possible to use throw, try, or catch statements, or to specify a function-exception specification. If your program (or a library that it includes) throws exceptions, then one of the xs... options should be used to compile all the modules in your program; otherwise, any active objects created within the module won't be destructed during exception processing. Multiple schemes are possible, allowing experimentation to determine the optimal scheme for particular circumstances. You can mix and match schemes on a module basis, with the proviso that exceptions should be enabled wherever it's possible that a created object should be destroyed by the exception mechanism.

---

xds

(C++ only) This option disables exception handling. When this option is specified:

• Destruction of objects is caused by direct calls to the appropriate destructors.
• Destruction of base classes and class members is accomplished by interpreting tables.

This option, in general, generates smaller code, with increased execution time, and with more runtime system routines included by the linker.

---

The xd... options disable exception handling. Consequently, it isn't possible to use throw, try, or catch statements, or to specify a function-exception specification. If your program (or a library that it includes) throws exceptions, then one of the xs... options should be used to compile all the modules in your program; otherwise, any active objects created within the module won't be destroyed during exception processing. Multiple schemes are possible, allowing experimentation to determine the optimal scheme for particular circumstances. You can mix and match schemes on a module basis, with the proviso that exceptions should be enabled wherever it's possible that a created object should be destroyed by the exception mechanism.

---

xs

(C++ only) This option enables exception handling using a balanced scheme. When this option is specified:

• tables are interpreted to effect the destruction of temporaries and automatic objects
• destructor functions are implemented with direct calls to the appropriate destructors to destroy base classes and class members

xss

(C++ only) This option enables exception handling using a space-saving scheme. When this option is specified:

• tables are interpreted to effect destruction of temporaries and automatic objects
• destruction of base classes and class members is accomplished by interpreting tables.

This option, in general, generates smaller code, with increased execution time.

xst

(C++ only) This option enables exception handling using a time-saving scheme. When this option is specified:

• destruction of temporaries and automatic objects is accomplished with direct calls to appropriate destructors
• destructor functions are implemented with direct calls to appropriate destructors to destroy base classes and class members.

This scheme, in general, generates faster code, but it uses more space.

za

This option helps to ensure that the module to be compiled conforms to the ANSI C programming language specification. The macro NO_EXT_KEYS (no extended keywords) is predefined if za is selected. See also the description of the ze option.

zc

The zc option causes the code generator to place literal strings and const items in the code segment.

For example,

const int cvar = 1;
int var = 2;
const int ctable[ 5 ] = { 1, 2, 3, 4, 5 };
char *birds[ 3 ] = { "robin", "finch", "wren" };

In the above example, cvar and ctable and the strings ``robin'', ``finch'', and so on are placed in the code segment. This option is supported in large data or flat memory models only, or if the item is explicitly far. The macro __SW_ZC is predefined if zc is selected.

zd{f,p}

The zdf option allows the code generator to use the DS register to point to other segments besides DGROUP. This is the default in the compact, large, and huge (wcc/wpp only) memory models. The macro __SW_ZDF is predefined if zdf is selected.

The zdp option informs the code generator that the DS register must always point to DGROUP. This is the default in the flat (wcc386/wpp386 only), small, and medium memory models. The macro __SW_ZDP is predefined if zdp is selected.

zdl

(wcc386/wpp386 only) The zdl option causes the generation of code to load the DS register directly from DGROUP (rather than the default runtime call). This option causes the generation of a segment relocation. This option is used with the zdp option, but not the zdf option.

---

QNX flat programs don't allow relocations.

---

ze

The ze option (default) enables the use of the following compiler extensions:

• The requirement for at least one external definition per module is relaxed.
• The escape sequence \l is interpreted as a synonym for \n in strings and character constants.
• When using the C compiler, some forgiveable pointer type mismatches become warnings instead of errors.
• In-line math functions are allowed (note that errno won't be set by in-line functions).
• When using the C compiler, anonymous structs and unions are allowed (this is always permitted in C++).

  For example,

  struct {
      int a;
      union {
          int   b;
          float alt_b;
      };
      int c;
  } x;
      
  

  In the above example, x.b is a valid reference to the b field.

• For C only, ANSI function prototype scope rules are relaxed to allow the following program to compile without any errors:

  void foo( struct a *__p );
  
  struct a {
      int b;
      int c;
  };
  
  void bar( void )
  {
      struct a x;
      foo( &x );
  }
        
  

  According to a strict interpretation of the ANSI C standard, the function prototype introduces a new scope that's terminated at the semicolon (;). The effect of this is that the structure tag a in the function foo() isn't the same structure tag a defined after the prototype. A diagnostic must be issued for a conforming ANSI C implementation.

• A trailing comma (,) is allowed after the last constant in an enum declaration.

  For example,

  enum colour { RED, GREEN, BLUE, };
        
  

• The ANSI requirement that all enumerated types have a base type of int is relaxed. The motivation for this extension is the conservation of storage. Many enumerated types can be represented by integral types that are smaller in size than an int.

  For example,

  enum colour { RED, GREEN, BLUE, };
  
  void foo( void )
  {
      enum colour x;
  
      x = RED;
  }
        
  

  In the example, x can be stored in an unsigned char because its values span the range 0 to 2.

• The ANSI requirement that the base type of a bitfield be int or unsigned is relaxed. This allows a programmer to allocate bitfields from smaller units of storage than an int (for example, unsigned char).

  For example,

  struct {
      unsigned char a : 1;
      unsigned char b : 1;
      unsigned char c : 1;
  } x;
  
  struct {
      unsigned a : 1;
      unsigned b : 1;
      unsigned c : 1;
  } y;
        
  

  In the above example, the size of x is the same size as an unsigned char, whereas the size of y is the same size as an unsigned int.

• The following macros are defined:
  • _near, near
  • _far, far
  • _huge, huge
  • _cdecl, cdecl
  • _pascal, pascal
  • _fortran, fortran
  • _interrupt, interrupt
  • _export
  • _loadds
  • _saveregs

  These macros are described in ``C/C++ extended keywords'' in the C/C++ Compilers chapter.

Use the za option if your application must conform to the ANSI C standard.

zf{f,p}

The zff option allows the code generator to use the FS register (the default for all but the flat memory model). The macro __SW_ZFF is predefined if zff is selected.

The zfp option informs the code generator that the FS register must not be used (the default in the flat memory model). The macro __SW_ZFP is predefined if zfp is selected.

zg

The zg option is similar to the v option, except that function declarations are written to the .def file using base types (that is, typedefs are reduced to their base type).

For example,

typedef unsigned int UINT;
UINT f( UINT x )
 {
    return( x + 1 );
 }

If you use the v option, the output is:

extern UINT f(UINT );

If you use the zg option, the output is:

extern unsigned int f(unsigned int );

zg{f,p}

The zgf option allows the code generator to use the GS register (the default for all memory models). The macro __SW_ZGF is predefined if zgf is selected.

The zgp option informs the code generator that the GS register must not be used. The macro __SW_ZGP is predefined if zgp is selected.

zk{0,1,2}

This option causes the compiler to recognize double-byte characters in strings. When the compiler scans a text string enclosed in quotes ("), it recognizes the first byte of a double-byte character, and suppresses the lexical analysis of the second byte. This prevents the compiler from misinterpreting the second byte as a backslash (\) or quote (") character.

zk, zk0

These options cause the compiler to process strings for Japanese double-byte characters (range 0x81 - 0x9F and 0xE0 - 0xFC). The characters in the range A0 - DF are single-byte Katakana.

zk1

This option causes the compiler to process strings for Traditional Chinese and Taiwanese double-byte characters (range 0x81 - 0xFC).

zk2

This option causes the compiler to process strings for Korean Hangeul double-byte characters (range 0x81 - 0xFD).

The macro __SW_ZK is predefined if any zk option is selected.

zk0u

This option causes the compiler to process strings for Japanese double-byte characters (range 0x81 - 0x9F and 0xE0 - 0xFC). The characters in the range A0 - DF are single-byte Katakana. All characters, including Kanji, in wide characters (L'c') and wide strings (L"string") are translated to UNICODE.

When the compiler scans a text string enclosed in quotes ("), it recognizes the first byte of a double-byte character, and suppresses the lexical analysis of the second byte. This prevents the compiler from misinterpreting the second byte as a backslash (\) or quote (") character.

zku=codepage

Characters in wide characters (L'c') and wide strings (L"string") are translated to UNICODE. The UNICODE translation table for the specified code page is loaded from a file with the name UNICODE.cpn, where cpn is the code page number (for example, zku=850 selects the file UNICODE.850).

zl

By default, the compiler places in the object file the names of the C libraries that correspond to the memory model and floating-point options that were selected. The Watcom Linker uses these library names to select the libraries required to link the application. If you use the zl option, the library names aren't included in the generated object file.

The compiler may generate external references for library code that conveniently cause the linker to link in different code. For example, if you have any functions that pass or return floating-point values (that is, float or double), the compiler inserts an external reference that causes the floating-point formatting routines to be included in the executable. The zl option disables these external references.

Use this option when you wish to create a library of object modules that don't contain Watcom C/C++ library name references.

zld

By default, the compiler places in the object file the names and time stamps of all the files referenced by the source file. This file dependency information can then be used by a make utility program to determine that this file needs to be recompiled if any of the referenced files have been modified since the object file was created. This option causes the compiler not to emit this information into the object file.

zm

The zm option instructs the code generator to place each function into a separate segment. This option is used in paging environments where special segment ordering may be employed. The alloc_text pragma is often used in conjunction with this option to place functions into specific segments. The disadvantages to this option are:

1. Static functions are far-called in big code models. The near-call optimization is lost.
2. The common-epilogue optimization is lost.

The macro __SW_ZM is predefined if zm is selected.

zo

This option enables exception handling using a space-saving scheme.

This option has been added to the C++ compiler in order to specify that operating-system dependent exception-handling is to be used. When the option isn't specified, the exception-handling mechanism is independent of the operating system (as was the case in previous releases).

---

This option has an effect only under NT and OS/2 in the 32-bit compiler (WPP386). A warning is issued when this option is used in other environments.

---

When this option is used, it must be used to produce all C++ object files that are linked together to create .EXE or .DLL files. When only some of the object files are compiled with this option, the linker will report unresolved or duplicated global symbols. If you wish to use this option, the complete application must be recompiled with this option. This is to ensure that only operating-system dependent libraries are used to link the application.

When the zo option is used and the target object is for a different system than the system used for compilation, the build-target (bt) option must be used to specify the target system. If omitted, the C++ compiler assumes you're producing object for the system used to compile the program.

This option should viewed as a temporary mechanism to allow users to avoid recompiling applications when they don't require either NT or OS/2 system exception handling. In the next major release, full recompilation will be required and the system-dependent exception handling will be the default.

To help resolve errors, the following global symbols are generated:

__compiled_under_NT

compiled using -zo -bt=NT

__compiled_under_OS2

compiled using -zo -bt=OS2

__compiled_under_GENERIC

compiled otherwise. This is defined in all libraries for which exceptions are handled in a system-independent manner.

zp[{1,2,4,8}]

The zp option allows you to specify the alignment of members in a structure. The default is zp1. The alignment of structure members is described in the following table. If the size of the member is 1, 2, 4 or 8, the alignment is given for each of the zp options.

sizeof(member)	zp1	zp2	zp4	zp8
1	0	0	0	0
2	0	2	2	2
4	0	2	4	4
8	0	2	4	8

An alignment of 0 means no alignment, 2 means word boundary, 4 means double-word boundary, and so on.

If the member of the structure is an array or structure, it's aligned to the largest member, as follows:

• If the largest member of structure x is 1 byte, then x isn't aligned.
• If the largest member of structure x is 2 bytes, then x is aligned according to row 2.
• If the largest member of structure x is 4 bytes, then x is aligned according to row 4.
• If the largest member of structure x is 8 bytes, then x is aligned according to row 8.

To understand why the alignment of structure members may be important, consider the following example:

typedef struct memo_el {
    char           date[9];
    struct memo_el *prev,*next;
    ref_number     int;
} memo;

In the above example, the default alignment zp1 causes the pointer and integer items to be aligned on odd addresses, since the array date is 9 bytes in length. On computer systems that have a 16-bit (or 32-bit) bus, improved performance can be obtained when these items are aligned on an even boundary.

zq

The quiet mode option causes the informational messages displayed by the compiler to be suppressed. These include:

• messages that identify the compiler
• messages that summarize the number of lines compiled
• dots that are displayed every few seconds while the code generator is active to indicate that the compiler is still working.

Error and warning messages aren't suppressed.

zs

This option makes the compiler check the source code only, and omit the generation of object code. Syntax checking, type checking, and so on are performed as usual.

ztnumber

The data threshold option is used to set the maximum size for data objects to be included in the default data segment. This option can be used with the compact, large, and huge (16-bit) memory models only. These are memory models where there can be more than one data segment.

Normally, all data objects whose size is less than or equal to the threshold value are placed in the default data segment _DATA unless they're specifically declared to be far items. When there's a large amount of static data, it's often useful to set the data threshold size so that all objects larger than this size are placed in another (far) data segment.

For example, the option zt100 causes all data objects larger than 100 bytes in size to be implicitly declared as far, and to be grouped in other data segments.

The default data threshold value is 32767. Thus, by default, all objects greater than 32767 bytes in size are implicitly declared as far, and are placed in other data segments. If the zt option is specified without a size, the data threshold value is 256.

---

If the zt option is used to compile any module in a program, then you must compile all the other modules in the program with the same option (and value).

---

Be careful when declaring the size of objects in different modules. Consider the following declarations in two different C files. Suppose we define an array in one module as follows:

extern int Array[100] = { 0 };

and, suppose we reference the same array in another module as follows:

extern int Array[10];

If these modules are compiled with the option zt100, we have a problem. In the first module, the array would be placed in another segment, since Array[100] is bigger than the data threshold. In the second module, the array would be placed in the default data segment since Array[10] is smaller than the data threshold. The extra code required to reference the object in another data segment wouldn't be generated.

---

This problem can also occur even when the zt option isn't used (that is, for objects greater than 32767 bytes in size). There are two solutions to this problem: be consistent when declaring an object's size, or, don't specify the size in data reference declarations.

---

zu

The zu option relaxes the restriction that the SS register contains the base address of the default data segment, DGROUP. Normally, all data items are placed into the group DGROUP, and the SS register contains the base address of this group. When the zu option is selected, the SS register is volatile (that is, it's assumed to point to another segment), and any global data references require loading a segment register such as DS with the base address of DGROUP.

This option is useful when compiling routines that are to be placed in a shared library, since the SS register points to the stack segment of the calling application upon entry to the function.

The macro __SW_ZU is predefined if zu is selected.

---

QNX interrupt handlers must be compiled with the s and zu options; see the description of the qnx_hint_attach() function in the C Library Reference.

---

zv

This option makes sizeof (void) == 1, so you can directly increment or decrement void pointers without having to do type-casting.

zw

(wcc/wpp only) This option causes the compiler to generate the prologue/epilogue code sequences required for Microsoft Windows applications. The following ``fat'' prologue/epilogue sequence is generated for any functions declared to be far _export or far pascal.

far pascal func(...)
far _export func(...)
far _export pascal func(...)

    push DS
    pop  AX
    nop
    inc  BP
    push BP
    mov  BP,SP
    push DS
    mov  DS,AX
    .
    .
    .
    pop DS
    pop BP
    dec BP
    retf n

The macro __WINDOWS__ is predefined if zw is selected.

(wcc386/wpp386 only) This option causes the compiler to generate any special code sequences required for 32-bit Microsoft Windows applications. The macro __WINDOWS__ and __WINDOWS_386__ are predefined if zw is selected.

---

This option doesn't apply to QNX.

---

zW

(wcc/wpp only) This option is similar to zw, but causes the compiler to generate more efficient prologue/epilogue code sequences in some cases. This option may be used for Microsoft Windows applications code other than user callback functions. Any functions declared as far _export are compiled with the ``fat'' prologue/epilogue code sequence described under the zw option.

far _export func(...)
far _export pascal func(...)

The following ``skinny'' prologue/epilogue sequence is generated for functions that aren't declared to be far _export.

far pascal func(...)
far func(...)

    inc  BP
    push BP
    mov  BP,SP
    .
    .
    .
    pop BP
    dec BP
    retf n

The macro __CHEAP_WINDOWS__ and __WINDOWS__ are predefined if zW is selected.

---

This option doesn't apply to QNX.

---

zWs

(wcc/wpp only) This option is similar to zW, but causes the compiler to generate ``smart callbacks.'' This option may be used for Microsoft Windows user callback functions in executables only. It isn't permitted for DLLs.

---

This option doesn't apply to QNX.

---

Normally, a callback function can't be called directly. You must use MakeProcInstance() to obtain a function pointer with which to call the callback function.

If you specify zWs then you don't need to use MakeProcInstance() in order to call your own callback functions. Any functions declared as far _export are compiled with the ``smart'' prologue code sequence described here.

The following example shows the usual prologue code sequence that's generated when the zWs option isn't used.

wcc winapp -mc -bt=windows -d1
wpp winapp -mc -bt=windows -d1

short FAR PASCAL __export Function1( short var1,
                                     long varlong,
                                     short var2 )
{
 0000  1e         FUNCTION1          push    ds
 0001  58                            pop     ax
 0002  90                            nop
 0003  45                            inc     bp
 0004  55                            push    bp
 0005  89 e5                         mov     bp,sp
 0007  1e                            push    ds
 0008  8e d8                         mov     ds,ax

The following example shows the ``smart'' prologue code sequence that's generated when the zWs option is used. The assumption here is that the SS register contains the address of DGROUP.

wcc winapp -mc -bt=windows -d1 -zWs
wpp winapp -mc -bt=windows -d1 -zWs

short FAR PASCAL __export Function1( short var1,
                                     long varlong,
                                     short var2 )
{
 0000  8c d0         FUNCTION1       mov     ax,ss
 0002  45                            inc     bp
 0003  55                            push    bp
 0004  89 e5                         mov     bp,sp
 0006  1e                            push    ds
 0007  8e d8                         mov     ds,ax

zz

Use this option if you want to generate __stdcall function names that are compatible with version 10.0 of the compilers. When this option is omitted, all C symbols (extern C symbols in C++) are suffixed by @nnn, where nnn is the sum of the argument sizes (each size is rounded up to a multiple of 4 bytes so that char and short are size 4). When the argument list contains ``...'', the @nnn suffix is omitted. This convention is compatible with Microsoft.

For more information on the __stdcall convention, see ``Watcom Extended Keywords'' in the C/C++ Compilers chapter.

---

This option doesn't apply to QNX.

---