HP OpenVMS Systems Documentation
Porting Applications from HP OpenVMS Alpha to HP OpenVMS Industry Standard 64 for Integrity Servers
BLISS has added the following new compiler-state lexicals to support the OpenVMS I64 compilers: BLISS32I and BLISS64I.
The IPF calling standard requires that all global data objects with a size of 8 bytes or smaller be allocated in short data sections.
Short data sections can be addressed with an efficient code sequence that involves adding a 22-bit literal to the contents of the GP base register. This code sequence limits the combined size of all the short data sections. A linker error occurs if the total amount of data allocated to short data sections exceeds a size of 2**22 bytes. Compilers on IPF can use GP relative addressing when accessing short globals and short externals.
OpenVMS I64 BLISS exhibits new behavior for the PSECT attribute GP_RELATIVE and for the new PSECT attribute SHORT, which supports allocating short data sections.
Specifying the GP_RELATIVE keyword as a PSECT attribute causes PSECT to be labeled as containing short data so that the linker will allocate the PSECT close to the GP base address.
The syntax of the SHORT attribute is as follows:
The following rules apply to the SHORT attribute:
The following example shows the use of PSECT in BLISS code.
COBOL Version 2.8 is supported on both Alpha and I64. See the COBOL
Release Notes for restrictions and known problems related to using
COBOL on OpenVMS I64.
The COBOL compiler does not support /IEEE_MODE. The COBOL RTL sets up the run-time environment on I64 to be similar in terms of exception handling and rounding to what is provided in the COBOL run-time environment on Alpha.
The COBOL Release Notes and the white paper entitled "OpenVMS Floating-Point Arithmetic on the Intel® Itanium® Architecture" together describe how COBOL deals with floating-point issues on I64.
See the Related Documents section in the Preface for the web location
of this white paper and other OpenVMS-to-Itanium architecture resources.
For the sake of "compile-and-go" compatibility, Alpha values for the /ARCH and /OPTIMIZE=TUNE qualifiers are accepted by the COBOL compiler on I64. An informational message is displayed indicating that they are ignored.
I64 values for /ARCH and /OPTIMIZE=TUNE are defined in the COBOL
compiler for development purposes only. Their behavior is unpredictable
and they should not be used.
Fortran 90 V8.0 is supported on OpenVMS I64. Fortran 77 is not supported on OpenVMS I64. (See Section 6.5.2 for details.)
HP Fortran for OpenVMS I64 systems provides the same command-line
options and language features as HP Fortran for OpenVMS Alpha systems
with a few exceptions. These exceptions are discussed in the following
The Fortran release notes and the white paper entitled "OpenVMS Floating-Point Arithmetic on the Intel® Itanium® Architecture" together describe how HP Fortran for I64 deals with floating-point issues.
See the Related Documents section in the Preface for the web location of this white paper and other OpenVMS-to-Itanium architecture resources.
Highlights are summarized as follows:
As specified in the white paper, HP OpenVMS Floating-Point Arithmetic on the Itanium® Architecture, the number, type and location of floating-point exceptions raised during the execution of an application on I64 may not be the same as on Alpha. This is particularly true for VAX-format floating-point. In that case exceptions are (in general) only raised on the convert back to VAX-format after the computation is over.
Three consequences may be of interest for users of VAX-format floating-point:
6.5.2 Only the F90 Compiler is Supported
The F77 compiler, previously invoked with the /OLD_F77 qualifier, is not available. Development is currently underway to provide the following functionality contained in the Alpha F77 compiler that is not available in the I64 and Alpha F90 compilers:
6.5.3 /ARCH and /OPTIMIZE=TUNE Qualifiers
For the sake of "compile-and-go" compatibility, Alpha values for the /ARCH and /OPTIMIZE=TUNE qualifiers are accepted on the compiler invocation command. An informational message is printed saying they are ignored.
I64 values for /ARCH and /OPTIMIZE=TUNE are defined in the OpenVMS I64
compiler for development purposes only. Their behavior is unpredictable
and they should not be used.
HP C Version 7.1 is supported on I64 systems. Refer to the HP C
documentation, including the HP C Release Notes for details and
additional porting considerations.
The native Alpha compiler defaults to /FLOAT=G_FLOAT. For I64, the default is /FLOAT=IEEE_FLOAT/IEEE=DENORM.
On OpenVMS I64, there is no hardware support for floating-point representations other than IEEE. The VAX floating point formats are supported in the compiler by generating run-time code to convert to IEEE format in order to perform arithmetic operations, and then convert the IEEE result back to the appropriate VAX format. This imposes additional run-time overhead and a possible loss of accuracy compared to performing the operations in hardware on the Alpha (and VAX). The software support for the VAX formats is an important functional compatibility requirement for certain applications that deal with on-disk binary floating-point data, but its use should not be encouraged by letting it remain the default. This change is similar to the change in default from /FLOAT=D_FLOAT on VAX to /FLOAT=G_FLOAT on Alpha.
Note also that the default /IEEE_MODE has changed from FAST (on OpenVMS
Alpha) to DENORM_RESULTS on OpenVMS I64. This means that, by default,
floating-point operations silently generate values that print as
Infinity or Nan (the industry-standard behavior) instead of issuing a
fatal run-time error as they would using VAX format float or
/IEEE_MODE=FAST. Also, the smallest-magnitude nonzero value in this
mode is much smaller because results are permitted to enter the
denormal range instead of being flushed to zero as soon as the value is
too small to represent with normalization.
On OpenVMS Alpha, the /IEEE_MODE qualifier generally has its greatest effect on the generated code of a compilation. When calls are made between functions compiled with different /IEEE_MODE qualifiers, each function produces the /IEEE_MODE behavior with which it was compiled.
On OpenVMS I64, the /IEEE_MODE qualifier primarily affects only the setting of a hardware register at program startup. In general, the /IEEE_MODE behavior for a given function is controlled by the /IEEE_MODE option that was specified on the compilation that produced the main program. The compiler marks the object module of each compilation with the floating-point control options specified by the compile-time qualifiers. When the I64 linker produces an executable image, it copies the floating point controls from the object module that supplied the main entry point transfer address for the image into the image itself; this is called the "whole program floating-point mode" for the image. Then when the image is activated for execution, the hardware's floating-point controls are initialized according to this whole program floating point mode. It is expected that code that modifies the floating-point controls at run-time will be written to ensure that the whole program floating point mode settings get restored whenever control passes out of the section of code that required the specific setting of the controls at run-time.
When the /IEEE_MODE qualifier is applied to a compilation that does not contain a main program, the qualifier does have some effect: it can affect the evaluation of floating-point constant expressions, and it is used to set the EXCEPTION_MODE used by the math library for calls from that compilation.
The qualifier has no effect on the exceptional behavior of floating-point calculations generated as inline code for that compilation. Therefore, if floating point exceptional behavior is important to an application, all of its compilations, including the one containing the main program, should be compiled with the same /FLOAT and /IEEE_MODE settings.
Note that even on Alpha, setting /IEEE_MODE=UNDERFLOW_TO_ZERO requires the setting of a run-time status register; therefore, this setting needs to be specified on the compilation containing the main program in order to be effective in other compilations.
Finally, note that the /ROUNDING_MODE qualifier is affected in the same
way as /IEEE_MODE, and is included in the whole program floating-point
mode, and that because VAX floating point operations are actually
performed using IEEE instructions, compilations that use VAX format
floating-point exhibit the same whole program floating-point mode
settings as compilations with /IEEE_MODE=DENORM/ROUND=NEAREST.
The compiler predefines a number of macros with the same meanings as in the native Alpha compiler, except that it does not predefine any of the macros that specify the Alpha architecture. Instead, it predefines the macros __ia64 and __ia64__ , as is the practice in the Intel and gcc compilers for I64. The change in floating-point representation from G_FLOAT to IEEE is reflected in the macros that are predefined by default.
Some users have tried defining the macro
explicitly by using /DEFINE or by putting it in a header file as a
quick way to deal with source code conditionals that were written to
assume that if
is not defined, then the target must be a VAX system. Doing this causes
the CRTL headers and other OpenVMS headers to take the wrong path for
I64. You must not define any of the Alpha architecture predefined
macros when using this compiler.
HP C++ Version 7.1 is supported on OpenVMS I64. Refer to the HP C++
documentation for details and additional porting considerations.
Exactly the same considerations for floating-point defaults, /IEEE_MODE
semantics, and predefined macros as described for the C compiler above
apply to the C++ compiler.
The long double type is always represented in 128-bit IEEE quad
precision. The /L_DOUBLE_SIZE=64 qualifier is ignored with a warning.
Note that on Alpha, C++ library support for 64-bit lon double was
limited - code that requires a 64-bit floating point type should use
double instead of long double.
The object model and name mangling schemes used by the C++ compiler on
I64 differ significantly from those used on Alpha. The "ARM" object
model is not available, the only object model is one that supports the
ANSI/ISO C++ standard. However, this still differs from the /MODEL=ANSI
object model implemented on Alpha, as the model on I64 is an
implementation of the industry-standard I64 ABI. Programs that rely on
the layout of C++ objects (non "POD" data), or on the external mangles
names as encoded in the .obj file, will need to be reworked. Such
programs are inherently highly implementation-dependent. But programs
that use standard C++ features in a reasonable
implementation-independent manner should not have difficulty in porting.
The "cfront" dialect is no longer supported (and will be removed from
Alpha as well). Compilations specifying /standard=cfront will instead
use the "relaxed_ansi" dialect.
On OpenVMS I64, .OBJ files are implemented in ELF format rather than EOBJ, and along with the I64 linker they support the notion of "COMDAT" sections that have been used for some time on both Windows and Unix platforms to resolve the issues of duplicate definitions at link-time that arise when using C++ templates and inline functions. On Alpha, these issues are handled by the repository mechanism, which arranges to present a single defining instance to the linker. On I64, no repository mechanism is needed to do this, as duplicates are discarded by the linker automatically. So the repository-based template instantiation options supported on Alpha are not supported on IPF. Alpha build procedures that attempt to manipulate objects in the repository will fail on I64 and will need to be changed (because there are no objects in the repository on I64, just the demangler database). In most cases, the reason for manipulating the repository directly in the build procedure has been eliminated by the compiler's use of COMDAT instantiation.