HP OpenVMS Calling Standard
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.
Translated Images--- OpenVMS adds support (signature
information and special ABIs) for calls between native and translated
VAX or Alpha images.
|
