[Digital logo]

Migrating an Application from OpenVMS VAX to OpenVMS Alpha

Previous | Contents

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:

Eliminating the Problem

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

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

2.5.3 Shared Access to Data

An atomic operation is one in which:

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:

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:

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:


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:

Finding the Problem

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

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:

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.


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

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:

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.


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:

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:

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.


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:

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. 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:


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.


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. 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.


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

2.5.10 Modification of the VAX AST Parameter List

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:

For more information on migrating VAX MACRO code, see Porting VAX MACRO Code to OpenVMS Alpha.

2.5.12 Generation of VAX Instructions at Run Time

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.


¹ 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.

Previous | Next | Contents | [Home] | [Comments] | [Ordering info] | [Help]


  OSSG Documentation
  22-NOV-1996 13:07:05.30

Copyright © Digital Equipment Corporation 1996. All Rights Reserved.