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.

• %BLISS now recognizes BLISS32V, BLISS32E, BLISS64E, BLISS32I and BLISS64I.
  %BLISS(BLISS32) is true for all 32-bit BLISS compilers.
  %BLISS(BLISS32V) is true only for VAX BLISS (BLISS-32).
  %BLISS(BLISS32E) is true for all 32-bit Alpha compilers.
  %BLISS(BLISS64E) is true for all 64-bit Alpha compilers.
  %BLISS(BLISS32I) is true for all 32-bit I64 compilers.
  %BLISS(BLISS64I) is true for all 64-bit I64 compilers.
• The lexicals %BLISS32I and %BLISS64I have been added. Their behavior parallels that of the new parameters to %BLISS.
• Support for the Intel Itanium architecture as a keyword to the %HOST and %TARGET lexicals has been added for OpenVMS I64 BLISS.

OpenVMS I64 BLISS Support for IPF Short Data Sections

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:

• If the PSECT name in a SHORT attribute is not yet declared then its appearance in a SHORT attribute constitutes a declaration. The attributes of the PSECT containing the SHORT attribute become the attributes of the PSECT named in the SHORT attribute, except that the PSECT name declared in the SHORT attribute does not have the SHORT attribute and the PSECT name declared in the SHORT attribute does have the GP_RELATIVE attribute.
• If the PSECT name in a SHORT attribute has been previously declared then its attributes are not changed. A warning message is generated if the PSECT named in a SHORT attribute does not have the GP_RELATIVE attribute.
• If a data object with storage class OWN, GLOBAL or PLIT has a size of 8 or fewer bytes and the data object is specified to be allocated to a PSECT that includes the SHORT attribute, then that object is allocated to the PSECT named in the SHORT attribute. Note that this is a one-step process that is not recursive. If a short data object has it allocation PSECT renamed by the SHORT attribute, then the SHORT attribute of the renamed PSECT is not considered for any further renaming.
• Data objects with sizes larger then 8 bytes ignore the SHORT attribute.
• Data objects in the CODE, INITIAL and LINKAGE storage classes ignore the SHORT attribute, regardless of their size.
• For the purposes of PSECT renaming by means of the SHORT attribute, the size of a PLIT object does not include the size of the count word that precedes the PLIT data.

Example

The following example shows the use of PSECT in BLISS code.

PSECT

  NODEFAULT = $GLOBAL_SHORT$
    (READ,WRITE,NOEXECUTE,NOSHARE,NOPIC,CONCATENATE,LOCAL,ALIGN(3),
    GP_RELATIVE),

! The above declaration of $GLOBAL_SHORT$ is not needed.  If the above
! declaration were deleted then the SHORT($GLOBAL_SHORT$) attribute in
! the following declaration would implicitly make an identical
! declaration of $GLOBAL_SHORT$.

  GLOBAL = $GLOBAL$
    (READ,WRITE,NOEXECUTE,NOSHARE,NOPIC,CONCATENATE,LOCAL,ALIGN(3),
    SHORT($GLOBAL_SHORT$)),

  NODEFAULT = MY_GLOBAL
    (READ,WRITE,NOEXECUTE,SHARE,NOPIC,CONCATENATE,LOCAL,ALIGN(3)),

  PLIT = $PLIT$
    (READ,NOWRITE,NOEXECUTE,SHARE,NOPIC,CONCATENATE,GLOBAL,ALIGN(3),
    SHORT($PLIT_SHORT$));

GLOBAL
        X1,                     ! allocated in $GLOBAL_SHORT$
        Y1 : VECTOR[2,LONG],    ! allocated in $GLOBAL_SHORT$
        Z1 : VECTOR[3,LONG],    ! allocated in $GLOBAL$
        A1 : PSECT(MY_GLOBAL),  ! allocated in MY_GLOBAL
        B1 : VECTOR[3,LONG] PSECT(MY_GLOBAL), ! allocated in MY_GLOBAL
        C1 : VECTOR[3,LONG]
                PSECT($GLOBAL_SHORT$); ! allocated in $GLOBAL_SHORT$

PSECT GLOBAL = MY_GLOBAL;
! use MY_GLOBAL as default for both noshort/short

GLOBAL
        X2,                     ! allocated in MY_GLOBAL
        Y2 : VECTOR[2,LONG],    ! allocated in MY_GLOBAL
        Z2 : VECTOR[3,LONG],    ! allocated in MY_GLOBAL
        A2 : PSECT($GLOBAL$),   ! allocated in $GLOBAL_SHORT$
        B2 : VECTOR[3,LONG] PSECT($GLOBAL$); ! allocated in $GLOBAL$;

! Note that the allocations of A1, X2 and Y2 violate the calling
! standard rules.  These variables cannot be shared with other
! languages, such as C or C++.

PSECT GLOBAL = $GLOBAL$;
! back to using $GLOBAL$/$GLOBAL_SHORT$ as default noshort/short

GLOBAL BIND
        P1 = UPLIT("abcdefghi"),        ! allocated in $PLIT$
        P2 = PLIT("abcdefgh"),          ! allocated in $PLIT_SHORT$
        P3 = PSECT(GLOBAL) PLIT("AB"),  ! allocated in $GLOBAL_SHORT$
        p4 = PSECT($PLIT_SHORT$)
                PLIT("abcdefghijklmn"), ! allocated in $PLIT_SHORT$
        P5 = PSECT(MY_GLOBAL) PLIT("AB"); ! allocated in MY_GLOBAL

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.

6.4.1 Floating-Point Arithmetic

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.

6.4.2 /ARCH and /OPTIMIZE=TUNE Qualifiers

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.

6.5 Fortran

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 sections.

6.5.1 Floating-Point Arithmetic

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:

• IEEE is the default floating-point datatype (that is, the default is /FLOAT=IEEE_FLOAT).
  The OpenVMS Alpha compiler defaults to /FLOAT=G_FLOAT. On OpenVMS I64 systems, 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 before performing arithmetic operations, and then converting the IEEE result back to the appropriate VAX format. This imposes additional run-time overhead and some loss of accuracy compared to performing the operations in hardware on Alpha (and VAX).
  The software support for the VAX formats is an important functional compatibility requirement for certain applications that need to deal with on-disk binary floating-point data, but its use should not be encouraged. This change is similar to the change in default from /FLOAT=D_FLOAT on VAX to /FLOAT=G_FLOAT on Alpha.
  If at all possible, users should use /FLOAT=IEEE_FLOAT (the default) for the highest performance and accuracy.
  Note that the changed /FLOAT default has implications for the use of /CONVERT=NATIVE (the default). This switch causes unformatted data to remain unconverted on input, on the assumption that it matches the prevailing floating-point datatype.
  Files written from Fortran applications built with /FLOAT=G_FLOAT/CONVERT=NATIVE on Alpha (either explicitly G_FLOAT and NATIVE or defaulting either or both) will be in G_FLOAT. They can be read by I64 applications built with /FLOAT=G_FLOAT/CONVERT=NATIVE or /FLOAT=IEEE/CONVERT=VAXG. But they will not be readable by applications build with /CONVERT=NATIVE, as that will default to the /FLOAT type, which will have defaulted to IEEE.
• The /IEEE_MODE qualifier defaults to /IEEE_MODE=DENORM_RESULTS.
  This differs from Alpha, where the default is /IEEE_MODE=FAST. Despite the name, /IEEE_MODE=FAST does not have a significant effect on run-time performance on I64 (or on Alpha processors from EV6 onward).
• Users must choose one /FLOAT value and one /IEEE_MODE value and stick with it for the whole of their application. This is because mixed-mode applications do not (in general) work on OpenVMS I64 systems as a result of architectural differences in the hardware. This is a change from OpenVMS on Alpha systems, where mixed-mode applications work. In particular, per-routine/per-file/per-library settings of a mode do not work.
  As on Alpha, /IEEE_MODE can only be set if the user has chosen or defaulted to /FLOAT=IEEE. The IEEE_MODE used for G_FLOAT and D_FLOAT is one the compiler has picked as appropriate for supporting the IEEE-format calculations which implement VAX-format support.
• If your code changes the floating-point exception mode, it is your responsibility to change it back on routine exit, including exits by means of exception handlers. Failure to do so might lead to unexpected results, since the compilers assume that no called routine changes the current mode. This is also a requirement on user-written libraries.
• Exception handlers are entered with the floating-point mode in effect at the time the exception was raised, not the mode with which the handler was compiled.

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:

• Intermediate values (such as the "X/Y" in "X*Y + X/Y" which could have raised an exception on Alpha will probably not raise an exception on I64.
• Values not converted back to VAX-format floating-point (such as the "X/Y" in "IF (X/Y > 0.0)" will probably not raise an exception on I64.
• OpenVMS Alpha and VAX Fortran applications do not report underflows for VAX-format floating-point operations unless you specifically enable underflow traps by compiling with the /CHECK=UNDERFLOW qualifier. The same is true on OpenVMS I64 systems, but with an important caveat.
  Since all I64 floating-point operations are implemented using IEEE-format operations, enabling underflow traps with /CHECK=UNDERFLOW causes exceptions to be raised when values underflow the IEEE-format representation, not the VAX-format one.
  This can result in an increased number of underflow exceptions seen with /CHECK=UNDERFLOW when compared with equivalent Alpha or VAX programs, as the computed values may be in the valid VAX-format range, but in the denormalized IEEE-format range.

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:

• CDD and FDML support, which were previously available only in the Alpha F77 compiler, have now been implemented in the I64 Fortran 90 compiler.
• Code previously compiled with the F77 compiler that does not compile with the F90 compiler should be reported through the problem reporting mechanism. Although it may not be possible to eliminate all differences, the HP development team has attempted to minimize these differences by enhancing the F90 compiler.

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.

6.6 HP C/ANSI C

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.

6.6.1 I64 Floating-Point Default

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.

6.6.2 Semantics of /IEEE_MODE Qualifier

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.

6.6.3 Predefined Macros

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 __ALPHA 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 __ALPHA 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.

6.7 HP C++

HP C++ Version 7.1 is supported on OpenVMS I64. Refer to the HP C++ documentation for details and additional porting considerations.

6.7.1 Floating Point and Predefined Macros

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.

6.7.2 Long Double

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.

6.7.3 Object Model

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.

6.7.4 Language Dialects

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.

6.7.5 Templates

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.