HP OpenVMS Calling Standard

Contents

Index

Appendix C
Summary of Differences from the Intel Itanium Software Conventions

The OpenVMS Calling Standard on the Intel Itanium processor family is designed to follow the Intel Itanium software conventions as much as possible while avoiding user-visible differences from the OpenVMS VAX and Alpha conventions. The design methodology was basically to start with the Intel Itanium conventions and make changes only where it was deemed necessary to maintain compatibility with the historical OpenVMS design in ways that minimize the cost and difficulty of porting applications and OpenVMS itself to the Intel Itanium architecture.

Following is a brief summary of the differences between the Itanium® Software Conventions and Runtime Architecture Guide and this Calling Standard. This summary assumes the reader is already familiar with the Intel Itanium processor family and related software specifications.

C.1 Changes

Data Model---OpenVMS on Alpha systems is deliberately ambiguous about the data model in use: many programs are compiled using what appears to be an ILP32 model, yet most of the system operates as though using either a P64 or LP64 model. The sign extension rules for integer parameters play a key role in making this more or less transparent. OpenVMS I64 preserves this characteristic, while the Itanium conventions define a pure LP64 data model.

Data Terminology---This specification uses the terms word and quadword to mean 2 bytes and 8 bytes, respectively, while the Itanium terminology uses these words to mean 4 bytes and 16 bytes respectively.

General Register Usage---General registers are used for integer arithmetic, some parts of VAX floating-point emulation, and other general-purpose computation. OpenVMS uses the same (default) conventions for these registers except for the following cases:

R8 and R9 (only) are used for return values.
R10 and R11 are used as scratch registers and not for return values.
R25 is used for an AI (argument information) register.

Floating-Point Register Usage---Floating-point registers are used for floating-point computations, some parts of VAX floating-point emulation, and certain integer computations. OpenVMS uses the same (default) conventions for these registers except for the following cases:

F8 and F9 (only) are used for return values.
F10 through F15 are used as scratch registers and not for return values.

Parameter Passing---OpenVMS parameter passing is similar to the Itanium conventions, but with the following differences:

Add an argument information register (for argument count and parameter type information).
No argument is ever duplicated in both general and floating-point registers.
For parameters that are passed in registers, the first parameter is passed in either the first general register slot (R32) or the first floating point register slot (F8), the second parameter in either the second general register slot (R33) or second floating register (F9) slot, and so on. Floating point parameters are not packed into the available floating point registers and at most eight parameters total are passed in registers.
For 32-bit parameters passed in the general registers, the 32-bit value is sign-extended to the full 64-bit width of the parameter slot by replicating bit 31 (even for unsigned types).
There is no even slot alignment for arguments larger than 64-bits.
There is no special handling for HFA (homogeneous floating-point aggregates) in general, although some rules for complex types have a similar benefit.
OpenVMS implements __float128 pass-by value semantics using a reference mechanism.
OpenVMS supports only little-endian representations.
OpenVMS supports three additional VAX floating-point types for backward compatibility: F_floating (32 bits), D_floating (64 bits), and G_floating (64 bits). Values of these types are passed using the general registers.

Return Values--- Return values up to at most 16 bytes in size may be returned in registers; larger return values are returned using a hidden parameter method using the first or second parameter slot.

C.2 Extensions

Some differences are not changes but rather additions or extensions. These include:

Floating-Point Data Types--- The calling standard for OpenVMS I64 includes support for the VAX F_floating (32-bit), D_floating (64-bit) and G_floating (64-bit) data types found on VAX and Alpha systems; it omits support for the Itanium 80-bit double-extended floating-point type.

VAX Compatible Record Layout---The OpenVMS standard adds a user optional VAX compatible record layout.

Linkage Options---OpenVMS allows additional flexibility and user control in the use of the static general registers as inputs, outputs, global registers and whether used at all.

Memory Stack Overflow Checking---OpenVMS defines how memory stack overflow checking should be performed.

Function Descriptors---OpenVMS defines extended forms of function descriptors to support additional functionality for bound procedure values and translated image support.

Unwind Information--- OpenVMS adds an operating system-specific data area to the Itanium unwind information block. The presence of an operating system-specific data area is indicated by a flag in the unwind information header.

Handler Invocation--- OpenVMS does not invoke a handler while control is in either a prologue or epilogue region of a routine. This difference in behavior is indicated by a flag in the unwind information header.