HP OpenVMS systems documentation

Java^tm Version 1.4.2-1 is supported on OpenVMS I64. There are no differences between Java on OpenVMS Alpha and OpenVMS I64.

6.9 Macro-32

Most VAX MACRO programs that compile on OpenVMS Alpha should recompile on OpenVMS I64 without modification. However, programs that call routines with nonstandard return values or programs that use the JSB instruction to call routines written in other languages must add some new directives to the source file. For more information, refer to the HP OpenVMS MACRO Compiler Porting and User's Guide.

6.10 HP Pascal

HP Pascal Version 5.9 is available for both Alpha and I64.

There are no known language differences between Pascal on OpenVMS Alpha and Pascal on OpenVMS I64. The only difference is that the default is for IEEE floating datatypes instead of VAX floating datatypes, which is true for all the HP I64 compilers.

6.10.1 /ARCH and /OPTIMIZE=TUNE Qualifiers

For the sake of "compile-and-go" compatibility, Alpha values for the /ARCH and /OPTIMIZE=TUNE qualifiers are accepted on the compiler invocation command. An informational message is printed saying they are ignored.

I64 values for /ARCH and /OPTIMIZE=TUNE are defined in the OpenVMS I64 compiler for development purposes only. Their behavior is unpredictable and they should not be used.

This chapter describes additional porting considerations.

7.1 Hardware Considerations

This section contains information about the Alpha, PA-RISC and the Itanium processor families. It also discusses processor-related development issues and provides examples using both C and assembly language for typical processor-dependent code.

7.1.1 Intel Itanium Processor Family Overview

The Itanium architecture was developed by HP and Intel as a 64-bit processor for engineering workstations and e-commerce servers. The Itanium processor family uses a new architecture called Explicitly Parallel Instruction Computing (EPIC).

Some of the most important goals in the design of EPIC were instruction-level parallelism, software pipelining, speculation, predication, and large register files. These allow Itanium processors to execute multiple instructions simultaneously. EPIC exposes many of these parallel features to the compiler (hence "Explicitly" in the name). This increases the complexity of the compiler, but it allows the compiler to directly take advantage of these features.

EPIC is designed so future generations of processors can utilize different levels of parallelism, which increases the flexibility of future designs. This allows the machine code to express where the parallelism exists without forcing the processor to conform to previous machine widths.

For more information on assembly programming for the Intel Itanium processor family, see the Intel® Itanium® Architecture Assembly Language Reference Guide, available at:

http://developer.intel.com/software/products/opensource/tools1/tol_whte2.htm

7.1.2 Alpha Processor Family Overview

Alpha is a 64-bit load/store RISC architecture that is designed with particular emphasis on the three elements that most affect performance: clock speed, multiple instruction issue, and multiple processors.

The Alpha architects examined and analyzed current and theoretical RISC architecture design elements and developed high-performance alternatives for the Alpha architecture.

The Alpha architecture is designed to avoid bias toward any particular operating system or programming language. Alpha supports the OpenVMS Alpha, Tru64 UNIX, and Linux operating systems and supports simple software migration for applications that run on those operating systems.

Alpha was designed as a 64-bit architecture. All registers are 64 bits in length and all operations are performed between 64-bit registers. It is not a 32-bit architecture that was later expanded to 64 bits.

The instructions are very simple. All instructions are 32 bits in length. Memory operations are either loads or stores. All data manipulation is done between registers.

The Alpha architecture facilitates pipelining multiple instances of the same operations because there are no special registers and no condition codes.

The instructions interact with each other only by one instruction writing a register or memory and another instruction reading from the same place. That makes it particularly easy to build implementations that issue multiple instructions every CPU cycle.

Alpha makes it easy to maintain binary compatibility across multiple implementations and easy to maintain full speed on multiple-issue implementations. For example, there are no implementation-specific pipeline timing hazards, no load-delay slots, and no branch-delay slots.

The Alpha architecture reads and writes bytes between registers and memory with the LDBU and STB instructions. (Alpha also supports word read/writes with the LDWU and STW instructions.) Byte shifting and masking are performed with normal 64-bit register-to-register instructions, crafted to keep instruction sequences short.

As viewed from a second processor (including an I/O device), a sequence of reads and writes issued by one processor can be arbitrarily reordered by an implementation. This allows implementations to use multibank caches, bypassed write buffers, write merging, pipelined writes with retry on error, and so forth. If strict ordering between two accesses must be maintained, explicit memory barrier instructions can be inserted in the program.

The basic multiprocessor interlocking primitive is a RISC-style load_locked, modify, store_conditional sequence. If the sequence runs without interrupt, exception, or an interfering write from another processor, then the conditional store succeeds. Otherwise, the store fails and the program eventually must branch back and retry the sequence. This style of interlocking scales well with very fast caches and makes Alpha an especially attractive architecture for building multiple-processor systems.

A privileged architecture library (PALcode) is a set of subroutines that are specific to a particular Alpha operating system implementation. These subroutines provide operating-system primitives for context switching, interrupts, exceptions, and memory management. PALcode is similar to the BIOS libraries that are provided in personal computers.

For more information, refer to the Alpha Architecture Handbook, part number EC-QD2KC-TE.

7.2 Endianism Considerations

Users who are porting from OpenVMS Alpha or OpenVMS VAX to OpenVMS I64 do not need to be concerned with endianism issues; OpenVMS on all platforms uses little-endian for data storage and manipulation. This chapter is being made available more for reference to allow the reader to be aware of issues, in general, when porting between different hardware architectures where endianisms are different.

Endianism refers to the way data is stored and defines how bytes are addressed in multibyte data types. This is important because if you try to read binary data on a machine that is of a different endianism than the machine that wrote the data, the results will be different. This is an especially significant problem when a database needs to be moved to a different endian architecture.

There are two types of endian machines: big-endian (forward byte ordering or most significant first, [MSF]) and little-endian (reverse byte ordering or least significant first, [LSF]). The mnemonics "big end in" and "little end in" can be useful when discussing endianism. Figure 7-1 and Figure 7-2 compare the two byte-ordering methodologies.

Figure 7-1 Big-Endian Byte Ordering

Figure 7-2 Little-Endian Byte Ordering

The Alpha microprocessor provides a little-endian environment for operating systems such as OpenVMS and Tru64 UNIX, while the PA-RISC microprocessor provides a big-endian environment for the HP-UX operating system.

On a little-endian operating system, such as OpenVMS, the little end, or least-significant byte is stored at the lowest address. This means a hexadecimal like 0x1234 is stored in memory as 0x34 0x12. The same is true for a 4-byte value; for example, 0x12345678 is stored as 0x78 0x56 0x34 0x12. A big-endian operating system does this in reverse fashion, so 0x1234 is stored as 0x12 0x34 in memory.

Consider the number 1025 (2 to the tenth power plus 1) stored in a 4-byte integer. This is represented in memory as follows:

little endian: 00000000 00000000 00000100 00000001b big endian: 00000001 00000100 00000000 00000000b

The Intel Itanium processor family architecture supports both big-endian and little-endian memory addressing. There are no problems reading and exchanging data between OpenVMS Alpha and OpenVMS I64 running on Itanium processors. If there is a need to exchange data between OpenVMS on an Alpha or I64 system and HP-UX on PA-RISC or the Itanium processor family, then byte swapping might be required.

General Information
1.	What does your application do (brief description)?
Development History and Plans
2.	a. Does the application currently run on other operating systems or hardware architectures?	[] YES	[] NO
	b. If yes, does the application currently run on the latest OpenVMS Alpha system?	[] YES	[] NO
	[If your application already runs on multiple platforms, it is likely to be platform independent, and therefore, easier to port to OpenVMS I64. (However, if the application code is conditionalized per platform, then minor modifications might be required. For more information, see Section 4.8.1.) If you answer YES to b, your application will be easier to port to OpenVMS I64. If your application is running on OpenVMS VAX, you must first port it to OpenVMS Alpha. (For more information, refer to the Migrating an Application from OpenVMS VAX to OpenVMS Alpha manual.)]
3.	When was the last time the application environment was completely recompiled and rebuilt from source?
	a. Is the application rebuilt regularly?	[] YES	[] NO
	b. How frequently?
	[Applications that are not built frequently might require additional work before being ported. For example, changes in the development environment might cause incompatibilities. Prior to porting your applications, confirm that they can be built on the latest version of OpenVMS Alpha.]
4.	Is the application actively maintained by developers who know it well?	[] YES	[] NO
	List developer names and contact information:
	Developer Contact
5.	a. How is a new build of the application tested or verified for proper operation?
	b. Do you have performance characterization tools to assist with optimization?	[] YES	[] NO
	c. If yes, list the tools and version numbers used:
	Tool Version
	d. Which source-code configuration management tools are used? List the tools and their version numbers:
	Tool Version
6.	Do you have a development and test environment separate from your production systems?	[] YES	[] NO
7.	What procedures are in place for rolling in a new version of the application into production?
8.	What are your plans for the application after porting it to OpenVMS I64?
	a. No further development	[] YES	[] NO
	b. Maintenance releases only	[] YES	[] NO
	c. Additional or changed functionality	[] YES	[] NO
	d. Maintain separate OpenVMS I64 and OpenVMS Alpha sources	[] YES	[] NO
	[If you answer YES to a, you might want to consider translating the application. A YES response to b or c is reason to evaluate the benefits of recompiling and relinking your application, although translation is still possible. If you intend to maintain separate OpenVMS I64 and OpenVMS Alpha sources, as indicated by a YES to d, you might need to consider interoperability and consistency issues, especially if different versions of the application can access the same database.]
Composition of the Application
	Consider the size and components of your application that need to be ported.
9.	How large is your application?
	How many modules?
	How many lines, disk blocks, or megabytes of code?
	How much disk space is required?
	[This will help you "size" the effort and the resources required for porting. Most helpful is knowing the number of disk blocks of code.]
10.	a. Do you have access to all source files that make up your application?	[] YES	[] NO
	b. If you are considering using HP Services, will it be possible to give HP access to these source files and build procedures?	[] YES	[] NO
	[If you answer NO to a, translation may be your only porting option for the files with missing sources. Translate user-mode OpenVMS Alpha images to OpenVMS I64 images. Note that if you have OpenVMS VAX images, first translate them to OpenVMS Alpha images. You cannot translate them directly to OpenVMS I64 images. A YES answer to b allows you to take advantage of a greater range of HP porting services.]
11.	a. List the languages used to write the application. (If multiple languages are used, give the percentages of each.)
	Language Percentage
	b. Do you use Macro--64, PL/I, Ada 83, or Fortran 77 on OpenVMS Alpha?	[] YES	[] NO
	[If you use Macro--64 on OpenVMS Alpha, you must rewrite the code because no Macro--64 compiler exists for OpenVMS I64. If possible, HP recommends rewriting the code into a high-level language using documented system interfaces. For machine-specific code that must be written in assembly language, you must recode the Macro--64 code into OpenVMS I64 assembly code. Similarly, PL/I, Fortran 77, and ADA 83 are not supported on OpenVMS I64. If your application has code written in PL/I, HP recommends rewriting it in another language such as C or C++. Update code written in Ada 83 to Ada 95, and code written in Fortran 77 to Fortran 90. Analyze your code to determine whether the newer compiler requires changes to the code. In general, if the compilers are not available on OpenVMS I64, you must translate or rewrite code in a different language. For information on availability of compilers and translators, see Chapters 5 and 6.]
12.	Is there application documentation?	[] YES	[] NO
	[If you answer yes, note that if any changes were required to the application, the documentation might have to be updated accordingly.]
External Dependencies
	Consider the system configuration, environment, and software required for developing, testing, and running your application.
13.	What is the system configuration (CPUs, memory, disks) required to set up a development environment for the application?
	[This will help you plan for the resources needed for porting.]
14.	What is the system configuration (CPUs, memory, disks) required to set up a typical user environment for the application, including installation verification procedures, regression tests, benchmarks, or work loads?
	[This will help you determine whether your entire environment is available on OpenVMS I64.]
15.	Does the application rely on any special hardware?	[] YES	[] NO
	[This will help you determine whether the hardware is available on OpenVMS I64, and whether the application includes hardware-specific code.]
16.	What version of OpenVMS Alpha does your application currently run on?
	Does the application run on OpenVMS Alpha Version 7.3-2 or 7.3-1?	[] YES	[] NO
	[HP recommends having your application running on the latest version of OpenVMS Alpha before porting it to OpenVMS I64.]
17.	Does the application require layered and third-party products to run?
	a. From HP (other than compiler RTLs):	[] YES	[] NO
	List the HP layered products and versions:
	HP Product Version
	b. From third parties:	[] YES	[] NO
	List the third-party products and versions:
	Third-Party Product Version
	[If you answer YES to a and are uncertain whether the HP layered products are yet available for OpenVMS I64, check with an HP support representative. For information about HP's commitment to support porting of software, see Section 3.4. If you answer YES to b, check with your third-party product supplier.]
18.	a. Do you have regression tests for the application?	[] YES	[] NO
	b. If yes, do they require any particular software product such as HP Digital Test Manager?	[] YES	[] NO
	[If you answer YES to a, you should consider porting those regression tests. If you answer YES to b, HP Digital Test Manager (part of the DECset product set) is available with this release of OpenVMS. If you require other tools for testing purposes, contact your HP support representative; see also Chapter 5. HP recommends a disciplined testing process to check regressions in product development.]
Dependencies on the OpenVMS Alpha Architecture
	Consider differences between OpenVMS Alpha and OpenVMS I64. The following questions will help you account for the most significant differences. Consider the changes that might be necessary to application components because of these differences. Any user-written code or assembly code that depends specifically on the OpenVMS Alpha architecture must be rewritten.
19.	Does the application use OpenVMS VAX floating-point data types?	[] YES	[] NO
	[If you answer YES, note that the default for OpenVMS I64 compilers is IEEE floating data types. OpenVMS I64 compilers provide for VAX floating support by automatically converting from OpenVMS VAX to IEEE floating data types. Slight precision differences might result. In addition, run-time performance will be somewhat slower (compared to the direct use of IEEE floating data types without conversion), depending on the extent to which the application is dominated by floating point calculations. For more information about floating point data types, see Section 4.8.4.]
20.	Is the data naturally aligned?	[] YES	[] NO
	[If your data is not naturally aligned, HP recommends that you align your data naturally to achieve optimal performance for data referencing. Unaligned data can degrade data referencing performance significantly. In certain instances, you must align data naturally. For more information about data structures and alignment, see Section 4.8.7 and refer to th HP OpenVMS Programming Concepts Manual.]
21.	Does the application call OpenVMS system services that:
	a. Modify the working set?	[] YES	[] NO
	b. Change program control flow using SYS$GOTO_UNWIND?	[] YES	[] NO
	[If you answer YES to a, make sure that calls to the SYS$LKWSET and SYS$LKWSET_64 system services specify the required input parameters correctly. If you answer YES to b, change any calls to SYS$GOTO_UNWIND to SYS$GOTO_UNWIND_64. OpenVMS I64 does not support SYS$GOTO_UNWIND. For more information, see Chapter 4.]
22.	a. Does the application use multiple, cooperating processes?	[] YES	[] NO
	If so:
	b. How many processes?
	c. What interprocess communication method is used?
	[] $CRMPSC [] Mailboxes [] SCS [] Other [] DLM [] SHM, IPC [] SMG$ [] STR$
	d. If you use global sections ($CRMPSC) to share data with other processes, how is data access synchronized?
	[This will help you determine whether you will need to use explicit synchronization, and the level of effort required to guarantee synchronization among the parts of your application. Use of a high-level synchronization method generally allows you to port an application most easily.]
23.	Does the application currently run in a multiprocessor (SMP) environment?	[] YES	[] NO
	[If you answer YES, it is likely that your application already uses adequate interprocess synchronization methods.]
24.	Does the application use AST (asynchronous system trap) mechanisms?	[] YES	[] NO
	[If you answer YES, you should determine whether the AST and main process share access to data in process space. If so, you may need to explicitly synchronize such accesses. Note that this is equally true for applications on Alpha. For more information about ASTs, see HP OpenVMS Programming Concepts Manual.]
25.	a. Does the application contain condition handlers?	[] YES	[] NO
	b. Do any handlers modify data in the mechanism array?	[] YES	[] NO
	[The OpenVMS Alpha and I64 mechanism array formats differ significantly. Be sure to modify any applications that modify register values in the mechanism array. For more information, see the HP OpenVMS Guide to Upgrading Privileged-Code Applications.]
26.	a. Does the application run in privileged mode or link against SYS$BASE_IMAGE?	[] YES	[] NO
	If so, why?
	b. Does the application depend on OpenVMS internal data structures or interfaces?	[] YES	[] NO
	[Applications that link against the OpenVMS executive or run in privileged mode might require additional porting work. Undocumented interfaces in SYS$BASE_IMAGE might have changed on OpenVMS I64. Applications that depend on OpenVMS internal data structure definitions (as defined in SYS$LIBRARY:LIB.INCLUDE, SYS$LIBRARY:LIB.L32, SYS$LIBRARY:LIB.MLB, SYS$LIBRARY:LIB.R64, SYS$LIBRARY:LIB.REQ, and SYS$LIBRARY:SYS$LIB_C.TLB) might also require additional porting work, as some internal data structures have changed on OpenVMS I64.]
27.	Does the application use connect-to-interrupt mechanisms?	[] YES	[] NO
	If yes, with what functionality?
	[Connect-to-interrupt is not supported on OpenVMS I64 systems. Contact an HP representative if you need this feature.]
28.	Does the application create or modify machine instructions?	[] YES	[] NO
	[Guaranteeing correct execution of instructions written to the instruction stream requires great care on OpenVMS I64. Any code dealing with specific machine instructions must be rewritten.]
29.	Does the application include any other user-written code or assembler code that depends specifically on the OpenVMS Alpha architecture?	[] YES	[] NO
	[If you answer YES, rewrite such code. Optimally, rewrite it so that it is independent of architecture.]
30.	Does the application include or depend on any conditionalized statements in source code or build files, or any code that includes logic that assumes it is running on either a VAX or an OpenVMS Alpha system?	[] YES	[] NO
	[If you answer YES, you might have to modify the conditional directives slightly. For example, change "IF ALPHA" to "IF ALPHA OR IPF", or change "IF NOT ALPHA" to "IF VAX". For more information, see Section 4.8.1.]
31.	What parts of the application are most sensitive to performance? I/O, floating point, memory, realtime (that is, interrupt latency, and so on).
	[This will help you determine how to prioritize work on the various parts of your application and allow HP to plan performance enhancements that are most meaningful to customers.]
32.	Does the application use any OpenVMS Alpha Calling Standard routines?	[] YES	[] NO
	[If you answer YES, note that applications that use the calling standard data structure named LIBICB, or that make use of the calling standard routines such as LIB$GET_CURRENT_INVO_CONTEXT, LIB$GET_PREVIOUS_INVO_CONTEXT, LIB$PUT_INVO_CONTEXT, and LIB$GET_INVO_HANDLE, will have to be modified. These routines have been renamed in OpenVMS I64 due to changes in the LIBICB data structure. In addition, the calling standard has changed. Applications with direct knowledge of the OpenVMS Alpha calling standard must be modified for OpenVMS I64. For more information on the differences between OpenVMS Alpha and I64 calling standards, see Section 2.1.1. For more information about OpenVMS calling standards, see the HP OpenVMS Calling Standard.]
33.	Does the application use non-standard routine linkage declarations?	[] YES	[] NO
	[If you answer YES, note that by definition applications with non-standard linkages know the OpenVMS Alpha calling standard and might need modification to conform to the OpenVMS I64 calling standard.]
34.	a. Does the application depend on the format or content of an object file?	[] YES	[] NO
	b. Does the application depend on the format or content of an executable image?	[] YES	[] NO
	c. Does the application depend on the debug symbol table content of an image?	[] YES	[] NO
	[If you answer YES to a, b, or c, note that applications that depend on any of these image and object file data structures must be modified. The industry-standard object and image file layout called ELF has been adopted by OpenVMS I64. The industry-standard DWARF debug symbol table format has also been adopted. Applications with dependencies on OpenVMS Alpha's object, image or debug symbol table formats must be modified. For more information, see Section 4.8.3.4.]
35.	Does the application use the C asm statement?	[] YES	[] NO
	[If you answer YES, note that applications that use the C asm statement have Alpha instruction dependencies and must be modified. The HP C compiler for OpenVMS I64 has added many new builtin functions that minimize the need for using asm statements.]
36.	Does the application use BLISS register Builtins?	[] YES	[] NO
	[If you answer YES, note that applications that use the BLISS BUILTIN statement to declare register builtins must be modified.]
Porting Your Application
	Once the preliminary evaluation and planning stages are completed, these are the main porting tasks.
37.	Have you upgraded your OpenVMS Alpha system to the latest version available?	[] YES	[] NO
	[If you answer NO, first upgrade your OpenVMS Alpha system before beginning to port the application.]
38.	a. Have you test compiled your application on the latest version of OpenVMS Alpha, using the most recent version of the compiler?	[] YES	[] NO
	b. Have you corrected any problems detected during the compile?	[] YES	[] NO
	[If you answer NO to a, compile your application on the latest OpenVMS Alpha system, using the latest compiler available. If you answer YES to a but have rewritten some code since, compile again. After compiling, correct any problems detected. When you have finished this phase, and when you have responded to all other considerations detailed thus far in this checklist and in Chapters 4 through 7, your application is ready for porting to OpenVMS I64.]
39.	Copy the application source modules and all related code to the OpenVMS I64 system. Have you copied the modules and related code to OpenVMS I64?	[] YES	[] NO
40.	Compile, link, and run the application on the OpenVMS I64 system. Application is compiled, linked, and running?	[] YES	[] NO
	[For details, see Chapter 5.]
41.	Perform unit testing on the OpenVMS I64 system. Have you completed the unit testing?	[] YES	[] NO
	[For details, see Chapter 5.]
42.	Perform system testing on the OpenVMS I64 system. Have you completed the system testing?	[] YES	[] NO
	[For details, see Chapter 5.]
43.	Perform regression testing on the OpenVMS I64 system. Have you completed the regression testing?	[] YES	[] NO
	[For details, see Chapter 5.]
44.	Did testing succeed?	[] YES	[] NO
	[If you answer NO, resolve the problems, then recompile, relink, and retest the application. For details, see Chapter 5.]