| Previous | Contents | Index |
The /INTEGER_SIZE qualifier controls how the compiler interprets INTEGER or LOGICAL declarations that do not have a specified length. The default is INTEGER_SIZE=32.
The qualifier has the following form:
|
/INTEGER_SIZE=
|
16
Indicates that INTEGER declarations are interpreted as INTEGER (KIND=2) and LOGICAL declarations as LOGICAL (KIND=2). Same as the obsolete /NOI4 qualifier.32
Indicates that INTEGER declarations are interpreted as INTEGER (KIND=4) and LOGICAL declarations as LOGICAL (KIND=4). Same as the obsolete /I4 qualifier.64
Indicates that INTEGER declarations are interpreted as INTEGER (KIND=8) and LOGICAL declarations as LOGICAL (KIND=8)
For performance reasons, use INTEGER (KIND=4) data instead of INTEGER (KIND=2) or INTEGER (KIND=1) and whenever possible. You must explicitly declare INTEGER (KIND=1) data.
To improve performance, use /INTEGER_SIZE=32 rather than /INTEGER_SIZE=16 and declare variables as INTEGER (KIND=4) (or INTEGER (KIND=8)) rather than INTEGER (KIND=2) or INTEGER (KIND=1). For logical data, avoid using /INTEGER_SIZE=16 and declare logical variables as LOGICAL (KIND=4) rather than LOGICAL (KIND=2) or LOGICAL (KIND=1). |
The /LIBRARY qualifier specifies that a file is a text library file.
The qualifier has the following form:
|
text-library-file/LIBRARY |
The /LIBRARY qualifier can be specified on one or more text library files in a list of files concatenated by plus signs (+). At least one of the files in the list must be a nonlibrary file. The default file type is TLB.
The /LIST qualifier requests a source listing file. You can request additional listing information using the /MACHINE_CODE and /SHOW qualifiers.
The qualifier has the following form:
|
/LIST[=file-spec] |
You can include a file specification for the listing file. If you omit the file specification, the listing file has the name of the first source file and a file type of LIS.
The default depth of a page in a listing file is 66 lines. To modify the default, assign the new number to the logical name SYS$LP_LINES, using the DCL command DEFINE. For example, the following DCL command sets the page depth at 88 lines:
$ DEFINE SYS$LP_LINES 88 |
The valid number of lines per page ranges from 30 to a maximum of 255. The definition can be applied to the entire system by using the command DEFINE/SYSTEM.
In interactive mode, the compiler does not produce a listing file unless you include the /LIST qualifier. In batch mode, the compiler produces a listing file by default. In either case, the listing file is not automatically printed; you must use the PRINT command to obtain a line printer copy of the listing file.
If a source line contains a form-feed character, that line is printed but the form-feed character is ignored (does not generate a new page).
Any other nonprinting ASCII characters encountered in HP Fortran source files are replaced by a space character, and a warning message appears.
You can request additional information in the listing file using the /MACHINE_CODE and /SHOW qualifiers.
The listing file includes the HP Fortran version number.
The /ANNOTATIONS qualifier controls whether an annotated listing showing optimizations is included with the listing file.
Specifying /MACHINE_CODE requests that the listing file include a symbolic representation of the OpenVMS object code generated by the compiler. Generated code and data are represented in a form similar to an assembly code listing. The code produced by the /MACHINE_CODE qualifier is for informational purposes only. It is not intended to be assembled and is not supported by the MACRO assembler.
If a listing file is not being generated, the /MACHINE_CODE qualifier is ignored.
The default is /NOMACHINE_CODE.
If you omit /MATH_LIBRARY=FAST (and /FAST), the compiler uses the standard, very accurate math library routines for each HP Fortran intrinsic function, such as SQRT (default is /MATH_LIBRARY=ACCURATE).
Specify /MATH_LIBRARY=FAST to use a special version of certain math library routines that produce faster results, but with a slight loss of precision and less exception checking.
This qualifier applies only to IEEE data types (when you specify /FLOAT=IEEE_FLOAT). The qualifier has the following form:
|
/MATH_LIBRARY=
|
ACCURATE
On Alpha systems, using /MATH_LIBRARY=ACCURATE (the default if you omit /FAST) produces the very accurate results and error checking expected of quality compiler products. It uses the standard set of math library routines for the applicable intrinsics.The standard math library routines are designed to obtain very accurate "near correctly rounded" results and provide the robustness needed to check for IEEE exceptional argument values, rather than achieve the fastest possible run-time execution speed. Using /MATH_LIBRARY=ACCURATE allows user control of arithmetic exception handling with the /IEEE_MODE qualifier.
FAST
Specifying /MATH_LIBRARY=FAST (the default if you specify /FAST) use versions of certain math library routines that perform faster computations than the standard, more accurate math library routines, but with slightly less fractional accuracy and less reliable arithmetic exception handling. Using /MATH_LIBRARY=FAST allows certain math library functions to get significant performance improvements when the applicable intrinsic function is used.If you specify /MATH_LIBRARY=FAST, the math library routines do not necessarily check for IEEE exceptional values and the /IEEE_MODE qualifier is ignored.
When you use MATH_LIBRARY=FAST, you should carefully check the calculated output from your program. Check the program's calculated output to verify that it is not relying on the full fractional accuracy of the floating-point data type (see Section 8.4) to produce correct results or producing unexpected exceptional values (exception handling is indeterminate).
Programs that do not produce acceptable results with /MATH_LIBRARY=FAST and single-precision data might produce acceptable results with /MATH_LIBRARY=FAST if they are modified (or compiled) to use double-precision data.
The specific intrinsic routines that have special fast math routines depend on the version of the OpenVMS operating system in use. Allowed error bounds vary with each routine.
The /MODULE qualifier controls where module files (.F90$MOD) are placed. If you omit this qualifier or specify /NOMODULE, the .F90$MOD files are placed in your current default directory.
The qualifier has the following form
|
/MODULE=directory |
If you specify this qualifier, .F90$MOD files are placed in the
specified directory location.
2.3.32 /NAMES --- Control Case of External Names
The /NAMES qualifier specifies how the HP Fortran compiler represents external (global) names to the linker.
The qualifier has the following form:
|
/NAMES=
|
UPPERCASE
Causes the compiler to ignore case differences in identifiers and to convert external names to uppercase. This is the default.LOWERCASE
Causes the compiler to ignore case differences in identifiers and to convert external names to lowercase.AS_IS
Causes the compiler to distinguish case differences in identifiers and to preserve the case of external names.
The default, /NAMES=UPPERCASE, means that HP Fortran converts external names to uppercase.
The /OBJECT qualifier specifies the name of the object file or prevents object file creation.
The qualifier has the following form:
|
/OBJECT[=file-spec] |
The default is /OBJECT. If you omit the file specification, the object file has the name of the first source file and a file type of OBJ.
Use /NOOBJECT to suppress object code (for example, when you want to test only for compilation errors in the source program).
On using the /OBJECT qualifier, see Section 2.2.5.
2.3.34 /OLD_F77 --- Use Old FORTRAN 77 Compiler (Alpha only)
To use the Compaq Fortran 77 compiler, specify /OLD_F77 as the first qualifier on the FORTRAN command line. The default is to use the HP Fortran (90/95 language) compiler. The default HP Fortran compiler supports the FORTRAN 77 language as well as the Fortran 90 and Fortran 95 standards.
If you specify the /OLD_F77 qualifier, certain FORTRAN command
qualifiers will be ignored, including qualifiers associated with
Fortran 90 and Fortran 95 features, Fortran 90 and 95 standards
checking, and certain optimization keywords.
2.3.35 /OPTIMIZE --- Specify Compiler Optimizations
The /OPTIMIZE qualifier requests that the compiler produce optimized code.
The qualifier has the following form:
|
/OPTIMIZE=
|
The default is /OPTIMIZE, which is equivalent to /OPTIMIZE=LEVEL=4. Use /NOOPTIMIZE or /OPTIMIZE=LEVEL=0 for a debugging session to ensure that the debugger has sufficient information to locate errors in the source program.
In most cases, using /OPTIMIZE will make the program execute faster. As a side effect of getting the fastest execution speeds, using /OPTIMIZE can produce larger object modules and longer compile times than /NOOPTIMIZE.
To allow full interprocedure optimization when compiling multiple source files, consider separating source file specifications with plus signs (+), so the files are concatenated and compiled as one program. Full interprocedure optimization can reduce overall program execution time (see Section 5.1.2). Consider not concatenating source files when the size of the source files is excessively large and the amount of memory or disk space is limited.
The /OPTIMIZE keywords follow:
LEVEL
You can specify the optimization level with /OPTIMIZE=LEVEL=n, where n is from 0 to 5, as follows:
- LEVEL=0 disables nearly all optimizations. Specifying LEVEL=0 causes the /WARNINGS=UNUSED qualifier to be ignored.
This provides the same inlining as /OPTIMIZE=INLINE=NONE.- LEVEL=1 enables local optimizations within the source program unit, recognition of common subexpressions, and integer multiplication and division expansion (using shifts).
- LEVEL=2 enables global optimizations and optimizations performed with LEVEL=1. Global optimizations include data-flow analysis, code motion, strength reduction and test replacement, split-lifetime analysis, and instruction scheduling.
This provides the same inlining as /OPTIMIZE=INLINE=MANUAL.- LEVEL=3 enables additional global optimizations that improve speed (at the cost of extra code size) and optimizations performed with LEVEL=2. Additional global optimizations include:
- Loop unrolling
- Code replication to eliminate branches
- LEVEL=4 enables interprocedure analysis, automatic inlining of small procedures (with heuristics limiting the amount of extra code), the software pipelining optimization (also set by /OPTIMIZE=PIPELINE), and optimizations performed with LEVEL=3. LEVEL=4 is the default.
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 also enables the prefetching of data to reduce the impact of cache misses.
For more information on software pipelining, see the PIPELINE keyword in this section.
This provides the same inlining as /OPTIMIZE=INLINE=SPEED.- LEVEL=5 activates the loop transformation optimizations (also set by /OPTIMIZE=LOOPS).
- The loop transformation optimizations are a group of optimizations that apply to array references within loops. These optimizations can improve the performance of the memory system and can apply to multiple nested loops.
Loop transformation optimizations include loop blocking, loop distribution, loop fusion, loop interchange, loop scalar replacement, and outer loop unrolling.
To specify loop transformation optimizations without software pipelining, do one of the following:
- Specify LEVEL=5 with NOPIPELINE (preferred method)
- Specify LOOPS with LEVEL=4, LEVEL=3, or LEVEL=2. This optimization is not performed at optimization levels below LEVEL=2.
For more information on the loop transformation optimizations, see the LOOPS keyword in this section.
In addition to loop transformation, specifying LEVEL=5 activates certain optimizations that are not activated by LOOPS and PIPELINE, including byte-vectorization, and insertion of additional NOP (No Operation) instructions for alignment of multi-issue sequences.
To determine whether using LEVEL=5 benefits your particular program, you should time program execution for the same program compiled at LEVEL=4 and LEVEL=5 (see Section 5.2).
For programs that contain loops that exhaust available registers, longer execution times may result with /OPTIMIZE=LEVEL=5, requiring use of /OPTIMIZE=UNROLL=n to limit loop unrolling (see the UNROLL keyword in this section).
Specifying LEVEL=5 implies the optimizations performed at LEVEL=1, LEVEL=2, LEVEL=3, and LEVEL=4.
This provides the same inlining as /OPTIMIZE=INLINE=SPEED.INLINE
You can specify the level of inlining with /OPTIMIZE=INLINE=xxxxx, where xxxx is one of the following keywords:
- NONE (same as /OPTIMIZE=NOINLINE) prevents any procedures from being inlined, except statement functions, which are always inlined. This type of inlining occurs if you specify /OPTIMIZE=LEVEL=0, LEVEL=1, LEVEL=2, or LEVEL=3 and omit /OPTIMIZE=INLINE=keyword.
- MANUAL is the same as NONE for HP Fortran (but not necessarily for other OpenVMS languages). This type of inlining occurs if you specify /OPTIMIZE=LEVEL=0, LEVEL=1, LEVEL=2, or LEVEL=3 and omit /OPTIMIZE=INLINE=keyword.
- SIZE inlines procedures that will improve run-time performance without significantly increasing program size. This type of inlining is relevant at /OPTIMIZE=LEVEL=1 or higher.
- SPEED inlines procedures that will improve run-time performance with a significant increase in program size. This type of inlining is relevant at /OPTIMIZE=LEVEL=1 or higher. INLINE=SPEED occurs if you specify /OPTIMIZE=LEVEL=4 or LEVEL=5 and omit /INLINE=keyword.
- ALL inlines every call that can possibly be inlined while generating correct code, including the following:
- Statement functions (NONE or MANUAL)
- Any procedures that HP Fortran thinks will improve run-time performance (SPEED)
- Any other procedures that can possibly be inlined and generate correct code. Certain recursive routines are not inlined to prevent infinite loops.
This type of inlining is relevant at /OPTIMIZE=LEVEL=1 or higher.NOINLINE
Same as INLINE=NONE.LOOPS
Specifying /OPTIMIZE=LOOPS (or /OPTIMIZE=LEVEL=5) activates a group of loop transformation optimizations that apply to array references within loops. These optimizations can improve the performance of the memory system and usually apply to multiple nested loops. The loops chosen for loop transformation optimizations are always counted loops (which include DO or IF loops, but not uncounted DO WHILE loops).Conditions that typically prevent the loop transformation optimizations from occurring include subprogram references that are not inlined (such as an external function call), complicated exit conditions, and uncounted loops.
The types of optimizations associated with /OPTIMIZE=LOOPS include the following:
- Loop blocking
- Loop distribution
- Loop fusion
- Loop interchange
- Loop scalar replacement
- Outer loop unrolling
The loop transformation optimizations are a subset of optimizations activated by /OPTIMIZE=LEVEL=5. Instead of specifying both LOOPS and PIPELINE, you can specify /OPTIMIZE=LEVEL=5.
To specify loop transformation optimizations without software pipelining, do one of the following:
- Specify LEVEL=5 with NOPIPELINE (preferred method)
- Specify LOOPS with LEVEL=3 or LEVEL=2. This optimization is not performed at optimization levels below LEVEL=2.
To determine whether using /OPTIMIZE=LOOPS benefits your particular program, you should time program execution for the same program (or subprogram) compiled with and without loop transformation optimizations (such as with /OPTIMIZE=LOOPS and /OPTIMIZE=NOLOOPS).
PIPELINE
Specifying /OPTIMIZE=PIPELINE (or /OPTIMIZE=LEVEL=4) activates 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.For this version of HP Fortran, loops chosen for software pipelining are always innermost loops and do not contain branches, procedure calls, or COMPLEX floating-point data.
On Alpha systems, software pipelining can be more effective when you combine /OPTIMIZE=PIPELINE with the appropriate /OPTIMIZE=TUNE=xxxx keyword for the target Alpha processor generation (see the TUNE keyword in this section).
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 /OPTIMIZE=LEVEL=4.
To specify software pipelining without loop transformation optimizations, do one of the following:
- Specify LEVEL=4 with NOLOOPS (preferred method)
- Specify PIPELINE with LEVEL=3 or LEVEL=2. This optimization is not performed at optimization levels below LEVEL=2.
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 (such as with /OPTIMIZE=PIPELINE and /OPTIMIZE=NOPIPELINE).
For programs that contain loops that exhaust available registers, longer execution times may result with /OPTIMIZE=LEVEL=5, requiring use of /OPTIMIZE=UNROLL=n to limit loop unrolling (see the UNROLL keyword in this section).
TUNE (Alpha only)
You can specify the types of processor-specific instruction tuning for implementations of the Alpha architecture using the /OPTIMIZE=TUNE=xxxx keywords. Regardless of the setting of /OPTIMIZE=TUNE=xxxx you use, the generated code runs correctly on all implementations of the Alpha architecture. Tuning for a specific implementation can improve run-time performance; it is also possible that code tuned for a specific target may run slower on another target.The /OPTIMIZE=TUNE=xxxx keywords are as follows:
- GENERIC generates and schedules code that will execute well for all generations of Alpha processor chips. This provides generally efficient code for those cases where both processor generations are likely to be used. If /FAST is specified, the default is HOST; otherwise, the default is GENERIC.
- HOST generates and schedules code optimized for the processor generation in use on the system being used for compilation.
- EV4 generates and schedules code optimized for the 21064, 21064A, 21066, and 21068 implementations of the Alpha chip.
- EV5 generates and schedules code optimized for the 21164 implementation of the Alpha chip. This processor generation is faster and more recent than the implementations of the Alpha chip associated with EV4 (21064, 21064A, 21066, and 21068).
- EV56 generates and schedules code optimized for some 21164 Alpha architecture implementations that use the BWX (Byte/Word manipulation) instruction extensions of the Alpha architecture.
- PCA56 generates and schedules code optimized for 21164PC Alpha architecture implementation that uses BWX (Byte/Word manipulation) and MAX (Multimedia) instructions extensions.
- EV6 generates and schedules code optimized for the 21264 chip implementation that uses the following extensions to the base Alpha instruction set: BWX (Byte/Word manipulation) and MAX (Multimedia) instructions, square root and floating-point convert instructions, and count instructions.
- EV67 generates and schedules code optimized for the EV67 Alpha architecture implementation that uses BWX (Byte/Word manipulation), MVI (Multimedia) instructions, square root and floating-point convert extensions (FIX), and count extensions (CIX).
If /OPTIMIZE=TUNE=xxxx specifies a processor of less functionality than is specified by /ARCHITECTURE, code is optimized for the processor specified by /ARCHITECTURE.
Previous Next Contents Index