![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
The items in the following list correspond to the numbered items in Example 8-1:
Application condition-handling routines identify which exception is being signaled by checking the condition code returned in the signal array. The following program fragment, taken from Example 8-1, shows how a condition-handling routine can accomplish this task by using the run-time library routine LIB$MATCH_COND:
status = LIB$MATCH_COND( sigs->chf$l_sig_name, /* returned code */
SS$_INTOVF); /* test against */
On Alpha systems, the format of the 32-bit condition code and its location in the signal array are the same as they are on VAX systems. However, the condition codes your condition-handling routine expects to receive on VAX systems may not be meaningful on Alpha systems. Because of architectural differences, some exception conditions that are returned on VAX systems are not supported on Alpha systems.
For software exceptions, Alpha systems support the same set supported by VAX systems, as documented in the online Help Message utility or in the OpenVMS system messages documentation. Hardware exceptions, however, are more architecture specific, especially the arithmetic exceptions. Only a subset of the hardware exceptions supported by VAX systems (documented in the Bookreader version of the OpenVMS Programming Concepts Manual) are also supported on Alpha systems. In addition, the Alpha architecture defines several additional exceptions that are not supported by the VAX architecture.
Table 8-1 lists the VAX hardware exceptions that are not supported on Alpha systems and the Alpha hardware exceptions that are not supported on VAX systems. If the condition-handling routine in your application tests for any of these VAX-specific exceptions, you may need to add the code to test for the equivalent Alpha exceptions. (Section 8.4.1 provides more information about testing for arithmetic exceptions on Alpha systems.)
Note
A translated VAX image run on an Alpha system can still return these VAX exceptions.
| Exception Condition Code | Comment |
|---|---|
| Exceptions Specific to Alpha Systems | |
| SS$_HPARITH--High-performance arithmetic exception | Replaces VAX arithmetic exceptions (see Section 8.4.1) |
| SS$_ALIGN--Data alignment trap | No equivalent on VAX systems |
| Exceptions Specific to VAX Systems | |
| SS$_ARTRES--Reserved arithmetic trap | No equivalent on Alpha systems |
| SS$_COMPAT--Compatibility fault | No equivalent on Alpha systems |
| SS$_DECOVF--Decimal overflow¹ | Replaced by SS$_HPARITH (see Section 8.4.1) |
| SS$_FLTDIV--Float divide-by-zero (trap)¹ | Replaced by SS$_HPARITH (see Section 8.4.1) |
| SS$_FLTDIV_F--Float divide-by-zero (fault) | Replaced by SS$_HPARITH (see Section 8.4.1) |
| SS$_FLTOVF--Float overflow (trap)¹ | Replaced by SS$_HPARITH (see Section 8.4.1) |
| SS$_FLTOVF_F--Float overflow (fault) | Replaced by SS$_HPARITH (see Section 8.4.1) |
| SS$_FLTUND--Float underflow (trap)¹ | Replaced by SS$_HPARITH (see Section 8.4.1) |
| SS$_FLTUND_F--Float underflow (fault) | Replaced by SS$_HPARITH (see Section 8.4.1) |
| SS$_INTDIV--Integer divide-by-zero¹ | Replaced by SS$_HPARITH (see Section 8.4.1) |
| SS$_INTOVF--Integer overflow¹ | Replaced by SS$_HPARITH (see Section 8.4.1) |
| SS$_TBIT--Trace pending | No equivalent on Alpha systems |
| SS$_OPCCUS--Opcode reserved to customer | No equivalent on Alpha systems |
| SS$_RADMOD--Reserved addressing mode | No equivalent on Alpha systems |
| SS$_SUBRNG--INDEX subscript range check | No equivalent on Alpha systems |
On a VAX system, the architecture ensures that arithmetic exceptions are reported synchronously; that is, a VAX arithmetic instruction that causes an exception (such as an overflow) enters any exception handlers immediately and no subsequent instructions are executed. The program counter (PC) reported to the exception handler is that of the failing arithmetic instruction. This allows application programs, for example, to resume the main sequence, with the failing operation being emulated or replaced by some equivalent or alternate set of operations.
On Alpha systems, arithmetic exceptions are reported asynchronously; that is, implementations of the architecture can allow a number of instructions (including branches and jumps) to execute beyond that which caused the exception. These instructions may overwrite the original operands used by the failing instruction, thus causing information integral to interpreting or rectifying the exception to be lost. The PC reported to the exception handler is not that of the failing instruction, but rather is that of some subsequent instruction. When the exception is reported to an application's exception handler, it may be impossible for the handler to fix up the input data and restart the instruction.
Because of this fundamental difference in arithmetic exception reporting, Alpha systems define a single condition code, SS$_HPARITH, to indicate all of the arithmetic exceptions. Thus, if your application contains a condition-handling routine that performs processing when an integer overflow exception occurs, on VAX systems it expects to receive the SS$_INTOVR condition code. On Alpha systems, this exception is indicated by the condition code SS$_HPARITH. In this way, condition-handling routines in applications cannot mistake an Alpha arithmetic exception with the corresponding VAX exception. This is important because the processing performed by the applications may be architecture specific.
Figure 8-3 shows the format of the SS$_HPARITH exception signal array.
Figure 8-3 SS$_HPARITH Exception Signal Array
This signal array contains three arguments that are specific to the SS$_HPARITH exception: the integer register write mask, the floating register write mask, and the exception summary arguments. The integer and floating register mask arguments indicate the registers that were targets of instructions that set bits in the exception summary argument. Each bit in the mask represents a register. The exception summary argument indicates the type of exception (or exceptions) that is being signaled by setting flags in the first seven bits. Table 8-2 lists the meaning of each of these bits when set.
| Bit | Meaning |
|---|---|
| 0 | Software completion. |
| 1 | Invalid floating arithmetic, conversion, or comparison operation. |
| 2 | Invalid attempt to perform a floating divide operation with a divisor of zero. Note that integer divide-by-zero is not reported. |
| 3 | Floating arithmetic or conversion operation overflowed the destination exponent. |
| 4 | Floating arithmetic or conversion operation underflowed the destination exponent. |
| 5 | Floating arithmetic or conversion operation gave a result that differed from the mathematically exact result. |
| 6 | Integer arithmetic or conversion operation from floating point to integer overflowed the destination precision. |
Recommendations
The following recommendations provide guidelines for determining if a condition-handling routine that performs processing in response to an arithmetic exception needs modification to run on an Alpha system:
Note
A translated VAX image running on an Alpha system can return VAX exception conditions, including arithmetic exception conditions.
On an Alpha system, a data-alignment trap is generated when an attempt is made to load or store a longword or quadword to or from a register using an address that does not have the natural alignment of the particular data reference, without using an Alpha instruction that takes an unaligned address as an operand (LDQ_U). (For more information about data alignment, see Chapter 7.)
Compilers on Alpha systems typically avoid triggering alignment faults by:
Note, however, that compilers cannot align dynamically defined data. Thus, alignment faults may be triggered.
An alignment exception is identified by the condition code SS$_ALIGN. Figure 8-4 shows the elements of the signal array returned by the SS$_ALIGN exception.
Figure 8-4 SS$_ALIGN Exception Signal Array
This signal array contains two arguments specific to the SS$_ALIGN exception: the virtual address argument and the register number argument. The virtual address argument contains the address of the unaligned data being accessed. The register number argument identifies the target register of the operation.
Recommendation
In addition to condition-handling routines, applications that include condition handling must perform other tasks, such as identifying their condition-handling routine to the system. The run-time library provides a set of routines that allows applications to perform these tasks. For example, applications can call the run-time library routine LIB$ESTABLISH to identify (or establish) the condition-handling routine they want executed when an exception is signaled.
Because of differences between the VAX architecture and the Alpha architecture and between the calling standards for both architectures, the way in which many of these tasks are accomplished is not the same. Table 8-3 lists the run-time library condition-handling support routines available on VAX systems and indicates which are supported on Alpha systems.
| Routine | Support on Alpha Systems |
|---|---|
| Arithmetic Exception Support Routines | |
| LIB$DEC_OVER--Enable or disable signaling of decimal overflow | Not supported |
| LIB$FIXUP_FLT--Change floating-point reserved operand to a specified value | Not supported |
| LIB$FLT_UNDER--Enable or disable signaling of floating-point underflow | Not supported |
| LIB$INT_OVER--Enable or disable signaling of integer overflow | Not supported |
| General Condition-Handling Support Routines | |
| LIB$DECODE_FAULT--Analyze instruction context for fault | Not supported |
| LIB$ESTABLISH--Establish a condition handler | Not supported by RTL but supported by compilers to provide compatibility |
| LIB$MATCH_COND--Match condition value | Supported |
| LIB$REVERT--Delete a condition handler | Not supported by RTL but supported by compilers to provide compatibility |
| LIB$SIG_TO_STOP--Convert a signaled condition to a condition that cannot be continued | Supported |
| LIB$SIG_TO_RET--Convert a signal to a return status | Supported |
| LIB$SIM_TRAP--Simulate a floating-point trap | Not supported |
| LIB$SIGNAL--Signal an exception condition | Supported |
| LIB$STOP--Stop execution by using signaling | Supported |
Recommendations
The following list provides specific guidelines for applications that use run-time library routines:
The FORTRAN program in Example 8-2 uses the RTL routine LIB$ESTABLISH to specify a condition-handling routine that tests for integer overflow by specifying the condition code SS$_INTOVF. On VAX systems, you must compile the program with the /CHECK=OVERFLOW qualifier to enable integer overflow detection.
To get this program to run on an Alpha system, you must change the condition code from SS$_INTOVF to SS$_HPARITH. (You can determine the type of overflow by examining the exception summary argument in the signal array. For more information, see the compiler documentation.) As on VAX systems, you must specify the /CHECK=OVERFLOW qualifier on the compile command line to enable overflow detection. The call to the LIB$ESTABLISH routine does not have to be removed because DEC Fortran accepts this routine as an intrinsic function.
Example 8-2 Sample Condition-Handling Program
C This program types a maximum value of integers
C Compile with /CHECK=OVERFLOW and the /EXTEND_SOURCE qualifiers
INTEGER*4 int4
EXTERNAL HANDLER
CALL LIB$ESTABLISH (HANDLER) (1)
int4=2147483645
WRITE (6,*) ' Beginning DO LOOP, adding 1 to ', int4
DO I=1,10
int4=int4+1
WRITE (6,*) ' INT*4 NUMBER IS ', int4
END DO
WRITE (6,*) ' The end ...'
END
C This is the condition-handling routine
INTEGER*4 FUNCTION HANDLER (SIGARGS, MECHARGS)
INTEGER*4 SIGARGS(*),MECHARGS(*)
INCLUDE '($FORDEF)'
INCLUDE '($SSDEF)'
INTEGER INDEX
INTEGER LIB$MATCH_COND
INDEX = LIB$MATCH_COND (SIGARGS(2), SS$_INTOVF) (2)
IF (INDEX .EQ. 0 ) THEN
HANDLER = SS$_RESIGNAL
ELSE IF (INDEX .GT. 0) THEN
WRITE (6,*) 'Arithmetic exception detected...'
CALL LIB$STOP(SIGARGS(1))
END IF
END
The items in the following list correspond to the numbered items in Example 8-2:
The following example shows how to compile, link, and run the program in Example 8-2.
$ FORTRAN/EXTEND_SOURCE/CHECK=OVERFLOW HANDLER_EX.FOR
$ LINK HANDLER_EX
$ RUN HANDLER_EX
Beginning DO LOOP, adding 1 to 2147483645
INT*4 NUMBER IS 2147483646
INT*4 NUMBER IS 2147483647
Arithmetic exception detected...
%TRACE-F-TRACEBACK, symbolic stack dump follows
Image Name Module Name Routine Name Line Number rel PC abs PC
INT_OVR_HAND INT_OVR_HANDLER HANDLER 1637 00000238 00020238
DEC$FORRTL 0 000651E4 001991E4
----- above condition handler called with exception 00000504:
%SYSTEM-F-HPARITH, high performance arithmetic trap, Imask=00000001, Fmask=00000
000, summary=40, PC=000200E0, PS=0000001B
-SYSTEM-F-INTOVF, arithmetic trap, integer overflow at PC=000200E0, PS=0000001B
----- end of exception message
0 84FE9FFC 84FE9FFC
INT_OVR_HAND INT_OVR_HANDLER INT_OVR_HANDLER 15 000000E0 000200E0
0 84EFD918 84EFD918
0 7FF23EE0 7FF23EE0
This chapter describes resources used to translate a VAX application to
run on an Alpha system.
9.1 DECmigrate for OpenVMS Alpha
DECmigrate for OpenVMS Alpha is used to translate images for which the source code is not available. The VAX Environment Software Translator (VEST) component of DECmigrate translates the VAX binary image file into a native Alpha image. The translated image runs under the Translated Image Environment (TIE) on an Alpha computer. (TIE is a shareable image that is included with the OpenVMS Alpha operating system.) Translation does not involve running an OpenVMS VAX image under emulation or interpretation (with certain limited exceptions). Instead, the new OpenVMS Alpha image contains Alpha instructions that perform operations identical to those performed by the instructions in the original OpenVMS VAX image.
A translated image generally runs as fast on an Alpha computer as the original image runs on a VAX computer. However, a translated image does not benefit from the optimizing compilers that take full advantage of the Alpha architecture. Therefore, a translated image typically runs about 25 to 40 percent as fast as a native OpenVMS Alpha image. The primary causes for this reduced performance are unaligned data and the extensive use of complex VAX instructions.
DECmigrate translation support is limited to the language features, system services, and run-time library entry points that existed on OpenVMS VAX Version 5.5-2.
A second function of DECmigrate is to analyze images to identify specific incompatibilities for an Alpha computer. Depending on the type of incompatibility, you can choose to specify a compiler qualifier that will compensate for the problem or make changes to the code.
For more information on image translation and VEST, see DECmigrate for OpenVMS AXP Systems Translating Images.
9.2 DECmigrate: Translated Image Support
DECmigrate Version 1.1A runs on Alpha systems running OpenVMS Version
6.1 or later. The images it translates require this version or a later
version to execute. Translated images are generally forward compatible
but not backward compatible; that is, images translated with DECmigrate
Version 1.1A can run only on Alpha systems running OpenVMS Version 6.1
or later while images translated with DECmigrate Version 1.0 can run on
OpenVMS Alpha Version 1.0 and later. Table 9-1 correlates the
versions of OpenVMS Alpha systems with the different versions of
DECmigrate that support them.
| DECmigrate Version Used to Translate Images | OpenVMS Alpha Support for Translated Images | ||
|---|---|---|---|
| Version 1.0 | Version 1.5 | Version 6.1 and later | |
| Version 1.0 | Yes | Yes | Yes |
| Version 1.1 | No | Yes | Yes |
| Version 1.1A | No | No | Yes |
Image translation is one means of migrating all or part of a VAX application to OpenVMS Alpha. The DECmigrate for OpenVMS AXP VAX Environment Software Translator utility (VEST) creates a translated image by converting a VAX executable or shareable image into a functionally equivalent Alpha image. VEST is a component of the optional layered product DECmigrate for OpenVMS AXP.
When a translated image runs on OpenVMS Alpha, the Translated Image Environment (TIE) provides the VAX environment required for the image to execute properly. The TIE consists of the shareable images TIE$SHARE and TIE$EMULAT_TV, which perform VAX complex instructions. For information on the role of image translation in a migration strategy, see the manual DECmigrate for OpenVMS AXP Systems Translating Images.
The following subsections discuss these topics:
Interoperability Between Native and Translated Images
The TIE works together with other components of OpenVMS Alpha to enable native and translated images to call one another. If you are developing applications or run-time libraries that rely on interoperability, you need to follow certain procedures when compiling, linking, or translating. See the first restriction described in Section 9.3.1.4.
Use the DCL RUN command to run a translated image. For example:
$ RUN FOO_TV.EXE
Note that the translated image does not run correctly unless OpenVMS Alpha includes the appropriate translated shareable images and run-time libraries. When you translate an image, VEST requires the image information files (IIFs---file type .IIF) corresponding to whichever images and libraries the input image refers to. These .IIF files enable VEST to create a translated image that correctly refers to the translated versions of the shareable images and libraries. An image information file used at image translation must exactly correspond to the version of the translated shareable image or run-time library available on OpenVMS Alpha.
OpenVMS Alpha includes a set of translated run-time libraries and a matching set of image information files, which are listed in Section 9.4. Check these lists to determine if they include the libraries or shareable images referred to by images you want to translate and run. If OpenVMS Alpha does not include the required shared images or libraries, refer to DECmigrate for OpenVMS AXP Systems Translating Images. This manual describes how to create and use image information files.
6459P009.HTM OSSG Documentation 22-NOV-1996 13:07:17.92
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.