HP OpenVMS Systems Documentation

Content starts here

OpenVMS Programming Concepts Manual

Previous Contents Index

Change-Mode and Compatibility-Mode Handlers

Two types of hardware exception can be handled in a way different from the normal condition-handling mechanism described in this chapter. The two types of hardware exception are as follows:

  • Traps caused by change-mode-to-user or change-mode-to-supervisor instructions
  • On VAX systems, compatibility mode faults

You can use the Declare Change Mode or Compatibility Mode Handler (SYS$DCLCMH) system service to establish procedures to receive control when one of these conditions occurs. The SYS$DCLCMH system service is described in the OpenVMS System Services Reference Manual.

9.3.2 Exception Conditions

On Alpha systems, the condition values that your condition-handling routine expects to receive on VAX systems may no longer be meaningful, even though the format of the 32-bit condition value and its location in the signal array are the same as they are on VAX systems. Because of architectural differences, some exception conditions that are returned on VAX systems are not supported on Alpha systems.

On Alpha systems, because hardware exceptions are more architecture specific than software exceptions, only a subset of the hardware exceptions supported on VAX systems are also supported on Alpha systems. In addition, the Alpha architecture defines several additional exceptions that are not supported on VAX systems.

Table 9-2 lists the Alpha exceptions that are not supported on VAX systems and VAX hardware exceptions that are not supported on Alpha systems. For some arithmetic exceptions, Alpha software produces VAX compatible exceptions that are not supported by the hardware itself. See Section 9.3.3 for a discussion of SS$_HPARITH, a generic Alpha exception condition that software may replace with specific VAX exceptions.

Table 9-2 Architecture-Specific Hardware Exceptions
Exception Condition Code Comment
New Alpha Exceptions
SS$_HPARITH--High-performance arithmetic exception Generated for most Alpha arithmetic exceptions (see Section 9.3.3)
SS$_ALIGN--Data alignment trap No VAX equivalent
VAX Specific Hardware Exceptions
SS$_ARTRES--Reserved arithmetic trap No Alpha system equivalent
SS$_COMPAT--Compatibility fault No Alpha system equivalent
SS$_DECOVF--Decimal overflow 1 Replaced by SS$_HPARITH
(see Section 9.3.3)
SS$_FLTDIV--Float divide-by-zero (trap) 1 Replaced by SS$_HPARITH
(see Section 9.3.3)
SS$_FLTDIV_F--Float divide-by-zero (fault) Replaced by SS$_HPARITH (see Section 9.3.3)
SS$_FLTOVF--Float overflow (trap) 1 Replaced by SS$_HPARITH
(see Section 9.3.3)
SS$_FLTOVF_F--Float overflow (fault) Replaced by SS$_HPARITH (see Section 9.3.3)
SS$_FLTUND--Float underflow (trap) 1 Replaced by SS$_HPARITH
(see Section 9.3.3)
SS$_FLTUND_F--Float underflow (fault) Replaced by SS$_HPARITH
(see Section 9.3.3)
SS$_INTDIV--Integer divide-by-zero 1 Replaced by SS$_HPARITH
(see Section 9.3.3)
SS$_INTOVF--Integer overflow 1 Replaced by SS$_HPARITH
(see Section 9.3.3)
SS$_TBIT--Trace pending No Alpha system equivalent
SS$_OPCCUS--Opcode reserved to customer No Alpha system equivalent
SS$_RADMOD--Reserved addressing mode No Alpha system equivalent
SS$_SUBRNG--INDEX subscript range check No Alpha system equivalent

1On Alpha systems, this condition may be generated by software.

9.3.3 Arithmetic Exceptions

On VAX systems, 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 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-3 lists the meaning of each of these bits when set.

Table 9-3 Exception Summary Argument Fields
Bit Meaning When Set
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.

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

9.3.4 Unaligned Access Traps (Alpha Only)

On Alpha 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 do not use an Alpha instruction that takes an unaligned address as an operand (LDQ_U). For more information about data alignment, see Section 9.4.2.

Alpha compilers typically avoid triggering alignment faults by:

  • Aligning static data on natural boundaries by default. (This default behavior can be overridden by using a compiler qualifier.)
  • Generating special inline code sequences for data that is known to be unnaturally aligned at compile time.

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

9.4 How Run-Time Library Routines Handle Exceptions

Most general-purpose run-time library routines handle errors by returning a status in R0. 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.

9.4.1 Exception Conditions Signaled from Mathematics Routines (VAX Only)

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. Integer Overflow and Floating-Point Overflow

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 LIB$SIGNAL explicitly. Floating-Point Underflow

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:

  • If the immediate calling program (CALL or JSB) has enabled floating-point underflow traps, a mathematics-specific error condition is signaled.
  • Otherwise, the result is corrected to zero and execution continues with no error condition.

The user can enable or disable detection of floating-point underflow at run time by calling the routine LIB$FLT_UNDER.

9.4.2 System-Defined Arithmetic Condition Handlers

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:

  • LIB$DEC_OVER---Enables or disables the signaling of a decimal overflow. By default, signaling is disabled.
  • LIB$FLT_UNDER---Enables or disables the signaling of a floating-point underflow. By default, signaling is disabled.
  • LIB$INT_OVER---Enables or disables the signaling of an integer overflow. By default, signaling is enabled.

You can establish these handlers in one of two ways:

  • Invoke the appropriate handler as a function specifying the first argument as 1 to enable signaling.
  • Invoke the handler with command qualifiers when you compile your program. (Refer to your program language manuals.)

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 VAX BASIC and Compaq Fortran compilers provide a compile-time qualifier that permits you to enable or disable integer overflow for your entire routine.

On Alpha systems, certain RTL routines that process conditions do not exist because the exception conditions defined by the Alpha architecture differ somewhat from those defined by the VAX architecture. Table 9-4 lists the run-time library condition-handling support routines available on VAX systems and indicates which are supported on Alpha systems.

Table 9-4 Run-Time Library Condition-Handling Support Routines
Routine Availability on Alpha Systems
Arithmetic Exception Support Routines
LIB$DEC_OVER--Enables or disables signaling of decimal overflow Not supported
LIB$FIXUP_FLT--Changes floating-point reserved operand to a specified value Not supported
LIB$FLT_UNDER--Enables or disables signaling of floating-point underflow Not supported
LIB$INT_OVER--Enables or disables signaling of integer overflow Not supported
General Condition-Handling Support Routines
LIB$DECODE_FAULT---Analyzes instruction context for fault Not supported
LIB$ESTABLISH---Establishes a condition handler Not supported (languages may support for compatibility)
LIB$MATCH_COND---Matches condition value Supported
LIB$REVERT--Deletes a condition handler Not supported (languages may support for compatibility)
LIB$SIG_TO_STOP---Converts a signaled condition to a condition that cannot be continued Supported
LIB$SIG_TO_RET---Converts a signal to a return status Supported
LIB$SIM_TRAP---Simulates a floating-point trap Not supported
LIB$SIGNAL---Signals an exception condition Supported
LIB$STOP---Stops execution by using signaling Supported

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-5 describes the fields of a condition value.

Table 9-5 Fields of a Condition Value
Field Bits Meaning
FAC_NO <27:16> Indicates the system facility in which the condition occurred
MSG_NO <15:3> Indicates the condition that occurred
SEVERITY <2:0> Indicates whether the condition is a success (bit <0> = 1) or a failure (bit <0> = 0) as well as the severity of the error, if any

Figure 9-3 shows the format of a condition value.

Figure 9-3 Format of a Condition Value

Condition Value Fields


The severity of the error condition. Bit <0> indicates success (logical true) when set and failure (logical false) when clear. Bits <1> and <2> distinguish degrees of success or failure. The three bits, when taken as an unsigned integer, are interpreted as described in Table 9-6. The symbolic names are defined in module $STSDEF.

Table 9-6 Severity of Error Conditions
Value Symbol Severity Response
0 STS$K_WARNING Warning Execution continues, unpredictable results
1 STS$K_SUCCESS Success Execution continues, expected results
2 STS$K_ERROR Error Execution continues, erroneous results
3 STS$K_INFO Information Execution continues, informational message displayed
4 STS$K_SEVERE Severe error Execution terminates, no output
5     Reserved for Compaq
6     Reserved for Compaq
7     Reserved for Compaq

condition identification

Identifies the condition uniquely on a systemwide basis.


Four control bits. Bit <28> inhibits the message associated with the condition value from being printed by the SYS$EXIT system service. After using the SYS$PUTMSG system service to display an error message, the system default handler sets this bit. It is also set in the condition value returned by a routine as a function value, if the routine has also signaled the condition, so that the condition has been either printed or suppressed. Bits <29:31> must be zero; they are reserved for Compaq.

When a software component completes execution, it returns a condition value in this format. When a severity value of warning, error, or severe error has been generated, the status value returned describes the nature of the problem. Your program can test this value to change the flow of control or to generate a message. Your program can also generate condition values to be examined by other routines and by the command language interpreter. Condition values defined by customers must set bits <27> and <15> so that these values do not conflict with values defined by Compaq.

message number

The number identifying the message associated with the error condition. It is a status identification, that is, a description of the hardware exception condition that occurred or a software-defined value. Message numbers with bit <15> set are specific to a single facility. Message numbers with bit <15> clear are systemwide status values.

facility number

Identifies the software component generating the condition value. Bit <27> is set for user facilities and clear for Compaq facilities.

Previous Next Contents Index