Migrating an Application from OpenVMS VAX to OpenVMS Alpha

For more information on data alignment, see Chapter 7 and Section 8.4.2.

2.5.2 Data Types

The Alpha architecture supports most of the VAX native data types; however, certain VAX data types, such as the H_floating data type, are not supported (see Table 2-1). Check to see if your application depends on the size or bit representation of an underlying native data type.

Table 2-1 Floating-Point Data Type Support

Data Type	On VAX	On Alpha
D53_floating (G_floating) (Default double-precision format)	Not supported.	Supported. Using D53_floating instead of D56_floating drops three bits of precision and yields slightly different results.
D56_floating (Default double-precision format)	Supported.	Not supported. You can obtain full support by translating your code with DECmigrate. Alternatively, you can substitute D53_floating for D56_floating, if your application does not require the extra three bits of precision.
F_floating	Supported.	Supported.
G_floating	Supported.	Supported.
H_floating (128-bit floating-point)	Supported.	Not supported. You can obtain full H_floating support with DECmigrate. You can use it to translate the code module that contains H_floating structures, or you can recode your application, using a supported data type.
S_floating (IEEE)	Not supported.	Supported.
T_floating (IEEE)	Not supported.	Supported.
X_floating (128-bit floating-point (Alpha; IEEE-like))	Not supported.	Supported by Digital Fortran Version 6.2 or later and by DEC C Version 4.0 or later. The X_floating data format is not identical to H_floating, but both cover a similar range of values. For Fortran applications, automatic conversion between X_floating memory format and H_floating on-disk is possible by use of the FOR$CONVERTnnn logical name, the OPTIONS statement, the /CONVERT compiler qualifier, or the CONVERT=keyword on OPEN statements.

To improve their performance, Alpha processors implement the numeric string and packed decimal string, H_floating, and full-precision D_floating data types by using software, as follows:

• Decimal
  Eighteen-digit decimal data is converted to 64-bit binary integers internally, which provides very fast COBOL performance.
• H_floating
  Alpha compilers do not support H_floating data; however, the Translated Image Environment (TIE) provides emulated support for H_floating data in translated images.
• D_floating
  D_floating data is implemented on Alpha platforms in the following ways:
  • Using G_floating hardware (D53). Alpha hardware converts D_floating data (D53) to G_floating for processing. This provides speed and data-type compatibility with existing binary files that contain D_floating data, but loses 3 fraction bits compared to D_floating arithmetic on current VAX systems. D_floating data is thus processed with 15 decimal digits of precision instead of the 16 decimal digits supplied by D56 on a VAX system.
  • Using software emulation (D56) for translated images. This gives exact D56 format VAX results, but is slower than D53 or G_floating.

Eliminating the Problem

To eliminate data type problems, you will be able to use one or more of the following methods:

• Instead of D_floating or H_floating, use G_floating or IEEE T_floating whenever possible because both:
  • Support data in the range 10^^-308 to 10^³⁰⁸
  • Have approximately 15 decimal digits of precision
• Instead of decimal data types, use integer data types whenever possible.

For more information on Alpha data types, see Chapter 7.

2.5.3 Shared Access to Data

An atomic operation is one in which:

• Intermediate or partial results cannot be seen by other processors or devices.
• The operation cannot be interrupted (that is, once started, the operation continues until completion).

On OpenVMS Alpha, any operation that reads, modifies, and stores data in memory will be broken into several instructions, and can be interrupted between any of those instructions. As a result, if your application expects to modify data in shared memory atomically, you must take steps to guarantee the atomicity of the operation.

An application can depend on the atomicity of operations under any of the following conditions:

• An AST routine within the process shares data with the mainline code.
• The process shares data in a writable global section with another process that executes on the same CPU (that is, in a uniprocessor system).
• The process shares data in a writable global section with another process that may execute concurrently on another CPU (that is, in a multiprocessor system).

Finding the Problem

To find dependencies on atomicity, reexamine use of shared variables (writable items accessed by multiple threads of execution) for hidden or explicit assumptions of atomicity.

Eliminating the Problem

To eliminate general problems of instruction atomicity, you will be able to use one or more of the following methods:

• Use language constructs, where available, that guarantee atomicity to protect shared variables: for example, in C, the VOLATILE declaration.
• Use explicit synchronization rather than relying on assumptions of atomicity.
• Use OpenVMS locking services (such as $ENQ and $DEQ) or LIB$ routines.
• To synchronize with an AST thread, use the $SETAST system service in the mainline code to block the AST and then reenable delivery after the instruction has completed.

For more information on synchronization, see Chapter 6.

2.5.4 Reading or Writing Data Smaller Than a Quadword

Granularity refers to the size of the data that can be read or written to memory as an atomic operation, without interfering with data in adjacent memory locations. Machines such as the VAX that provide granularity at the byte level are said to be byte granular. Alpha systems are quadword granular.¹

Since OpenVMS Alpha is quadword granular, writes to a shared byte, word, or longword may corrupt other data present in the same quadword as the shared data. This occurs when:

• A program attempts to modify a byte, word, or longword.
• An unaligned field of any size crosses an aligned quadword boundary, which creates a byte, word, or longword that must be written independently.

Note

All of the types of data sharing listed in the discussion of atomicity (Section 2.5.3) can create granularity problems in the rest of the quadword containing the intentionally shared data.

In addition, if a process invokes asynchronous system services or asynchronously completing library functions that write a result back to process space, then the data written back can create granularity problems in the quadword that contains it; for example:

• An asynchronous system service that writes to a status block
• An I/O operation that writes to a process buffer
• An I/O operation in which a direct-memory-access (DMA) controller writes to a process buffer

Finding the Problem

To find uses of byte, word, or longword granularity, you can use the following methods:

• Look for intentionally shared data (between an AST and main thread or between processes). Check whether the shared data occupies the same quadword as other data that might be written.
• Look for data written back by asynchronous system services or library calls that complete asynchronously. Check whether that data occupies the same quadword as other data written by another process.
• Look for I/O buffers that contain data written back asynchronously from a device. Check whether the start and end of the buffers occupy the same quadword as data written by another process.

Eliminating the Problem

To eliminate use of granularity at a level smaller than the quadword, you will be able to use one or more of the following methods:

• Put shared items in private quadwords.
• Align I/O buffer heads on quadword boundaries and move any data after the buffer into the next quadword.
• If the problem is not caused by data shared with the system, use a higher-level synchronization mechanism to interlock both intentionally shared data and background data in the same quadword.

Digital compilers assume quadword granularity by default, but to maintain compatibility with your current code, they allow you to specify byte, word, unaligned longword, and unaligned quadword granularity by using the /GRANULARITY qualifier. For more information, see the documentation for the individual compilers.

For more information on read/write granularity, see Chapter 6.

2.5.5 Page Size Considerations

Page size governs the amount of virtual memory allocated by memory management routines and system services. For example, in mixed-architecture OpenVMS Cluster systems, your application may determine the size of certain data buffers based on the VAX page size. Page size is also the basis on which protection is assigned to code and data in memory.

The OpenVMS VAX operating system allocates memory in multiples of 512 bytes. To improve overall system performance, Alpha systems have much larger page sizes, ranging from 8 KB to 64 KB, depending on the specific hardware platform.

Page size is a factor in the management of system resources, such as working set quotas. In addition, memory protection on VAX systems can vary for each 512-byte region of memory; on Alpha systems, the granularity of memory protection is much larger, depending on the system's page-size implementation.

Note

The change to a larger page size affects only applications that explicitly rely on a 512-byte page size, for example, applications that:

• Use "512" to:
  • Compute memory usage.
  • Calculate page table requirements.
• Change protection on a 512-byte granularity.
• Use the system service Create and Map Section ($CRMPSC) to map a file into a specific location in the process address space (for example, to reuse memory when available memory is limited).

Finding the Problem

To find uses of the VAX page size, identify code that manipulates virtual memory in 512-byte chunks or relies on 512-byte memory protection granularity. Search your code for occurrences of numbers such as the decimal values 511, 512, or 513; the hexadecimal values 1FF, 200, or 201; and so forth.

Eliminating the Problem

To eliminate conflicts between the VAX and Alpha page sizes, you will be able to use one or more of the following methods:

• Change hardcoded page size references to symbolic values (assigned at run time using a call to $GETSYI).
• Reevaluate code that assumes that page size and disk (file) block size are equal. On Alpha systems, this assumption is not correct.
• Do not depend on being able to use memory-management-related system services (for example, $CRMPSC, $MGBLSC) to map a file into a fixed, page-size-dependent range of addresses (global section). Consider instead using the $EXPREG system service.

For more information on page size, see Chapter 5.

2.5.6 Order of Read/Write Operations on Multiprocessor Systems

The VAX architecture specifies that if a processor in a multiprocessing system writes multiple data items to memory, these items are written to memory in the order specified. This ordering ensures that the writes become visible to other CPUs in the order in which they were specified by the program and I/O devices.

The guarantee that writes become visible to other CPUs in the same order in which they are specified limits the performance optimization that the system can make. It also makes caches more complex and limits the optimization of cache performance.

To benefit overall system performance, Alpha systems, as well as other RISC systems, can reorder reads and writes to memory. Therefore, writes to memory can become visible to other CPUs in the system in an order different from that in which they were issued.

Note

This section is relevant only to multiprocessor systems. On a uniprocessor system, all memory accesses are completed in the order in which the program requested them.

Finding the Problem

To find instances of reliance on read/write ordering for applications that may execute on multiprocessor systems, identify algorithms that depend upon the order in which data is written: for example, use of flag-passing protocols for synchronization.

Eliminating the Problem

To eliminate problems with the ordering of read and write operations, you will be able to use one or more of the following methods:

• Instead of flag-passing protocols, use system-supplied routines for synchronization, such as the OpenVMS locking system services ($ENQ, $DEQ).
• The Alpha architecture specifies a memory barrier instruction, which causes the hardware to complete all previous memory reads and writes before performing reads and writes following the barrier. Some Alpha languages provide a way of inserting this instruction, but its use will degrade performance.

For more information on synchronization, see Chapter 6.

2.5.7 Immediacy of Arithmetic Exception Reporting

Alpha (and vector VAX) systems treat exceptions differently from scalar VAX systems. Scalar VAX systems use "precise exception reporting;" that is, they guarantee that if an instruction causes an exception, the program counter (PC) that is reported is the address of the instruction that caused the exception. Because no subsequent instructions have been issued or have affected the context of the process, a condition handler can remedy the cause of the exception and resume execution of the program at or after the failing instruction.

To achieve the best possible performance in a pipelined environment, vector VAX and Alpha systems use "imprecise exception reporting;" that is, the PC reported by the exception handler is not guaranteed to be that of the instruction that caused the arithmetic exception. Furthermore, subsequent instructions may complete before the exception is reported.

In practice, very few, if any, programs rely on knowing the specific instruction that caused an arithmetic exception. Typically, when an arithmetic exception occurs, a program does one of the following:

• Logs the exception and continues
• Prints an error message and aborts the subroutine or program
• Restarts the entire subroutine and uses a different algorithm that scales the data to prevent overflow or underflow

If a VAX program performs one of these actions upon encountering an arithmetic exception, it will not be affected by being migrated to a RISC system that uses imprecise exception handling.

Note

Imprecise exception reporting applies only to arithmetic exceptions. For other types of exceptions, such as faults and traps, OpenVMS Alpha uses precise exception reporting, and the specific instruction that caused the exception is reported.

For more information on exception handling, see Section 8.4.1.

2.5.8 Explicit Reliance on the VAX Procedure Calling Standard

The OpenVMS calling standard specifies significantly different calling conventions for Alpha programs than for VAX programs. Application programs that depend explicitly on certain details of the VAX procedure calling conventions must be modified to run as native code on an Alpha system. Such dependencies include:

• Code that locates the placement of arguments relative to the argument pointer (AP)
  In many cases, however, the VAX MACRO--32 Compiler for OpenVMS Alpha compensates for this.
• Code that modifies its return address on the stack
• Code that interprets the contents of a call frame

Both VAX and Alpha compilers provide techniques for accessing procedure arguments. If your code uses these standard mechanisms, you can simply recompile it to run correctly on an Alpha system. If your code does not use these mechanisms, you must rewrite it so that it does. For a description of these standard mechanisms, see the OpenVMS Calling Standard.

Translated code mimics the behavior of VAX procedure calling. Images that contain the dependencies listed here will execute properly under translation on an Alpha system.

2.5.9 Explicit Reliance on VAX Exception-Handling Mechanisms

The mechanics of exception handling differ between VAX and Alpha systems. Chapter 8 discusses the differences in how arithmetic exceptions are dispatched on VAX and Alpha systems. This section focuses on the mechanisms by which code dynamically establishes a condition handler and by which a condition handler accesses the exception state.

2.5.9.1 Establishing a Dynamic Condition Handler

VAX systems provide a number of ways in which an application can establish a condition handler dynamically at run time. The OpenVMS calling standard facilitates this operation for VAX programs by providing a space at the top of a call frame in which executing code can place the address of a condition handler that is to service exceptions that occur in the context of that frame. However, the OpenVMS calling standard provides no such writable area in the procedure descriptor for Alpha procedures.

For instance, a VAX MACRO program might use the following instruction sequence to move the address of a condition handler into a call frame:

 MOVAB    HANDLER,(FP) 

The MACRO--32 Compiler for OpenVMS Alpha parses this statement and generates appropriate Alpha assembly language code that results in the establishment of the condition handler. For more information, see Porting VAX MACRO Code to OpenVMS Alpha.

Note

On VAX systems, the run-time library routine LIB$ESTABLISH and its counterpart LIB$REVERT allow an application to establish and disestablish a condition handler for the current frame. These routines do not exist on an Alpha system; however, compilers may handle these calls properly (such as with FORTRAN intrinsic functions). For more precise information, see Chapter 11 and the documentation for the compilers relevant to your application.

Translated code mimics the VAX mechanism for dynamically establishing a condition handler.

Certain Alpha compilers (and cross-compilers) provide a language-specific mechanism to establish a dynamic condition handler.

For more information on condition handlers, see Chapter 8.

2.5.9.2 Accessing Data in the Signal and Mechanism Arrays

During exception processing, both VAX and Alpha systems push the exception processor status, an exception PC, a signal array, and a mechanism array onto the stack.

Both the signal array and mechanism array have different contents on VAX and Alpha systems; the mechanism array also has different formats on the two platforms. To work properly in either system, a condition handler that accesses data in the signal array or the mechanism array must use the appropriate CHF$ symbols rather than hardcoded offsets. For descriptions of the appropriate CHF$ symbols, see the Bookreader version of the OpenVMS Programming Concepts Manual.

Note

The condition handler cannot successfully locate information in the mechanism array by using hardcoded offsets from AP.

OpenVMS VAX passes five longword arguments to an AST service routine. AST service routines written in VAX MACRO access this information by using offsets from the argument pointer (AP). OpenVMS VAX allows an AST service routine to modify any of these arguments, including the saved registers and the return PC. These modifications can then affect the interrupted program once the AST routine returns.

Although the AST parameter list on Alpha systems also consists of five parameters, the only argument directly intended for the AST procedure is the AST parameter. Although the other arguments are present, they are not used after the AST procedure exits. Because modifying them has no effect on the thread of operation to be resumed at AST exit, a program that relies on such an effect must be changed to use more conventional argument-passing mechanisms to run on an Alpha system.

2.5.11 Explicit Dependency on the Form and Behavior of VAX Instructions

Programs that rely specifically on the execution behavior of VAX MACRO instructions or on binary encoding of VAX instructions must be modified before being recompiled or relinked to run as native code on an Alpha system.

For example, the following coding practices will not work on an Alpha system:

• In VAX MACRO, embedding a block of VAX instructions in a program data area, and modifying a PC to transfer control to this code block
• Examining condition codes or other information in the processor status longword (PSL)

Creating and executing conventional VAX instructions will not work in native Alpha mode.

VAX instructions created at run time will execute by emulation in a translated image.

For more information on code that generates specific VAX instructions at run time, see Porting VAX MACRO Code to OpenVMS Alpha.

Note

¹ The Alpha architecture also supports longword granularity, but assuming longword granularity is not recommended. Digital compilers assume by default that source code does not depend on granularity finer than quadword, but most Digital languages allow you to specify a smaller granularity by using the /GRANULARITY qualifier.

  6459P002.HTM
  OSSG Documentation
  22-NOV-1996 13:07:05.30

Copyright © Digital Equipment Corporation 1996. All Rights Reserved.

Legal