Porting Applications from HP OpenVMS Alpha to HP
OpenVMS Industry Standard 64 for Integrity Servers
This manual provides a framework for application developers who are
migrating applications from HP OpenVMS Alpha to HP OpenVMS Industry Standard 64 for Integrity Servers.
This is a new manual.
OpenVMS I64 Version 8.2
OpenVMS Alpha Version 8.2
Hewlett-Packard Company Palo Alto, California
© Copyright 2005 Hewlett-Packard Development Company, L.P.
Confidential computer software. Valid license from HP required for
possession, use or copying. Consistent with FAR 12.211 and 12.212,
Commercial Computer Software, Computer Software Documentation, and
Technical Data for Commercial Items are licensed to the U.S. Government
under vendor's standard commercial license.
The information contained herein is subject to change without notice.
The only warranties for HP products and services are set forth in the
express warranty statements accompanying such products and services.
Nothing herein should be construed as constituting an additional
warranty. HP shall not be liable for technical or editorial errors or
omissions contained herein.
Intel, Itanium, and Xeon are trademarks or registered trademarks of
Intel Corporation or its subsidiaries in the United States and other
Java is a U.S. trademark of Sun Microsystems, Inc.
UNIX is a registered trademark of The Open Group.
Printed in the US
Porting Applications from HP OpenVMS Alpha to HP OpenVMS Industry Standard 64 for Integrity Servers is intended for application developers who are planning to
migrate applications from the OpenVMS Alpha operating system to the
HP OpenVMS Industry Standard 64 for Integrity Servers (I64) operating system.
This document is organized as follows:
Chapter 1 includes an overview of the OpenVMS I64 8.2
operating system, including its evolution and its benefits.
Chapter 2 discusses fundamental differences between the OpenVMS
Alpha and OpenVMS I64 operating systems.
Chapter 3 outlines a process for assessing applications in
preparation for porting to OpenVMS I64.
Chapter 4 discusses specific tasks that must be completed to prepare
source modules for migration, as well as information about compiling,
linking, testing, and deploying ported applications.
Chapter 5 discusses the OpenVMS I64 development environment.
Chapter 6 discusses porting considerations related to the primary
compilers that will be available for OpenVMS I64.
Chapter 7 discusses other factors to consider when undertaking a
Appendix A contains a sample checklist for use when evaluating
applications prior to porting.
Appendix B lists the HP layered products that are supported on
OpenVMS Alpha but not on OpenVMS I64.
Appendix C describes how to use KP routines when porting
application-specific stack-switching code to I64.
The Glossary defines important terms and abbreviations used in this
Users of this manual may also find the following documents useful:
- HP OpenVMS Calling Standard
- HP OpenVMS Debugger Manual
- HP OpenVMS Linker Utility Manual
- HP OpenVMS System Analysis Tools Manual
Documentation for individual compilers may also be useful in the
The "OpenVMS Floating-Point Arithmetic on the Intel®
Itanium® Architecture" white paper describes differences
between floating-point data types on OpenVMS Alpha and OpenVMS I64. You
can obtain the white paper from the following location:
For additional information about HP OpenVMS products and services,
visit the following World Wide Web address:
HP welcomes your comments on this manual. Please send comments to
either of the following addresses:
OSSG Documentation Group, ZKO3-4/U08
110 Spit Brook Rd.
Nashua, NH 03062-2698
How to Order Additional Documentation
For information about how to order additional documentation, visit the
following World Wide Web address:
The following conventions may be used in this manual:
A sequence such as Ctrl/
x indicates that you must hold down the key labeled Ctrl while
you press another key or a pointing device button.
A sequence such as PF1
x indicates that you must first press and release the key
labeled PF1 and then press and release another key or a pointing device
In examples, a key name enclosed in a box indicates that you press a
key on the keyboard. (In text, a key name is not enclosed in a box.)
In the HTML version of this document, this convention appears as
brackets, rather than a box.
A horizontal ellipsis in examples indicates one of the following
- Additional optional arguments in a statement have been omitted.
- The preceding item or items can be repeated one or more times.
- Additional parameters, values, or other information can be entered.
A vertical ellipsis indicates the omission of items from a code example
or command format; the items are omitted because they are not important
to the topic being discussed.
In command format descriptions, parentheses indicate that you must
enclose choices in parentheses if you specify more than one.
In command format descriptions, brackets indicate optional choices. You
can choose one or more items or no items. Do not type the brackets on
the command line. However, you must include the brackets in the syntax
for OpenVMS directory specifications and for a substring specification
in an assignment statement.
In command format descriptions, vertical bars separate choices within
brackets or braces. Within brackets, the choices are optional; within
braces, at least one choice is required. Do not type the vertical bars
on the command line.
In command format descriptions, braces indicate required choices; you
must choose at least one of the items listed. Do not type the braces on
the command line.
Bold type represents the introduction of a new term. It also represents
the name of an argument, an attribute, or a reason.
Italic type indicates important information, complete titles of
manuals, or variables. Variables include information that varies in
system output (Internal error
number), in command lines (/PRODUCER=
name), and in command parameters in text (where
dd represents the predefined code for the device type).
Uppercase type indicates a command, the name of a routine, the name of
a file, or the abbreviation for a system privilege.
This typeface indicates code examples, command examples, and
interactive screen displays. In text, this type also identifies URLs,
UNIX commands and pathnames, PC-based commands and folders, and certain
elements of the C programming language.
A hyphen at the end of a command format description, command line, or
code line indicates that the command or statement continues on the
All numbers in text are assumed to be decimal unless otherwise noted.
Nondecimal radixes---binary, octal, or hexadecimal---are explicitly
This chapter contains an introduction to OpenVMS Industry Standard 64
for Integrity Servers (I64) systems and an overview of the migration
For more information, refer to the HP OpenVMS Version 8.2 Release Notes.
1.1 OpenVMS Industry Standard 64 for Integrity Servers
The OpenVMS I64 architecture has a 64-bit model and basic system
functions similar to the Alpha architecture; thus the great majority of
applications running on OpenVMS Alpha today can be easily ported to the
I64 architecture with few changes.
The OpenVMS Alpha and OpenVMS I64 architecture variants of OpenVMS are
produced from a single-source code base; thus, nonhardware dependent
features may be incorporated into both versions without multiple
changes to the source code, thereby minimizing the time required to
perform qualification testing, and helping to ensure the availability
of critical applications on both OpenVMS platforms.
HP intends to maintain a strict policy of ensuring forward source
compatibility so that "well-behaved" applications that
currently run on recommended versions of OpenVMS Alpha run successfully
on OpenVMS I64 systems. If an application takes advantage of published
system services and library interfaces, there should be a high level of
confidence that the application will move without modifications to the
latest version of OpenVMS I64.
OpenVMS I64 has the same look and feel familiar to OpenVMS customers.
Minor changes were made to accommodate the new architecture, but the
basic structure and capabilities of OpenVMS are the same.
1.2 Overview of the Porting Process
This section provides an overview of the porting process as it applies
to most applications.
1.2.1 Evaluating the Application
Evaluating the application identifies the steps necessary for its
migration to HP OpenVMS I64. The result of the evaluation should be a
migration plan that answers the following questions:
- How to migrate the application
- How much time, effort, and cost the migration requires
- Whether you require support from HP services
Evaluation should include the following three stages:
- A general inventory of the application, including identifying
dependencies on other software
- Source analysis to identify dependencies on other software
- Selection of a migration method (rebuilding from sources or using a
Completing these steps yields the information necessary to write an
effective migration plan.
The first step in evaluating an application for migration is to
determine exactly what has to be migrated. This includes not only the
application itself, but everything that the application requires in
order to run properly. To begin evaluating your application, identify
and locate the following items:
- Parts of the application
- Source modules for the main program
- Shareable images
- Object modules
- Libraries (object module, shareable image, text, or macro)
- Data files and databases
- Message files
- Other software on which your application depends; such as:
- Run-time libraries
- HP layered products
- Third-party layered products
- Required operating environment
- System characteristics
What sort of system is required to run
and maintain your application? For example, how much memory is
required, how much disk space, and so on?
- Build procedures
This includes HP tools such as Code Management
System (CMS) and Module Management System (MMS).
- Test Suite
Your tests must be able both to confirm that the
migrated application runs correctly and to evaluate its performance.
Many of these items have already been migrated to OpenVMS I64; for
- HP software bundled with the OpenVMS operating system
- Run-time libraries
- Other shareable libraries, such as those supplying callable utility
routines and other application library routines
- HP layered products
- Compilers and compiler RTLs
- Database managers
- Networking environment
- Third-party products
Many third-party products now run on
OpenVMS I64. To determine whether a particular application has been
migrated, contact the application vendor.
You are responsible for migrating your application and your development
environment, including build procedures and test suites.
When you have completed the evaluation of your application, continue
with a more detailed evaluation of each module and image, as described
in Chapter 4.
Fundamental Differences to Consider
This chapter discusses the fundamental differences between the Alpha
and I64 architectures.
2.1 Calling Standard
As with other components, the implementation of the OpenVMS Calling
Standard on the Intel® Itanium® processor family sought to
differ as little as possible from the OpenVMS VAX and Alpha
conventions. The design methodology started with Itanium conventions
and made changes only where necessary. This helped to maintain
compatibility with historical OpenVMS design while minimizing the cost
and difficulty of porting applications and the operating system itself
to the Itanium architecture.
The following sections contain a high-level description of differences
between the Itanium® Software Conventions and Runtime
Architecture Guide and the OpenVMS Calling Standard. For more
detailed information, see the HP OpenVMS Calling Standard.
2.1.1 Changes to the OpenVMS Calling Standard
Table 2-1 describes the major changes to the OpenVMS Calling
Standard to for OpenVMS I64.
Table 2-1 OpenVMS Calling Standard Changes
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 architecture conventions
define a pure LP64 data model.
This specification uses the terms
quadword to mean 2 bytes and 8 bytes, respectively, while the
Itanium terminology uses these words to mean 4 bytes and 16 bytes,
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 in the following cases:
- F8 and F9 (only) are used for return values.
- F10 through F15 are used as scratch registers and not for return
OpenVMS parameter passing is similar to the Itanium conventions.
Note the following differences in the OpenVMS standard:
- The OpenVMS standards adds an argument information register (for
argument count and parameter type information).
- No argument is ever duplicated in both general and floating-point
- 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 (F16), the second parameter in either the
second general register (R33) or second floating-point register (F17)
slot, and so on. Floating-point parameters are not packed into the
available floating-point registers, and a maximum of 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
- OpenVMS implements __float128 pass-by value semantics using a
- 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
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
2.1.2 Extensions to the OpenVMS Calling Standard
Table 2-2 describes additions to or extensions of the OpenVMS
Table 2-2 OpenVMS Calling Standard Extensions
Floating-point data types
The OpenVMS calling standard 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 80-bit
double-extended floating-point type of the Itanium architecture.
VAX compatible record layout
The OpenVMS standard adds a user-optional, VAX-compatible record layout.
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.
OpenVMS defines extended forms of function descriptors to support
additional functionality for bound procedure values and translated
OpenVMS adds an operating system-specific data area to the unwind
information block of the Itanium architecture. The presence of an
operating system-specific data area is indicated by a flag in the
unwind information header.
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.
OpenVMS adds support (signature information and special ABIs) for calls
between native and translated VAX or Alpha images.
2.2 Floating-Point Arithmetic
This section discusses the differences in floating-point arithmetic on
OpenVMS VAX, OpenVMS Alpha, and OpenVMS I64 systems.
The Alpha architecture supports both IEEE and VAX floating-point
formats in hardware. OpenVMS compilers generate code using the VAX
formats by default, with options on Alpha to use IEEE formats. The
Itanium architecture implements floating-point arithmetic in hardware
using the IEEE floating-point formats, including IEEE single and IEEE
If an application was originally written for OpenVMS VAX or OpenVMS
Alpha using the default floating-point formats, it can be ported to
OpenVMS I64 in one of two ways: continue to use VAX floating-point
formats utilizing the conversion features of the HP compilers or
convert the application to use IEEE floating-point formats. VAX
floating-point formats can be used in those situations where access to
previously generated binary floating-point data is required. HP
compilers generate the code necessary to convert the data between VAX
and IEEE formats.
For details about the conversion process, see the "OpenVMS
Floating-Point Arithmetic on the Intel® Itanium®
Architecture" white paper. See the Related Documents section in
the Preface for the web location of this white paper.
IEEE floating-point format should be used in those situations where VAX
floating-point formats are not required. The use of IEEE floating-point
formats will result in more efficient code.