HP OpenVMS systems
Order Number: BA442--90001
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.
Revision/Update Information: This is a new manual.
Software Version: 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 countries.
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 porting effort.
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 manual.
Users of this manual may also find the following documents useful:
Documentation for individual compilers may also be useful in the porting process.
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
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 button.
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
|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 following line.
|All numbers in text are assumed to be decimal unless otherwise noted. Nondecimal radixes---binary, octal, or hexadecimal---are explicitly indicated.
This chapter contains an introduction to OpenVMS Industry Standard 64 for Integrity Servers (I64) systems and an overview of the migration process.
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:
Evaluation should include the following three stages:
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:
Many of these items have already been migrated to OpenVMS I64; for example:
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.
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.
|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 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:
|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:
OpenVMS parameter passing is similar to the Itanium conventions.
Note the following differences in the OpenVMS standard:
|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.
Table 2-2 describes additions to or extensions of the OpenVMS Calling Standard.
|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 image support.
|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.
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 double.
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.