United States

Compaq C

# Compaq C
User's Guide for OpenVMS Systems

Previous | Contents | Index

The VAXCRTLX.OLB, VAXCRTLDX.OLB, and VAXCRTLTX.OLB libraries are used for the same floating-point formats, respectively, but include support for X_FLOAT format (/L_DOUBLE_SIZE=128). (ALPHA ONLY)

If /PREFIX=ALL is specified, then there is no need to link to the above-mentioned *.OLB object libraries. All the symbols you need are in STARLET.OLB. (ALPHA ONLY)

On OpenVMS VAX systems, representation of `double` variables defaults to D_floating format if not overridden by another format specified with the /FLOAT or /[NO]G_FLOAT qualifier. There is one exception: if /STANDARD=MIA is specified, G_floating is the default. If you are linking against object-module libraries, a program compiled with G_floating format must be linked with the object library DECCRTLG.OLB. (VAX ONLY)

Table 1-8 describes the /FLOAT qualifier options.

Table 1-8 /FLOAT Qualifier Options
Option | Usage
--- | ---
D_FLOAT | `double` variables are represented in D_floating format.
G_FLOAT | `double` variables are represented in G_floating format.
IEEE_FLOAT (ALPHA ONLY) | `float` and `double` variables are represented in IEEE floating-point format (S_float and T_float, respectively). Use the /IEEE_MODE qualifier for controlling the handling of IEEE exceptional values. If /IEEE_MODE is not specified, the default behavior is /IEEE_MODE=FAST.

### /[NO]G_FLOAT

Controls the format of floating-point variables. The /[NO]G_FLOAT qualifier is replaced by the /FLOAT qualifier, but is retained for compatibility.

If you specify /G_FLOAT, `double` variables are represented in G_floating format.

If you specify /NOG_FLOAT, `double` variables are represented in D_floating format. (See Section 4.5 for more information on the floating formats.)

On OpenVMS Alpha systems, representation of `double` variables defaults to G_floating format if not overridden by another format specified with the /FLOAT or /[NO]G_FLOAT qualifier.

If you are linking against object-module libraries, and /PREFIX=ALL is not specified on the command line:

- a program compiled with G_FLOAT format must be linked with the object library VAXCRTL.OLB
- a program compiled with D_FLOAT format must be linked with VAXCRTLD.OLB
- a program compiled with IEEE_FLOAT format (ALPHA ONLY) must be linked with VAXCRTLT.OLB.

The VAXCRTLX.OLB, VAXCRTLDX.OLB, and VAXCRTLTX.OLB libraries are used for the same floating-point formats, respectively, but include support for X_FLOAT format (/L_DOUBLE_SIZE=128). (ALPHA ONLY)

If /PREFIX=ALL is specified, then there is no need to link to the above-mentioned *.OLB object libraries. All the symbols you need are in STARLET.OLB. (ALPHA ONLY)

On OpenVMS VAX systems, representation of `double` variables defaults to D_floating format if not overridden by another format specified with the /FLOAT or /[NO]G_FLOAT qualifier. There is one exception: if /STANDARD=MIA is specified, G_floating is the default. If you are linking against object-module libraries, a program compiled with G_floating format must be linked with the object library DECCRTLG.OLB. (VAX ONLY)

### /GRANULARITY=option (ALPHA ONLY)

Determines how much memory to effectively cache for memory reference, depending on the compiler and the underlying system. For example, quadword granularity may require that the system cache quadword values in registers. If access to data in the same granularity unit occurs simultaneously, corruption (by storing back stale values) can occur.

Granularity has two aspects: references inside a particular data segment and references between data segments.

The options are:

> BYTE
> LONGWORD
> QUADWORD

The default is /GRANULARITY=QUADWORD.

### /IEEE_MODE=option (ALPHA ONLY)

Selects the IEEE floating-point mode to be used if /FLOAT=IEEE_FLOAT is specified.

Table 1-9 describes the /IEEE_MODE options.

Table 1-9 /IEEE_MODE Options
Option | Usage
--- | ---
FAST | During program execution, only finite values (no infinities, NaNs, or denorms) are created. Underflows and denormal values are flushed to zero. Exceptional conditions, such as floating-point overflow, divide-by-zero, or use of an IEEE exceptional operand are fatal. This is the default option.
UNDERFLOW_TO_ZERO | Generate infinities and NaNs. Flush denormalized results and underflow to zero without exceptions.
DENORM_RESULTS | Same as UNDERFLOW_TO_ZERO, except that denorms are generated.
INEXACT | Same as DENORM_RESULTS, except that inexact values are trapped. This is the slowest mode, and is not appropriate for any sort of general-purpose computations.

The default is /IEEE_MODE=FAST.

### /[NO]INCLUDE_DIRECTORY=(pathname[,...])

Provides similar functionality to the `-I` option of the cc command on Tru64 UNIX systems. This qualifier allows you to specify additional places to search for include files. A place can be one of the following:

- OpenVMS file-spec to be used as a default file-spec to RMS file services (example: DISK$:[directory])
- UNIX style pathname in quotation marks (example: "/sys")
- Empty string ("")

If one of the places is specified as an empty string, the compiler does not search any of its conventionally-named places:

> DECC$USER_INCLUDE
> DECC$SYSTEM_INCLUDE
> DECC$LIBRARY_INCLUDE
> SYS$COMMON:[DECC$LIB.INCLUDE.*]
> DECC$TEXT_LIBRARY
> SYS$LIBRARY:DECC$RTLDEF.TLB
> SYS$LIBRARY:SYS$STARLET_C.TLB

Instead, it searches only places specified explicitly on the command line by the /INCLUDE_DIRECTORY and /LIBRARY qualifiers (or by the location of the primary source file, depending on the /NESTED_INCLUDE_DIRECTORY qualifier). This behavior is similar to that obtained by specifying -I without a directory name to the Tru64 UNIX `cc` command.

The basic search order depends on the form of the header-file name (after macro expansion). Additional aspects of the search order are controlled by other command-line qualifiers and the presence or absence of logical name definitions.

Only the portable forms of the `#include` directive are affected by the pathnames specified on an /INCLUDE_DIRECTORY qualifier:

- In quotes (example: `#include "stdio.h"` )
- In angle brackets (example: `#include <stdio.h>` )

However, an empty string also affects the text-module form specific to OpenVMS systems (example: `#include stdio` ).

Except where otherwise specified, searching a "place" means that the string designating the place is used as the default file-spec in a call to an RMS system service (for example, $SEARCH/$PARSE). The file-spec consists of the name in the `#include` directive without enclosing delimiters. The search terminates successfully as soon as a file can be opened for reading.

Note Prior to OpenVMS VAX Version 7.1, the operating system did not provide a SYS$LIBRARY:SYS$STARLET_C.TLB nor the headers contained therein. Instead, the compiler installation generated these headers and placed them in SYS$LIBRARY:DECC$RTLDEF.TLB.

Quoted Form

For the quoted form of inclusion, the search order is:

1. One of the following:
   - If /NESTED_INCLUDE_DIRECTORY=INCLUDE_FILE (the default) is in effect, search the directory containing the file in which the `#include` directive itself occurred. The directory containing means the RMS resultant string obtained when the file in which the `#include` occurred was opened, except that the filename and subsequent components are replaced by the default file type for headers (".h", or just "." if /ASSUME=NOHEADER_TYPE_DEFAULT is in effect). The resultant string will not have translated any concealed device logical.
   - If /NESTED_INCLUDE_DIRECTORY=PRIMARY_FILE is in effect, search the default file type for headers using the context of the primary source file. This means that just the file type (".h" or ".") is used for the default file-spec but, in addition, the chain of "related file-specs" used to maintain the sticky defaults for processing the next top-level source file is applied when searching for the include file. This most closely matches the behavior of the VAX C compiler.
   - If /NESTED_INCLUDE_DIRECTORY=NONE is in effect, this entire step (Step 1) is bypassed.
2. Search the places specified in the /INCLUDE_DIRECTORY qualifier, if any. A place that can be parsed successfuly as an OpenVMS file-spec and that does not contain an explicit file type or version specification is edited to append the default header file type specification (".h" or ".").
   A place containing a "/" character is considered to be a UNIX-style name. If the name in the `#include` directive also contains a "/" character that is not the first character and is not preceded by a "!" character (it is not an absolute UNIX-style pathname), then the name in the `#include` directive is appended to the named place, separated by a "/" character, before applying the decc$to_vms pathname translation function. The result of the decc$to_vms translation is then used as the filespec to try to open.
3. If DECC$USER_INCLUDE is defined as a logical name, search DECC$USER_INCLUDE:.H, or just DECC$USER_INCLUDE:. if /ASSUME=NOHEADER_TYPE_DEFAULT is in effect.
4. If the file is not found, follow the steps for the angle-bracketed form of inclusion.

Angle-Bracketed Form

For the angle-bracketed form of inclusion, the search order is:

1. Search the place "/". This is a UNIX-style name that can combine only with UNIX names specified explicitly in the `#include` directive. It causes a specification like <sys/types.h> to be considered first as /sys/types.h, which is translated by decc$to_vms to SYS:TYPES.H.
2. Search the places specified in the /INCLUDE_DIRECTORY qualifier, exactly as in Step 2 for the quoted form of inclusion.
3. If DECC$SYSTEM_INCLUDE is defined as a logical name, search DECC$SYSTEM_INCLUDE:.H, or just DECC$SYSTEM_INCLUDE:. if /ASSUME=NOHEADER_TYPE_DEFAULT is in effect.
4. If DECC$LIBRARY_INCLUDE is defined as a logical name and DECC$SYSTEM_INCLUDE is not defined as a logical name, search DECC$LIBRARY_INCLUDE:.H, or just DECC$LIBRARY_INCLUDE:. if /ASSUME=NOHEADER_TYPE_DEFAULT is in effect.
5. If neither DECC$LIBRARY_INCLUDE nor DECC$SYSTEM_INCLUDE are defined as logical names, then search the default list of places for plain text-file copies of compiler header files as follows:

   > SYS$COMMON:[DECC$LIB.INCLUDE.DECC$RTLDEF].H
   > SYS$COMMON:[DECC$LIB.INCLUDE.SYS$STARLET_C].H

   Note The compiler installation does not create these directories of header files. Instead, it creates [DECC$LIB.REFERENCE] for your convenience. But if you choose to create and populate SYS$COMMON:[DECC$LIB.INCLUDE.DECC$RTLDEF] or SYS$COMMON:[DECC$LIB.INCLUDE.SYS$STARLET_C].H, the compiler will search them.

   If the file is not found, perform the text library search described in the next step.
6. Extract the simple filename and file type from the `#include` specification and use the filename as the module name to search a list of text libraries associated with that file type.
   For any file type, the initial text libraries searched consist of those named on the command line with /LIBRARY qualifiers, searched in left-to-right order.
   If the /INCLUDE_DIRECTORY qualifier contained an empty string, no further text libraries are searched. Otherwise, DECC$TEXT_LIBRARY is searched for all file types.
   If DECC$LIBRARY_INCLUDE is defined as a logical name, then no further text libraries are searched. Otherwise, the subsequent libraries searched for each file type are:
   - For a file type of ".h" or ".":

     > SYS$LIBRARY:DECC$RTLDEF.TLB
     > SYS$LIBRARY:SYS$STARLET_C.TLB

   - For a file type other then ".h" or ".":

     > SYS$LIBRARY:SYS$STARLET_C.TLB

7. If the previous step fails, search the following:

   > SYS$LIBRARY:.H

   Under /ASSUME=NOHEADER_TYPE_DEFAULT, the default file type is modified as usual.

Text-Module Form

For the text-module (nonportable) form of inclusion, the name can only be an identifier. It, therefore, has no associated file type.

The identifier is used as a module name to search the following:

1. The text libraries named on the command line with /LIBRARY qualifiers, in left-to-right order.
2. The following list of text libraries in the order shown (unless the /INCLUDE_DIRECTORY qualifier contains an empty string, in which case no further text libraries are searched):

   > DECC$TEXT_LIBRARY
   > SYS$LIBRARY:DECC$RTLDEF.TLB
   > SYS$LIBRARY:SYS$STARLET_C.TLB

The default for this qualifer is /NOINCLUDE_DIRECTORY.

### /INSTRUCTION_SET=[NO]FLOATING_POINT (ALPHA ONLY)

The /INSTRUCTION_SET=NOFLOATING_POINT qualifier suppresses the generation of floating-point instructions for integer operations.

The default is /INSTRUCTION_SET=FLOATING_POINT.

### /L_DOUBLE_SIZE=option (ALPHA ONLY)

Determines how the compiler interprets the `long double` type. The qualifier options are 64 and 128.

Specifying /L_DOUBLE_SIZE=64 treats all `long double` references as G_FLOAT, D_FLOAT, or T_FLOAT, depending on the value of the /FLOAT qualifier.

Specifying /L_DOUBLE_SIZE=128 treats all `long double` references as X_FLOAT.

The default is /L_DOUBLE_SIZE=128.

### /LIBRARY

Indicates that the associated input file is a library containing modules of Compaq C source text. If the library specification does not include a file extension, the CC command line assumes the .TLB default type. You must join the /LIBRARY qualifier with a file specification in a compilation unit using a plus sign (+); you cannot place the qualifier at other places on the CC command line. No matter where you place the /LIBRARY qualifier in a compilation unit, all files in the unit may make reference to modules within that library. Consider the following example:

    $ CC  ONE + TWO + THREE/LIBRARY[Return]

Files ONE.C and TWO.C can contain references to modules in THREE.TLB. Consider the following example:

    $ CC  ONE + TWO + THREE/LIBRARY, FOUR[Return]

The file FOUR.C cannot contain references to modules in THREE.TLB since FOUR.C is located in a separate compilation unit separated by a comma. The placement of the library file specification does not matter. The following command lines are equivalent:

    $ CC  THREE/LIBRARY + ONE + TWO[Return]
    $ CC  ONE + THREE/LIBRARY + TWO[Return]
    $ CC  ONE + TWO + THREE/LIBRARY[Return]

### /[NO]LINE_DIRECTIVES

Governs whether or not `#line` directives appear in preprocess output files.

The default is /LINE_DIRECTIVES.

### /[NO]LIST[=file-spec]

Produces a source program listing. You must specify this qualifier to get a listing. None of the other qualifiers use /LIST by default.

By default, /LIST creates a listing file with the same name as the source file and with a file extension of .LIS. If you include a file specification with the /LIST qualifier, the compiler uses that specification to name the listing file.

In interactive mode, the default is /NOLIST. In batch mode, the default is /LIST. See the descriptions of the qualifiers /[NO]MACHINE_CODE, and /SHOW for related information. (For example, to suppress compiler messages to the terminal or to a batch log file, use the /SHOW=NOTERMINAL qualifier.)

### /[NO]MACHINE_CODE[=option]

Lists the generated machine code in the listing file. To produce the listing file, you must also specify /LIST.

On OpenVMS VAX systems, several formats exist to list machine code. Table 1-10 describes the /MACHINE_CODE qualifier options.

Table 1-10 /MACHINE_CODE Qualifier Options (VAX ONLY)
Option | Usage
--- | ---
AFTER | Causes the lines of machine code produced during compilation to print after all the source code in the listing.
BEFORE | Causes lines of machine code produced during compilation to print before any source code in the listing.
INTERSPERSED | Produces a listing consisting of lines of source code followed by the corresponding lines of machine code. This is the default option.

On OpenVMS Alpha sytems, the format of the generated machine code listing is similar to what you would get using the AFTER keyword on OpenVMS VAX systems.

The default is /NOMACHINE_CODE.

### /[NO]MEMBER_ALIGNMENT

Controls whether the compiler naturally aligns data structure members. Natural alignment means that data structure members are aligned on the next boundary appropriate to the type of the member, rather than on the next byte. For instance, a `long` variable member is aligned on the next longword boundary; a `short` variable member is aligned on the next word boundary.

Any use of the `#pragma member_alignment` or `#pragma nomember_alignment` directives within the source code overrides the setting established by this qualifier. Specifying /NOMEMBER_ALIGNMENT causes data structure members to be byte-aligned (with the exception of bit-field members).

On OpenVMS Alpha systems, the default is /MEMBER_ALIGNMENT.

On OpenVMS VAX systems, the default is /NOMEMBER_ALIGNMENT.

See the description of `#pragma [no]member_alignment` in Section 5.4.11.

### /[NO]MMS_DEPENDENCIES[=(option[,...])]

Directs the compiler to produce a dependency file. Dependency files list all source files and included files for each object module. Note that the /OBJECT qualifier has no impact on the dependency file. The dependency file format is:

    object_file_name :<tab><source file name>)
    object_file_name :<tab><full path to first include file>)
    object_file_name :<tab><full path to second include file>)

Table 1-11 shows the /MMS_DEPENDENCIES qualifier options.

Table 1-11 /MMS_DEPENDENCIES Qualifier Options
Option | Usage
--- | ---
FILE[=filespec] | Specifies where to save the dependency file. The default file extension for a dependency file is `.mms` . Other than using this different default extension, /MMS_DEPENDENCY uses the same procedure that the /OBJECT and /LIST qualifiers do for determining the name of the output file.
[NO]SYSTEM_INCLUDE_FILES | Specifies whether or not to include dependency information about system include files (those included with `#include < filename>` .) If omitted, this option defaults to including dependency information about system include files.

The default is /NOMMS_DEPENDENCY.

### /NAMES=(option1,option2)

Option1 converts all definitions and references of external symbols and psects to the case specified. Table 1-12 lists the option1 case values.

Table 1-12 /NAMES Qualifier Option1 Values
Option | Usage
--- | ---
UPPERCASE | Converts to uppercase.
LOWERCASE | Converts to lowercase.
AS_IS | Leaves the case as specified in the source.

Option2 controls whether or not external names greater than 31 characters get truncated or shortened. Table 1-13 lists the option2 values.

Table 1-13 /NAMES Qualifier Option2 Values
Option | Usage
--- | ---
/NAMES=TRUNCATED (default) | Truncates long external names.
/NAMES=SHORTENED | Shortens long external names. A shortened name consists of the first 23 characters of the name followed by a 7-character Cyclic Redundancy Check (CRC) computed by looking at the full name, and then a "$".

The default is /NAMES=(UPPERCASE,TRUNCATED), which provides the same conversion-to-uppercase behavior as VAX C, and truncates the name to 31 characters.

Notes On OpenVMS VAX systems, the /NAMES qualifier does not affect the names of the $CODE and $DATA psects. On OpenVMS Alpha systems, the /NAMES qualifier does not affect the names of the $ABS$, $BSS$, $CODE$, $DATA$, $LINK$, $LITERAL$, and $READONLY$ psects. Specifying /NAMES=SHORTENED turns on the /REPOSITORY qualifier.

### /NESTED_INCLUDE_DIRECTORY[=option]

Controls the first step in the compiler's search algorithm for finding files that are included using the quoted form of the `#include` preprocessing directive:

    #include "file-spec"

Table 1-14 describes the /NESTED_INCLUDE_DIRECTORY qualifier options.

Table 1-14 /NESTED_INCLUDE_DIRECTORY Qualifier Options
Option | Usage
--- | ---
PRIMARY_FILE | Directs the compiler to search the default file type for headers using the context of the primary source file (the .C file). This means that just the file type (".h" or ".") is used for the default file-spec, but the chain of "related file-specs" used to maintain the sticky defaults for processing the next top-level source file is also applied when searching for the include file. This most closely matches the behavior of VAX C.
INCLUDE_FILE | Directs the compiler to first search the directory of the source file containing the `#include` directive. If the file to be included is not found, the compiler continues searching by following normal inclusion rules.
NONE | Directs the compiler to skip the first step of processing `#include " file.h"` directives. The compiler starts its search for the include file in the /INCLUDE_DIRECTORY directories. It does not start by looking in the directory containing the including file or in the directory containing the top level source file.

The default is /NESTED_INCLUDE_DIRECTORY=INCLUDE_FILE.

### /[NO]OBJECT[=file-spec]

Produces an object module. By default, /OBJECT creates an object module file with the same name as that of the first source file of a compilation unit and with the .OBJ file extension. If you include a file specification with /OBJECT, the compiler uses that specification instead.

The compiler executes faster if it does not have to produce an object module. Use the /NOOBJECT qualifier when you need only a listing of a program or when you want the compiler to check a source file for errors. The default is /OBJECT.

Note that the /OBJECT qualifier has no impact on the output file of the /MMS_DEPENDENCIES qualifier.

### /[NO]OPTIMIZE[=(option[,...])]

Determines whether Compaq C performs code optimizations.

You can specify the options described in Table 1-15.

Table 1-15 /OPTIMIZE Qualifier Options
Option | Usage
--- | ---
[NO]DISJOINT (VAX ONLY) | Optimizes the generated machine code. For example, the compiler eliminates common subexpressions, removes invariant expressions from loops, collapses arithmetic operations into 3-operand instructions, and places local variables in registers. When debugging Compaq C programs, use the /OPTIMIZE=NODISJOINT option if you need minimal optimization; if optimization during debugging is not important, use the /NOOPTIMIZE qualifier.
[NO]INLINE (VAX ONLY) | Provides automatic inline expansion of functions that yield optimized code when they are expanded. Whether or not a function is a candidate for inline expansion is based on its size, the number of times it is called, and whether it conforms to the rules specified in Section 5.4.8.
[NO]INLINE[= keyword] (ALPHA ONLY) | Provides inline expansion of functions that yield optimized code when they are expanded. Whether or not a function is a candidate for inline expansion is based on its size, the number of times it is called, and whether it conforms to the rules specified in Section 5.4.8. On OpenVMS Alpha systems, you can specify one of the following keywords to control inlining:
NONE | No inlining is done, even if requested by a `#pragma inline` preprocessor directive. /OPTIMIZE=INLINE=NONE is equivalent to /OPTIMIZE=NOINLINE.
MANUAL | Inlines only those function calls explicitly requested for inlining by a `#pragma inline` directive.
AUTOMATIC | Inlines all of the function calls in the MANUAL category, plus any additional calls that the compiler determines would improve run-time performance. This is the default.
ALL | Inlines every call that can be inlined while still generating correct code. Recursive routines, however, will not cause an infinite loop at compile time.
SIZE | Provides behavior similar to that of the keyword AUTOMATIC in versions of DEC C before 5.0, although it is somewhat more conservative in most cases. For DEC C Version 5.0 and higher, AUTOMATIC is treated as a synonym for SIZE. SIZE inlines functions when the compiler determines that it can improve run-time performance without significantly increasing the size of the program.
SPEED | Performs more aggressive inlining for run-time performance, even when it might significantly increase the size of the program.
The `#pragma noinline` preprocessor directive can be used to prevent inlining of any particular functions under the compiler-selected forms of inlining (SPEED, SIZE, or AUTOMATIC). The `#pragma inline` preprocessor directive (or the `__inline` storage-class modifier for OpenVMS Alpha systems) can be used to request inlining of specific functions under the AUTOMATIC or MANUAL forms of inlining.
[NO]INTRINSICS (ALPHA ONLY) | Controls whether or not certain functions are handled as intrinsic functions without explicitly enabling each of them as an intrinsic through the `#pragma intrinsic` preprocessor directive. An intrinsic function is an apparent function call that could be handled as an actual call to the specified function, or could be handled by the compiler in a different manner. By treating the function as an intrinsic, the compiler can often generate faster code. (Contrast with a built-in function, which is an apparent function call that is never handled as an actual function call. There is never a function with the specified name.) See Section 5.4.9 for a list of functions that can be handled as intrinsics. The /OPTIMZE=INTRINSICS qualifier works together with /OPTIMIZE=LEVEL=n and some other qualifiers to determine how intrinsics are handled: If the optimization level specified is less than 4, the intrinsic-function prototypes and call formats are checked, but normal run-time calls are still made. If the optimization level is 4 or higher, intrinsic code is generated. If /STANDARD=ANSI89 is specified, non-ANSI-Standard functions are not automatically intrinsic and do not even have their prototypes checked. They are only checked if the non-ANSI-Standard functions are made intrinsic through #pragma intrinsic. Intrinsic code is not generated for math functions that set the errno variable unless /ASSUME=NOMATH_ERRNO is specified. Such math functions, however, do have their prototypes and call formats checked. The default is /OPTIMIZE=INTRINSICS, which turns on this handling. To turn it off, specify /NOOPTIMIZE or /OPTIMIZE=NOINTRINSICS, or specify an optimization level less than 4.
LEVEL= n (ALPHA ONLY) | Selects the level of optimization. Specify an integer from 0 (no optimization) to 4 (full optimization):
0 | Disables all optimizations. Does not check for unassigned variables.
1 | Enables local optimizations and recognition of some common subexpressions. The call graph determines the order of compilation of procedures.
2 | Includes level 1 optimizations. Enables global optimization. This includes data-flow analysis, code motion, strength reduction and test replacement, split lifetime analysis, and code scheduling.
3 | Includes level 2 optimizations. Enables additional global optimizations that improve speed (at the cost of extra code size), for example: integer multiplication and division expansion (using shifts), loop unrolling, and code replication to eliminate branches.
4 | Includes level 3 optimizations. Enables interprocedural analysis and automatic inlining of small procedures (with heuristics limiting the amount of extra code). This is the default.
5 | Includes level 4 optimizations. Activates software pipelining, which is a specialized form of loop unrolling that in certain cases improves run-time performance. Software pipelining uses instruction scheduling to eliminate instruction stalls within loops, rearranging instructions between different unrolled loop iterations to improve performance. Loops chosen for software pipelining are always innermost loops and do not contain branches or procedure calls. To determine whether using level 5 benefits your particular program, you should time program execution for the same program compiled at levels 4 and 5. For programs that contain loops that exhaust available registers, longer execution times may result with level 5.
[NO]PIPELINE (ALPHA ONLY) | Controls Activation of the software pipelining optimization. The software pipelining optimization applies instruction scheduling to certain innermost loops, allowing instructions within a loop to "wrap around" and execute in a different iteration of the loop. This can reduce the impact of long-latency operations, resulting in faster loop execution. Software pipelining can be more effective when you combine /OPTIMIZE=PIPELINE with the appropriate /OPTIMIZE=TUNE keyword for the target Alpha processor generation. Software pipelining also enables the prefetching of data to reduce the impact of cache misses. Software pipelining is a subset of the optimizations activated by optimization level 5. To determine whether using /OPTIMIZE=PIPELINE benefits your particular program, you should time program execution for the same program (or subprogram) compiled with and without software pipelining. For programs containing loops that exhaust available registers, longer execution times can result with optimization level 5, requiring use of /OPTIMIZE=UNROLL= n to limit loop unrolling.
UNROLL= n (ALPHA ONLY) | Controls loop unrolling done by the optimizer. UNROLL= n means to unroll loop bodies n times, where n is between 0 and 16. UNROLL=0 means the optimizer will use its own default unroll amount. Specify UNROLL only at level 3 or higher.
TUNE= keyword (ALPHA ONLY) | Selects processor-specific instruction tuning for implementations of the Alpha architecture. Regardless of the setting of the /OPTIMIZE=TUNE flag, the generated code will run correctly on all implementations of the Alpha architecture. Tuning for a specific implementation can provide improvements in run-time performance. Code tuned for a specific target might run slower on another target. You can specify one of the following keywords:

||

GENERIC | Selects instruction tuning that is appropriate for all implementations of the Alpha architecture. This option is the default.

||

HOST | Selects instruction tuning that is appropriate for the machine on which the code is being compiled.

||

EV4 | Selects instruction tuning for the 21064, 21064A, 21066, and 21068 implementations of the Alpha architecture.

||

EV5 | Selects instruction tuning for the 21164 implementation of the Alpha architecture.

||

EV56 | Selects instruction tuning for the 21164 chip implementations that use the byte- and word-manipulation instruction extensions of the Alpha architecture. Running programs compiled with the EV56 keyword might incur emulation overhead on EV4 and EV5 processors, but will still run correctly on OpenVMS Version 7.1 (or higher).

||

PCA56 | Selects instruction tuning for the 21164PC implementation that uses the byte- and word-manipulation instruction extensions and multimedia instruction extensions of the Alpha architecture. Running programs compiled with the PCA56 keyword might incur emulation overhead on EV4, EV5, and EV56 processors, but will still run correctly on OpenVMS Version 7.1 (or higher).

||

EV6 | Selects instruction tuning for the first-generation 21264 implementation of the Alpha architecture.
EV67 | Selects instruction tuning for the second-generation 21264 implementation of the Alpha architecture.

Previous | Next | Contents | Index

privacy and legal statement