HP OpenVMS Systems Documentation
HP OpenVMS Programming Concepts Manual
9.3.3 Arithmetic Exceptions
On VAX and I64 systems, the architecture ensures that arithmetic exceptions are reported synchronously; that is, an arithmetic instruction that causes an exception (such as an overflow) enters any exception handlers immediately, and subsequent instructions are not 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 alternative 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 the loss of information that is integral to interpreting or rectifying the exception. The program counter (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 new condition code, SS$_HPARITH, to indicate most arithmetic exceptions. Thus, if your application contains a condition-handling routine that performs processing when an integer overflow exception occurs, on VAX systems the application expects to receive the SS$_INTOVF condition code. On Alpha systems, this exception may be indicated by the condition code SS$_HPARITH. It is possible, however, that some higher level languages using RTL routines, for example, LIB$ routines, might convert the SS$_HPARITH into a more precise exception code such as SS$_INTOVF, or generate a precise exception code directly in an arthmetic emulation routine. If a SS$_HPARITH is received as the condition code, it indicates an imprecise Alpha system exception. If a precise integer overflow is received, SS$_INTOVF, it indicates either a VAX system condition or a precise Alpha system condition.
Figure 9-1 shows the format of the SS$_HPARITH exception signal array.
Figure 9-1 SS$_HPARITH Exception Signal Array
This signal array contains three arguments that are specific to the SS$_HPARITH exception: the integer register write mask, floating register write mask, and exception summary arguments of the exception pc and exception ps. The integer register write mask and floating register write 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 exceptions that are being signaled by setting flags in the first 7 bits. Table 9-4 lists the meaning of each of these bits when set.
For more information and recommendations about using arithmetic exceptions on Alpha systems, see Migrating to an OpenVMS AXP System: Recompiling and Relinking Applications. Note that this manual has been archived but is available on the OpenVMS Documentation Web site at:
9.3.4 Unaligned Access Traps (Alpha and I64 Only)
On Alpha and I64 systems, an unaligned access 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 and does not use an instruction that takes an unaligned address as an operand (for example, LDQ_U on Alpha systems). For more information about data alignment, see Section 9.4.2.
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 9-2 illustrates the elements of the signal array returned by the SS$_ALIGN exception.
Figure 9-2 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 (ISR for I64) argument. The
virtual address argument contains the address of the
unaligned data being accessed. The register number
(ISR for I64) argument identifies the target register of the operation.
Most general-purpose run-time library routines handle errors by returning a status in R0 (R8 for I64). In some cases, however, exceptions that occur during the execution of a run-time library routine are signaled. This section tells how run-time library routines signal exception conditions.
Some calls to the run-time library do not or cannot specify an action to be taken. In this case, the run-time library signals the proper exception condition by using the operating system's signaling mechanism.
In order to maintain modularity, the run-time library does not use
exception vectors, which are processwide data locations. Thus, the
run-time library itself does not establish handlers by using the
primary, secondary, or last-chance exception vectors.
On VAX systems, mathematics routines return function values in register
R0 or registers R0 and R1, unless the return values are larger than 64
bits. For this reason, mathematics routines cannot use R0 to return a
completion status and must signal all errors. In addition, all
mathematics routines signal an error specific to the MTH$ facility
rather than a general hardware error.
Although the hardware normally detects integer overflow and floating-point overflow errors, run-time library mathematics routines are programmed with a software check to trap these conditions before the hardware signaling process can occur. This means that they call LIB$SIGNAL instead of allowing the hardware to initiate signaling.
The software check is needed because JSB routines cannot set up condition handlers. The check permits the JSB mathematics routines to add an extra stack frame so that the error message and stack traceback appear as if a CALL instruction had been performed. Because of the software check, JSB routines do not cause a hardware exception condition even when the calling program has enabled the detection of integer overflow. On the other hand, detection of floating-point overflow is always enabled and cannot be disabled.
If an integer or floating-point overflow occurs during a CALL or a JSB
routine, the routine signals a mathematics-specific error such as
MTH$_FLOOVEMAT (Floating Overflow in Math Library) by calling
All mathematics routines are programmed to avoid floating-point underflow conditions. Software checks are made to determine if a floating-point underflow condition would occur. If so, the software makes an additional check:
The user can enable or disable detection of floating-point underflow at
run time by calling the routine LIB$FLT_UNDER.
On VAX systems, you can use the following run-time library routines as arithmetic condition handlers to enable or disable the signaling of decimal overflow, floating-point underflow, and integer overflow:
You can establish these handlers in one of two ways:
You cannot disable the signaling of integer divide-by-zero, floating-point overflow, and floating-point or decimal divide-by-zero.
When the signaling of a hardware condition is enabled, the occurrence of the exception condition causes the operating system to signal the condition as a severe error. When the signaling of a hardware condition is disabled, the occurrence of the condition is ignored, and the processor executes the next instruction in the sequence.
The signaling of overflow and underflow detection is enabled independently for activation of each routine, because the call instruction saves the state of the calling program's hardware enable operations in the stack and then initializes the enable operations for the called routine. A return instruction restores the calling program's enable operations.
These run-time library routines are intended primarily for high-level languages, because you can achieve the same effect in MACRO with the single Bit Set PSW (BISPSW) or Bit Clear PSW (BICPSW) VAX instructions.
These routines allow you to enable and disable detection of decimal overflow, floating-point underflow, and integer overflow for a portion of your routine's execution. Note that the HP BASIC for OpenVMS VAX Systems and HP Fortran compilers provide a compile-time qualifier that permits you to enable or disable integer overflow for your entire routine.
On Alpha and I64 systems, certain RTL routines that process conditions do not exist because the exception conditions defined by the Alpha and Intel Itanium architectures differ somewhat from those defined by the VAX architecture. Table 9-5 lists the run-time library condition-handling support routines available on VAX systems and indicates which are supported on Alpha and I64 systems.
9.5 Condition Values
Error conditions are identified by integer values called condition codes or condition values. The operating system defines condition values to identify errors that might occur during execution of system-defined procedures. Each exception condition has associated with it a unique, 32-bit condition value that identifies the exception condition, and each condition value has a unique, systemwide symbol and an associated message. The condition value is used in both methods of indicating exception conditions, returning a status and signaling.
From a condition value you can determine whether an error has occurred, which error has occurred, and the severity of the error. Table 9-6 describes the fields of a condition value.
Figure 9-3 shows the format of a condition value.
Figure 9-3 Format of a Condition Value
Condition Value Fields
9.5.1 Return Status Convention
Most system-defined procedures are functions of longwords, where the
function value is equated to a condition value. In this capacity, the
condition value is referred to as a return status. You
can write your own routines to follow this convention. See
Section 9.14.3 for information about how to change a signal to a return
status. Each routine description in the HP OpenVMS System Services Reference Manual, HP OpenVMS RTL Library (LIB$) Manual,
OpenVMS Record Management Utilities Reference Manual, and OpenVMS Utility Routines Manual lists the condition values that can be
returned by that procedure.
When a function returns a condition value to your program unit, you should always examine the returned condition value. To check for a failure condition (warning, error, or severe error), test the returned condition value for a logical value of false. The following program segment invokes the run-time library procedure LIB$DATE_TIME, checks the returned condition value (returned in the variable STATUS), and, if an error has occurred, signals the condition value by calling the run-time library procedure LIB$SIGNAL ( Section 9.8 describes signaling):
To check for a specific error, test the return status for a particular condition value. For example, LIB$DATE_TIME returns a success value (LIB$_STRTRU) when it truncates the string. If you want to take special action when truncation occurs, specify the condition as shown in the following example (the special action would follow the IF statement):
126.96.36.199 Using the $VMS_STATUS_SUCCESS Macro
You can use the $VMS_STATUS_SUCCESS macro, defined in stsdef.h, to test an OpenVMS condition value. $VMS_STATUS_SUCCESS depends on the documented format of an OpenVMS condition value, and particularly on the setting of the lowest bit in a condition value. If the lowest bit is set, the condition indicates a successful status, while the bit is clear for an unsuccessful status.
$VMS_STATUS_SUCCESS is used only with condition values that follow the OpenVMS condition status value format, and not with C standard library routines and return values that follow C native status value norms. For deails on the OpenVMS condition status value structure, please see Chapter 9. For information on the return values from the various C standard library routines, see the HP C Run-Time Library Reference Manual for OpenVMS Systems.
For example, the following code demonstrates a test that causes a return on error.