HP OpenVMS systems
VAX floating-point formats are supported on the Itanium architecture by converting them to IEEE single and IEEE double floating types. By default, this is a transparent process that will not impact most applications. HP is providing compilers for C, C++, Fortran, BASIC, Pascal, and COBOL, all with the same floating-point options. Application developers need only recompile their applications using the appropriate compiler. For detailed descriptions of floating-point options, refer to the individual compilers' documentation.
Because IEEE floating-point format is the default, unless an application explicitly specifies VAX floating-point format options, a simple rebuild for OpenVMS I64 uses native IEEE formats directly. For programs that do not depend directly on the VAX formats for correct operation, this is the most desirable way to build for OpenVMS I64.
2.3 Object File Format
Hewlett-Packard has determined that the most efficient way to utilize
the compiler technologies developed by Intel is to adopt two industry
standards, both of which are used by the Itanium compiler:
One clear advantage of this decision is that development tools can be ported to OpenVMS more easily in the future. All of the compilers, development tools, and utilities provided with the OpenVMS I64 operating system will utilize and understand these new formats. Application developers will not need to be concerned with these formats unless their applications have specific knowledge of them.
In a typical application scenario in which an application is compiled, linked, debugged, and deployed, the details of the object file format, the executable image file format, and the debugging and traceback information are of no concern to the developer. However, software engineers who develop compilers, debuggers, analysis tools, or other utilities that are dependent on these file formats will need to understand how they are being implemented on OpenVMS.
Typically, porting an application to a new platform involves the following procedure:
Although you complete these tasks sequentially, you might have to repeat some steps if problems arise.
This chapter addresses the first task --- assessing porting needs. Subsequent chapters discuss the remaining tasks. This chapter describes the responsibilities and issues that developers should consider in planning to port an application. In particular, it sets the context for porting applications from an OpenVMS Alpha to an OpenVMS I64 environment and provides the information necessary to help developers evaluate needs, plan, and begin porting software.
Most applications running on OpenVMS Alpha today can easily be ported to OpenVMS I64 with few changes. The Alpha and I64 variants of OpenVMS are produced from a single source-code base, enabling developers to incorporate features (that are independent of the hardware) into both versions without requiring multiple changes to the source code. This minimizes the time required to perform qualification testing and helps to ensure the availability of critical applications on both OpenVMS platforms.
HP intends to maintain a strict policy of ensuring and maintaining forward source compatibility so that "well-behaved" applications that run on recommended versions of OpenVMS Alpha will also run successfully on OpenVMS I64 systems. For the most part, if an application takes advantage of published system services and library interfaces, the application should be portable (as is) to the latest version of OpenVMS I64. However, some published system and library interfaces available on OpenVMS Alpha will not be available or will behave differently on OpenVMS I64. In addition, the Linker utility does not support all qualifiers supported on OpenVMS Alpha. For more information about these exceptions, see Chapter 4 and Chapter 5.
OpenVMS I64 has the same look and feel familiar to OpenVMS customers.
Minor changes were needed to accommodate the new architecture, but the
basic structure and capabilities of OpenVMS are the same.
3.2 Evaluating the Application
The first step to porting an application is to evaluate and identify the steps necessary to port the application to OpenVMS I64. The evaluation process culminates in a porting plan that answers the following questions:
The evaluation process has the following four steps:
Completing these steps yields the information necessary to write an effective porting plan. Sections 3.2.1 through 3.2.4 suggest the steps for an initial, rudimentary evaluation, after which you can perform a more detailed evaluation of each module, image, and all dependencies.
After you complete the evaluation steps described in the following
sections, compare your results with the supported product, procedures,
and functionality of the target platform. Research any deviations for
schedule mismatches, missing functionality, procedural conflicts, and
supportability. To complete your porting plan, include all costs and
3.2.1 Selecting the Porting Method
After you complete the evaluation process described in the following sections, you will have to port your application and your development environment. In addition to the source modules, you might have to port other components, such as build procedures, test suites, and in some cases, the application data structures. You must decide on the best method for porting each part of the application. Usually the issue is whether to rebuild your application from sources or to use a binary translator. To make this decision, you need to know which methods are possible for each part of the application, and how much work is required for each method. To help answer those questions, you should answer the series of questions and perform the tasks shown in Figure 3-1.
The majority of applications can be ported by recompiling and relinking them. If your application runs only in user mode and is written in a standard high-level language, it is most likely in this category.
Figure 3-1 Porting an Application
The first step in evaluating an application for porting is to identify exactly what has to be ported. This includes not only the application itself, but everything that the application requires to run properly. To begin evaluating your application, identify and locate the following items:
Consider the differences between OpenVMS Alpha and OpenVMS I64 described in Chapter 2 and the consequent changes that are necessary for application components prior to porting. In addition, consider the processor-related development issues, as described in Chapter 7.
Evaluate the time and costs required for these changes. Any code that depends specifically on the OpenVMS Alpha architecture must be changed. For example, an application may require changes if it includes code that:
HP recommends that you align your data naturally to achieve optimal performance for data referencing. On both OpenVMS Alpha and OpenVMS I64 systems, referencing data that is unaligned degrades performance significantly. In addition, unaligned shared data can cause a program to execute incorrectly. You must align shared data naturally. Shared data might be between threads of a single process, between a process and ASTs, or between several processes in a global section. For more information about data alignment, see Section 4.8.7 and the HP OpenVMS Programming Concepts Manual.
In addition any source code that does not have a supported compiler on OpenVMS I64 must be rewritten or translated. (For a list of supported compilers, see Chapter 6.) Note also that certain language capabilities of OpenVMS Alpha are not supported on OpenVMS I64; for more information, see the HP OpenVMS Version 8.2 Release Notes. In addition, applications that run in privileged mode might require changes.
The next step is to assess the software and environment on which your
126.96.36.199 Software Dependencies
Many of these items have already been migrated to OpenVMS I64, including the following:
The availability of third-party software can be the biggest obstacle for a porting project. You must determine the availability and cost of third-party software for the target operating system. This might include build environment tools, third-party libraries, and automated testing tools. For information about tools that are freely available on OpenVMS, see Chapter 5.
Consider the development environment upon which your application
depends, including the operating system configuration, hardware,
development utilities, build procedures (including HP tools such as
Code Management System [CMS] and Module Management System [MMS]), and
188.8.131.52 Operating Environment
No single organization has expertise in all phases of a porting process. Therefore, HP has gathered a set of resources that can assist you through the process. These resources can provide everything from porting guides to teams of personnel with equipment that handles the entire porting task. For more information, consult your local HP representative and the Alpha Retain Trust services web site at:
A sampling of other resources available include the following:
As the HP strategy on the Itanium architecture continues to develop,
Sales Resources and Global Services will assess the impact to the
long-term plans of HP customers and ISVs. HP will create and document
template and custom service offerings to address generic and unique
situations of each customer. HP will tailor each service offering to
support your needs by making available the tools and resources needed
to assist with crucial changes during the transition.
3.4 Additional Considerations
HP recognizes that not all layered software and middleware supplier products will port to OpenVMS I64 at first release. HP is committed to assist software vendors with information, hardware, support, and tools that will facilitate this process. Each vendor should monitor the progress of the supplier of their prerequisite software to ensure that the required components are in place for their development schedules.
HP intends to implement a tool suite on the existing OpenVMS Alpha platform that will make porting to the new OpenVMS I64 platform transparent for most developers in terms of the code base, commands, and process. Nothing will replace the testing that accompanies any quality product release. Rather, this tool suite will reduce the time required for product porting.