![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
To ensure that an operation that can be performed atomically on a VAX system by a VAX instruction is performed atomically in a translated image, specify the INSTRUCTION_ATOMICITY keyword to the /PRESERVE qualifier.
To ensure that simultaneous updates to adjacent bytes within a longword or quadword can be accomplished without interfering with each other, specify the MEMORY_ATOMICITY keyword to the /PRESERVE qualifier.
To ensure that read/write operations appear to occur in the order you specify them, specify the READ_WRITE_ORDERING keyword to the /PRESERVE qualifier.
This chapter describes how to check the data your application uses for
dependencies on the VAX architecture. The chapter also describes the
effect your choice of data type can have on the size and performance of
your application on an Alpha system.
7.1 Overview
The data types supported by high-level programming languages, such as int in C or INTEGER*4 in FORTRAN, provide applications with a degree of data portability because they hide the machine-specific details of the underlying native data types. The languages map their data types to the native data types supported by the target platform. For this reason, you may be able to successfully recompile and run an application that runs on VAX systems on an Alpha system without modifying the data declarations it contains.
However, if your application contains any of the following assumptions about data types, you may need to modify your source code:
To provide data compatibility, the Alpha architecture has been designed to support many of the same native data types as the VAX architecture. Table 7-1 lists the native data types supported by both architectures. (See the Alpha Architecture Reference Manual for more information about the formats of the data types.)
| VAX Data Types | Alpha Data Types |
|---|---|
| byte | byte |
| word | word |
| longword | longword |
| quadword | quadword |
| octaword | -- |
| F_floating | F_floating |
| D_floating (56-bit precision) | D_floating (53-bit precision) |
| G_floating | G_floating |
| H_floating | X_floating |
| -- | S_floating (IEEE) |
| -- | T_floating (IEEE) |
| Variable-length bit field | -- |
| Absolute queue | Absolute longword queue |
| -- | Absolute quadword queue |
| Self-relative queue | Self-relative longword queue |
| -- | Self-relative quadword queue |
| Character string | -- |
| Trailing numeric string | -- |
| Leading separate numeric string | -- |
| Packed decimal string | -- |
Recommendations
Unless your application depends on the format or size of the underlying native VAX data types, you may not have to modify your application because of changes to the data-type mappings. Wherever possible, the compilers on Alpha systems map their data types to the same native data types as they do on VAX systems. For those VAX data types that are not supported by the Alpha architecture, the compilers map their data types to the closest equivalent native Alpha data type. (For more information about how the compilers on Alpha systems map the data types they support to native Alpha data types, see Chapter 11 and compiler documentation.)
The following list provides guidelines that can be helpful for certain types of data declarations:
Example 7-1 Assumptions About Data Types in VAX C Code
typedef struct {
char small;
short medium;
long large;
} MYSTRUCT ;
main()
{
int a1;
long b1;
MYSTRUCT c1;
a1 = &c1;
b1 = &c1;
a1->small = 1;
b1->small = 2;
}
MYSTRUCT *a1,*b2;
Even though your application may recompile and run successfully on an
Alpha system, your data-type selection may not take full advantage of
the benefits of the Alpha architecture. In particular, data-type
selection can impact the ultimate size of your application and its
performance on an Alpha system.
7.3.1 Effect of Data-Type Selection on Code Size
On VAX systems, applications typically use the smallest size data type adequate for the data. For example, to represent a value between 32,768 and -32,767 in an application written in C, you might declare a variable of type short. On VAX systems, this practice conserves storage and, because the VAX architecture supports instructions that operate on all sizes of data types, does not affect efficiency.
On an Alpha system, byte- and word-sized data incurs more overhead than
longword- or quadword-sized data because the Alpha architecture does
not support instructions that manipulate these smaller data types. Each
reference to a byte or word, which generates a single instruction on a
VAX system, generates a sequence of instructions on an Alpha system, in
which the longword containing the byte or word is fetched, manipulated
so that only the target bytes are modified, and then stored. For
frequently referenced data, these additional instructions can
significantly add to the total size of your application on an Alpha
system.
7.3.2 Effect of Data-Type Selection on Performance
Another aspect of data-type selection is data alignment. Alignment is an attribute of a data item that refers to its placement in memory. The mixture of byte-sized, word-sized, and larger data types, typically found in data-structure definitions and static data areas in applications on VAX systems, can lead to data that is not aligned on natural boundaries. (A data item is naturally aligned when its address is a multiple of its size in bytes.)
Accessing unaligned data incurs more overhead than accessing aligned data on both VAX and Alpha systems. However, VAX systems use microcode to minimize the performance impact of unaligned data. On Alpha systems, there is no hardware assistance. References to unaligned data trigger a fault, which must be handled by the system's PALcode. While the fault is being handled, the instruction pipeline must be stopped. Thus, the cost of an unaligned reference in performance is dramatically higher on Alpha systems.
The compilers on Alpha systems attempt to minimize the performance impact by generating a special unaligned reference instruction sequence when an unaligned reference is known at compile time. This prevents a run-time unaligned fault from occurring. Unaligned references that appear at run time must be handled as unaligned reference faults.
Recommendations
Given the potential impact of data-type selection on code size and performance, you might think you should change all byte- and word-sized data declarations to longwords to eliminate the extra instructions required for byte and word accesses and improve alignment. However, before making sweeping changes to your data declarations, consider the following factors:
Taking these factors into consideration, use the following guidelines when examining data-type selections:
The data structure defined in Example 7-1 shows these data-type selection concerns. The structure definition, called mystruct, is made up of byte-, word-, and longword-sized data, as follows:
struct{
char small;
short medium;
long large;
} mystruct ;
When compiled using VAX C, the structure is laid out in memory as shown in Figure 7-1.
Figure 7-1 Alignment of mystruct Using VAX C
When compiled using the DEC C for OpenVMS Alpha systems compiler, the structure is padded to achieve natural alignment, as shown in Figure 7-2. Note that by adding a byte of padding after the first field, Small, both the following members of the structure are aligned.
Figure 7-2 Alignment of mystruct Using DEC C for OpenVMS Alpha Systems
Note that the byte- and word-sized fields of the data structure still require multiple instruction sequences for access. If the fields Small and Medium are frequently referenced, and the entire structure is not frequently replicated, consider redefining the data structure to use longword data types. If, however, the fields are not frequently referenced or the data structure is frequently replicated, the cost of the byte or word references is a design trade-off the programmer must make.
This chapter describes the effect of differences between the VAX
architecture and the Alpha architecture on the condition-handling code
in your application.
8.1 Overview
For the most part, the condition-handling code in your application will work correctly on an Alpha system, especially if your application uses the condition-handling facilities provided by the high-level language in which it is written, such as the END, ERR, and IOSTAT specifiers in FORTRAN. These language capabilities insulate applications from architecture-specific aspects of the underlying condition-handling facility.
However, there are certain differences between the Alpha condition-handling facility and the VAX condition-handling facility that may require you to modify your source code, including:
The following sections describe these changes in more detail and
provide guidelines to help you decide if modifying your source code is
necessary.
8.2 Establishing Dynamic Condition Handlers
The OpenVMS Alpha run-time libraries (RTLs) do not contain the routine LIB$ESTABLISH, which the OpenVMS VAX RTLs contain. Due to the nature of the OpenVMS Alpha calling standard, setting up condition handlers is done by compilers.
For those programs that need to dynamically establish condition handlers, some Alpha languages give special treatment for calls to LIB$ESTABLISH and generate the appropriate code without actually calling an RTL routine. The following languages support LIB$ESTABLISH semantics in a compatible fashion with the corresponding VAX language:
The calling sequence of user-written condition-handling routines remains the same on Alpha systems as it is on VAX systems. Condition-handling routines declare two arguments to access the data the system returns when it signals an exception condition. The system uses two arrays, the signal array and the mechanism array, to convey information that identifies which exception condition triggered the signal and to report on the state of the processor when the exception occurred.
The format of the signal array and the mechanism array is defined by the system and is documented in the Bookreader version of the OpenVMS Programming Concepts Manual. On Alpha systems, the data returned in the signal array and its format is the same as it is on VAX systems, as shown in Figure 8-1.
Figure 8-1 32-Bit Signal Array on VAX and Alpha Systems
The following table describes the arguments in the signal array:
| Argument | Description |
|---|---|
| Argument Count | On Alpha and VAX systems, this argument contains a positive integer that indicates the number of longwords that follow in the array. |
| Condition Code | On Alpha and VAX systems, this argument is a 32-bit code that uniquely identifies a hardware or software exception condition. The format of the condition code, which remains unchanged on Alpha systems, is described in OpenVMS Programming Interfaces: Calling a System Routine. Note, however, that Alpha systems do not support every condition code returned on VAX systems and define condition codes that cannot be returned on a VAX system. Section 8.4 lists VAX condition codes that cannot be returned on Alpha systems. |
| Optional Message Sequence | These arguments provide additional information about the particular exception returned and vary for each exception. The Bookreader version of the OpenVMS Programming Concepts Manual describes these arguments for VAX exceptions. |
| Program Counter (PC) | The address of the next instruction to be executed when the exception occurred, if the exception is a trap; or the address of the instruction that caused the exception, if the exception is a fault. On Alpha systems, this argument contains the lower 32 bits of the PC (which is 64 bits long on Alpha systems). |
| Processor Status Longword (PSL) | A formatted 32-bit argument that describes the status of the processor when the exception occurred. On Alpha systems, this argument contains the lower 32 bits of the Alpha 64-bit processor status (PS) quadword. |
On Alpha systems, the mechanism array returns much of the same data that it does on VAX systems; however, its format is different. The mechanism array returned on Alpha systems preserves the contents of a larger set of integer scratch registers as well as the floating-point scratch registers. In addition, because these registers are 64 bits long, the mechanism array is constructed of quadwords (64 bits) on Alpha systems, not longwords (32 bits) as it is on VAX systems. Figure 8-2 compares the format of the mechanism array on VAX and Alpha systems.
Figure 8-2 Mechanism Array on VAX and Alpha Systems
The following table describes the arguments in the mechanism array:
| Argument | Description |
|---|---|
| Argument Count | On VAX systems, this argument contains a positive integer that represents the number of longwords that follow in the array. On Alpha systems, this argument represents the number of quadwords in the mechanism array, not counting the argument count quadword (always 43 on Alpha systems). |
| Flags | On Alpha systems, this argument contains various flags to communicate additional information. For example, if bit 0 is set, it indicates that the process has already performed a floating-point operation and the floating-point registers in the array are valid (no equivalent in the mechanism array on VAX systems). |
| Frame Pointer (FP) | On VAX and Alpha systems, this argument contains the address of the call frame on the stack that established the condition handler. |
| Depth | On VAX and Alpha systems, this argument contains an integer that represents the frame number of the procedure that established the condition-handling routine, relative to the frame that incurred the exception. |
| Reserved | Reserved. |
| Handler Data Address | On Alpha systems, this argument contains the address of the handler data quadword, when a handler is present (no equivalent in the mechanism array on VAX systems). |
| Exception Stack Frame Address | On Alpha systems, this argument contains the address of the exception stack frame (no equivalent in the mechanism array on VAX systems). |
| Signal Array Address | On Alpha systems, this argument contains the address of the signal array (no equivalent in the mechanism array on VAX systems). |
| Registers | On VAX and Alpha systems, the mechanism array includes the contents of scratch registers. On Alpha systems, this includes a much larger set of registers and also includes a corresponding set of floating-point registers. |
Recommendations
Because the 32-bit signal array is the same on Alpha systems as it is on VAX systems, you may not need to modify the source code of your condition-handling routine. However, the changes to the mechanism array may require changes to your source code. In particular, check the following:
Example 8-1 presents a condition-handling routine written in C.
Example 8-1 Condition-Handling Routine
#include <ssdef.h> #include <chfdef.h> . . . (1) int cond_handler( sigs, mechs ) struct chf$signal_array *sigs; struct chf$mech_array *mechs; { int status; (2) status = LIB$MATCH_COND(sigs->chf$l_sig_name, /* returned code */ SS$_INTOVF); /* test against */ (3) if(status != 0) { /* ...Condition matched. Perform processing. */ return SS$_CONTINUE; } else { /* ...Condition does not match. Resignal exception. */ return SS$_RESIGNAL; } }
6459P008.HTM OSSG Documentation 22-NOV-1996 13:07:16.32
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.