Document revision date: 15 July 2002 | |
![]() |
![]() ![]() ![]() ![]() |
![]() |
Previous | Contents | Index |
Table 9-1 summarizes common conditions caused by exceptions. The condition names are listed in the first column. The second column explains each condition more fully by giving information about the type, meaning, and arguments relating to the condition. The condition type is either trap or fault. For more information about traps and faults, refer to the VAX Architecture Reference Manual and Alpha Architecture Reference Manual. The meaning of the exception condition is a short description of each condition. The arguments for the condition handler are listed where applicable; they give specific information about the condition.
Condition Name | Explanation | |
---|---|---|
SS$_ACCVIO | Type: | Fault. |
Description | Acess Violation. | |
Arguments: |
|
|
SS$_ARTRES 2 |
Type:
Description: Arguments: |
Trap.
Reserved arithmetic trap. None. |
SS$_ASTFLT | Type: | Trap. |
Description: | Stack invalid during attempt to deliver an AST. | |
Arguments: |
|
|
SS$_BREAK |
Type:
Description: Arguments: |
Fault.
Breakpoint instruction encountered. None. |
SS$_CMODSUPR |
Type:
Description: Arguments: |
Trap.
Change mode to supervisor instruction encountered. 4 Change mode code. The possible values are --32,768 through 32,767. |
SS$_CMODUSER |
Type:
Description: Arguments: |
Trap.
Change mode to user instruction encountered. 4 Change mode code. The possible values are --32,768 through 32,767. |
SS$_COMPAT 1 | Type: | Fault. |
Description: | Compatibility-mode exception. This exception condition can occur only when executing in compatibility mode. 5 | |
Arguments: |
Type of compatibility exception. The possible values are as follows:
0 = Reserved instruction execution 1 = BPT instruction executed 2 = IOT instruction executed 3 = EMT instruction executed 4 = TRAP instruction executed 5 = Illegal instruction executed 6 = Odd address fault 7 = TBIT trap. |
|
SS$_DECOVF 1 2 |
Type:
Description: Arguments: |
Trap.
Decimal overflow. None. |
SS$_FLTDIV 1 2 |
Type:
Description: Arguments: |
Trap.
Floating/decimal divide-by-zero. None. |
SS$_FLTDIV_F 1 |
Type:
Description: Arguments: |
Fault.
Floating divide-by-zero. None. |
SS$_FLTOVF 1 2 |
Type:
Description: Arguments: |
Trap.
Floating-point overflow. None. |
SS$_FLTOVF_F 1 |
Type:
Description: Arguments: |
Fault.
Floating-point overflow fault. None. |
SS$_FLTUND 1 2 |
Type:
Description: Arguments: |
Trap.
Floating-point underflow. None. |
SS$_FLTUND_F 1 |
Type:
Description: Arguments: |
Fault.
Floating-point underflow fault. None. |
SS$_INTDIV 1 2 |
Type:
Description: Arguments: |
Trap.
Integer divide-by-zero. None. |
SS$_INTOVF 1 2 |
Type:
Description: Arguments: |
Trap.
Integer overflow. None. |
SS$_OPCCUS 1 |
Type:
Description: Arguments: |
Fault.
Opcode reserved for customer fault. None. |
SS$_OPCDEC |
Type:
Description: Arguments: |
Fault.
Opcode reserved for Compaq fault. None. |
SS$_PAGRDERR | Type: | Fault. |
Description: | Read error occurred during an attempt to read a faulted page from disk. | |
Arguments: |
|
|
SS$_RADRMOD 1 |
Type:
Description: Arguments: |
Fault.
Attempt to use a reserved addressing mode. None. |
SS$_ROPRAND |
Type:
Description: Arguments: |
Fault.
Attempt to use a reserved operand. None. |
SS$_SSFAIL |
Type:
Description: Arguments: |
Fault.
System service failure (when system service failure exception mode is enabled). Conditon occured as result of the use of the obsolete feature that was enabled by using $SETSFM service. Status return from system service (R0). (The same value is in R0 of the mechanism array.) |
SS$_SUBRNG 1 2 |
Type:
Description: Arguments: |
Trap.
Subscript range trap. None. |
SS$_TBIT 1 |
Type:
Description: Arguments: |
Fault.
Trace bit is pending following an instruction. None.
|
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:
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.
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 |
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.
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:
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.
Previous | Next | Contents | Index |
![]() ![]() ![]() ![]() |
privacy and legal statement | ||
5841PRO_026.HTML |