Porting Applications onto OpenVMS I64

Porting Applications onto OpenVMS I64

http://64.223.189.234/node/226

Submitted by Hoff on April 14, 2007 - 01:51.

Tagged: Alpha  •  Business  •  Itanium  •  Management  •  OpenVMS  •  OpenVMS Alpha  •  OpenVMS I64  •  OpenVMS VAX  •  Porting  •  Programming  •  Software  •  VAX

Porting from OpenVMS Alpha to OpenVMS I64 is generally rather easier than from OpenVMS VAX to OpenVMS Alpha, or OpenVMS VAX to OpenVMS I64. What to look for when porting from OpenVMS Alpha to OpenVMS I64?

When porting from OpenVMS Alpha to OpenVMS I64, user-mode code is generally little more than a recompile and a relink. (Porting forward from OpenVMS VAX is more difficult.) When starting with OpenVMS Alpha code, most time involved here is the creation of a multi-architecture build environment, if you are planning to operate two or three architectures in parallel (clustered or standalone) from a common source code pool.

The Itanium platform, the instruction set and the console are entirely different from Alpha. This leads to such considerations as the executable images being rather larger; OpenVMS I64 executable images are on the order of three times the size of OpenVMS Alpha images.

You will need to recreate objects, object libraries, shareable images and other similar files.

When porting existing OpenVMS Alpha code, do specifically look for #ifdef and SYI$ architectural specifications, and any code looking at the hardware model or architecture name or architecture type codes; this code is already conditionalized, and may well need adjustment to move to OpenVMS I64. If you find references to VAX or Alpha or the inclusion of ARCH_DEFS.* or such, the code will need a more careful look.

Floating point can be the most pernicious difference, as VAX has the VAX floating point formats and usually D_Float and F_Float and occasionally G_Float and H_Float, Alpha had both VAX floating point and the IEEE S_Float and T_Float formats. Itanium has the IEEE S_Float and T_Float, and does not have hardware support for the VAX formats. This can lead to subtle differences in the lowest or least significant bits of floating point values, and can lead to floating point conversions.

Look for floating point values written into files.

OpenVMS I64 supports most of the Alpha PALcode calls, though these are usually now system services. What was once a VAX hardware instruction became a PALcode call on Alpha, and is often now a system service on OpenVMS I64. VAX had hardware exceptions and signals and ASTs, Alpha had PALcode and compiler assists for these, and OpenVMS I64 has all of these pieces integrated into the operating system.

Code that references internal registers — the MTPR and MFPR series of PALcode calls, for instance — are not available.

Instruction and architectural changes make implementing threading far more difficult on OpenVMS I64, and applications that have implemented private threading models will usually want to move to the KP threads services. What was a kernel-only mechanism for threading within OpenVMS Alpha is now callable from outer modes, and on both OpenVMS Alpha and OpenVMS I64.

There have been various changes to internal data structures; kernel-mode code (linked with /SYSEXE, etc) will generally require a close look, and may well require modifications.

UCB Unit Number field, the CPU Masks, various LBN-related fields; kernel data structure fields that was smaller or unaligned have been promoted.

Other ancillary considerations include unaligned data references — these are slow on Alpha, and very slow on OpenVMS I64 — and process quotas will almost certainly need to be increased. (See Recommended OpenVMS Username Quota Changes and AskHL: TCP/IP Process Quotas for OpenVMS I64.

Slower? Where the data is aligned, there is no performance degradation. Where the compiler knows the data is unaligned, Alpha is about 4 cycles slower and Itanium is about 10 cycles slower than with aligned data. Where the compiler is unaware of the unalignment, Alpha is about 10 cycles slower and Itanium is about 100 cycles slower. For Itanium instruction scheduling details, see Itanium Instruction Scheduling and Performance.

To check for unaligned data, various compilers have diagnostics, such as CC /WARN=ENABLE=ALIGNMENT.

And start the port by getting to the most current OpenVMS version, and the most current compilers and layered products. Generate full maps and listings, and enable compiler diagnostics. On the same, current architecture. Make sure your code compiles cleanly, before you change the architecture.

Porting Documentation

Do read through the Porting Applications from HP OpenVMS Alpha to HP OpenVMS Industry Standard 64 for Integrity Servers manual in the OpenVMS documentation set.

An introduction around Porting Applications Off of OpenVMS is also available.

Login or register to post comments  •  Printer friendly version