Document revision date: 30 March 2001 | |
![]() |
![]() ![]() ![]() ![]() |
![]() |
Previous | Contents | Index |
Exceptions can be grouped into the following six classes:
This section contains the descriptions of the exceptions that occur as the result of performing an arithmetic or conversion operation. They are mutually exclusive and are all assigned the same vector in the system control block (SCB) and the same signal "reason" code. Each exception indicates that an instruction has been completed (trap) or backed up (fault). An appropriate distinguishing exception type code is pushed onto the stack as a longword. Table E-1 lists the arithmetic exception type codes.
Exception Type | Mnemonic | Decimal Value |
Hexadecimal Value |
---|---|---|---|
Traps | |||
integer overflow | SS$_INTOVF | 1 | 1 |
integer divide-by-zero | SS$_INTDIV | 2 | 2 |
floating overflow | SS$_FLTOVF | 3 | 3 |
floating or decimal
divide-by-zero |
SS$_FLTDIV | 4 | 4 |
floating underflow | SS$_FLTUND | 5 | 5 |
decimal overflow | SS$_DECOVF | 6 | 6 |
subscript range | SS$_SUBRNG | 7 | 7 |
Faults | |||
floating underflow | SS$_FLTOVF_F | 8 | 8 |
floating divide-by-zero | SS$_FLTDIV_F | 9 | 9 |
floating underflow | SS$_FLTUND_F | 10 | A |
An integer overflow trap is an exception indicating that the last
instruction executed had an integer overflow, which set the processor
status longword (PSL) V bit, and that the integer overflow was enabled
(the IV bit in the PSL was set). The stored result is the low-order
part of the correct result. The N and Z bits in the PSL are set
according to the stored result. The type code pushed onto the stack is
1 (SS$_INTOVF).
E.1.2 Integer Divide-by-Zero Trap
An integer divide-by-zero trap is an exception indicating that the last
instruction executed had an integer zero divisor. The stored result is
equal to the dividend, and condition code V bit in the PSL is set. The
type code pushed onto the stack is 2 (SS$_INTDIV).
E.1.3 Floating Overflow Trap
A floating overflow trap is an exception indicating that the last
instruction executed resulted in an exponent greater than the largest
representable exponent for the data type after normalization and
rounding. The stored result contains a one in the sign field and zeros
in the exponent and fraction fields. This is a reserved operand. It
causes a reserved operand fault if used in a subsequent floating-point
instruction. The N and V condition code bits in the PSL are set, and
the Z and C bits in the PSL are cleared. The type code pushed onto the
stack is 3 (SS$_FLTOVF).
E.1.4 Divide-by-Zero Trap
A floating divide-by-zero trap is an exception indicating that the last instruction executed had a floating zero divisor. The stored result is the reserved operand described previously for the floating overflow trap. The condition codes are set as they are for the floating overflow trap.
A decimal string divide-by-zero trap is an exception indicating that the last instruction executed had a decimal-string zero divisor. The destination, R0 to R5, and condition codes are UNPREDICTABLE. The zero divisor can be either +0 or -0.
The type code pushed onto the stack for both types of divide-by-zero is
4 (SS$_FLTDIV).
E.1.5 Floating Underflow Trap
A floating underflow trap is an exception indicating that the last
instruction executed resulted in an exponent less than the smallest
representable exponent for the data type after normalization and
rounding, and that floating underflow was enabled (FU set). The stored
result is zero. The N, V, and C condition codes bits in the PSL are
cleared, and the Z bit in the PSL is set, except for the polynomial
evaluation instruction POLYx. In POLYx, the trap occurs on completion
of the instruction, which may be many operations after the underflow.
The condition codes are set on the final result in POLYx. The type code
pushed onto the stack is 5 (SS$_FLTUND).
E.1.6 Decimal String Overflow Trap
A decimal string overflow trap is an exception indicating that the last
instruction executed had a decimal-string result too large for the
destination string provided, and that decimal overflow was enabled (the
DV bit in the PSL was set). The V condition code bit in the PSL is
always set. The type code pushed onto the stack is 6 (SS$_DECOVF).
E.1.7 Subscript-Range Trap
A subscript range trap is an exception indicating that the last
instruction was an INDEX instruction with a subscript operand that
failed the range check. The value of the subscript operand is lower
than the low operand or greater than the high operand. The result is
stored in indexout, and the condition codes are set as if the subscript
were within range. The type code pushed onto the stack is 7
(SS$_SUBRNG).
E.1.8 Floating Overflow Fault
A floating overflow fault is an exception indicating that the last
instruction executed resulted in an exponent greater than the largest
representable exponent for the data type after normalization and
rounding. The destination was unaffected, and the saved condition codes
are UNPREDICTABLE. The saved program counter (PC) points to the
instruction causing the fault. The POLYx instruction is suspended with
the first-part-done bit (FPD) set. The type code pushed onto the stack
is 8 (SS$_FLTOVF_F).
E.1.9 Divide-by-Zero Floating Fault
A floating divide-by-zero fault is an exception indicating that the
last instruction executed had a floating zero divisor. The quotient
operand was unaffected and the saved condition codes are UNPREDICTABLE.
The saved PC points to the instruction causing the fault. The type code
pushed onto the stack is 9 (SS$_FLTDIV_F).
E.1.10 Floating Underflow Fault
A floating underflow fault is an exception indicating that the last
instruction executed resulted in an exponent less than the smallest
representable exponent for the data type after normalization and
rounding, and that floating underflow was enabled (the FU bit was set).
The destination operand is unaffected. The saved condition codes are
UNPREDICTABLE. The saved PC points to the instruction causing the
fault. The POLYx instruction is suspended with FPD set. The type code
pushed onto the stack is 10 (SS$_FLTUND_F).
E.2 Memory Management Exceptions
A memory management exception can be either an access control violation
fault or a translation not valid fault.
E.2.1 Access Control Violation Fault
An access control violation fault is an exception indicating that the
process attempted a reference not allowed at the current access mode.
E.2.2 Translation Not Valid Fault
A translation not valid fault is an exception indicating that the process attempted a reference to a page for which the valid bit in the page table had not been set.
Note that if a process attempts to reference a page for which the page
table entry specifies both translation not valid fault and access
control violation, an access control violation fault occurs.
E.3 Exceptions Detected During Operand Reference
Two exceptions are possible during operand reference: the reserved
addressing mode fault and the reserved operand exception.
E.3.1 Reserved Addressing Mode Fault
A reserved addressing mode fault is an exception indicating that an
operand specifier attempted to use an addressing mode that is
disallowed. No parameters are pushed.
E.3.2 Reserved Operand Exception
A reserved operand exception is an exception indicating that an accessed operand has a format reserved for future use by Compaq. No parameters are pushed onto the stack. This exception always backs up the saved PC to point to the opcode. The exception service routine may determine the type of operand by examining the opcode using the saved PC.
Note that only the changes made by instruction fetch and the changes made because of operand specifier evaluation may be restored. Therefore, some instructions are not restartable. These exceptions are labeled as aborts rather than as faults. The saved PC is always restored properly unless the instruction attempted to modify it in a manner that results in UNPREDICTABLE results.
The reserved operand exceptions are caused by the following:
The following exceptions may occur as a consequence of instruction execution:
Each is described in the following subsections.
E.4.1 Reserved or Privileged Instruction Fault
A reserved or privileged instruction fault occurs when the processor
encounters an opcode that is not specifically defined or requires
higher privileges than the current mode. No parameters are pushed onto
the stack. Opcode FFFF (hex) will always fault.
E.4.2 Operand Reserved to Customers Fault
An opcode reserved to customers fault is an exception that occurs when an opcode reserved to customers is executed. The operation is identical to the reserved or privileged instruction fault, except that the event is caused by a different set of opcodes and faults through a different vector. All opcodes reserved to customers start with FC (hex), which is the XFC instruction. If the special instruction must generate a unique exception, one of the reserved-to-customer vectors should be used. An example might be an unrecognized second byte of the instruction.
The XFC fault is intended primarily for use with writable control store
to implement installation-dependent instructions. The method used to
enable and disable the handling of an XFC fault in user-written
microcode is implementation dependent. Some implementations may
transfer control to microcode without checking bits <1:0> of the
exception vector.
E.4.3 Instruction Emulation Exceptions
When a subset processor executes a string instruction that is omitted
from its instruction set, an emulation exception results. An emulation
exception can occur through either of two system control block (SCB)
vectors, depending on whether or not the first-part-done (FPD) bit in
the program status longword was set at the beginning of the
instruction. If the FPD bit is clear, a subset emulation trap occurs
through the SCB vector at offset CB (hex), and a subset emulation trap
frame is pushed onto the current stack. If the FPD bit is set, a
suspended emulation fault occurs through the SCB vector at offset CC
(hex), and the PC and the PSL are pushed onto the current stack.
E.4.4 Compatibility Mode Exception
A compatibility mode exception is an exception that occurs when the processor is in compatibility mode. A longword of information containing a code that indicates the exception type is pushed onto the stack. Figure E-1 shows the stack frame, which is the same as that for arithmetic exceptions.
Figure E-1 Compatibility Mode Exception Stack Frame
The compatibility type codes are shown in Table E-2.
Exception Type | Decimal Value |
---|---|
Faults | |
reserved opcode | 0 |
BPT instruction | 1 |
IOT instruction | 2 |
EMT instruction | 3 |
TRAP instruction | 4 |
illegal instruction | 5 |
Aborts | |
odd address | 6 |
All other exceptions in compatibility mode, including the access
control violation fault, the translation not valid fault, and the
machine check abort, occur by means of the regular native-mode vector.
E.4.5 Change Mode Trap
A change mode trap is an exception occurring when one of the change
mode instructions (CHMK, CHME, CHMS, or CHMU) is executed. The
instruction operand is pushed onto the exception stack.
E.4.6 Breakpoint Fault
A breakpoint fault is an exception that occurs when the breakpoint instruction (BPT) is executed. The BPT instruction pushes the current PSL onto the stack.
To proceed from a breakpoint fault, a debugger or tracing program does the following:
When the instruction that has a breakpoint completes execution, a trace exception occurs. At this point, the tracing program takes control and does the following:
Note that if both tracing and breakpointing are in progress (if the PSL
T bit was set at the time of the BPT), both the BPT restoration and a
normal trace exception should be processed on the trace exception by
the trace handler.
E.5 Trace Fault
Program tracing is used for many purposes. Debugging programs and evaluating program performance are the most common uses of program tracing.
A trace fault is an exception that occurs between instructions when trace is enabled. One trace fault occurs before the execution of each traced instruction. The address in the PC saved when a trace fault occurs is the address of the instruction after the trace fault that would normally be executed. The trace exception for an instruction takes precedence over all other exceptions. The detection of reserved instruction faults occurs after the trace fault. If a trace fault and a memory management fault (or an odd address abort during a compatibility mode instruction fetch) occur simultaneously, exceptions are taken in UNPREDICTABLE order.
To ensure that exactly one trace occurs per instruction despite other traps and faults, the PSL contains the trace enable (T) and trace pending (TP) bits.
The PSL TP bit generates a fault before any other processing at the start of the next instruction.
The following are rules of operation for trace:
The routine entered by a change mode (CHMx) instruction is not traced
because change mode clears T and TP in the new PSL that is used for
whichever new mode is entered. However, if the T bit was set in the old
PSW (the one to be saved) at the beginning of the change mode
instruction, the system sets both the T and the TP bit in the saved
PSL. Trace faults resume with the instruction that follows other
returns from interrupt (REI) in the routine entered by the CHMx
instruction. An instruction following an REI faults if T was set when
the REI was executed, or if the TP bit in the saved PSL is set. In both
cases, TP is set after the REI.
E.5.2 Trace Operation Upon Return From Interrupt
Note that a trace fault that occurs for an instruction following an REI
instruction that had set the TP will be taken with the new PSL restored
by the REI instruction. Thus, special care must be taken if exception
or interrupt routines are traced.
E.5.3 Trace Operation After a BISPSW Instruction
If the T bit is set by a BISPSW instruction, trace faults begin with
the second instruction after the BISPSW.
E.5.4 Trace Operation After a CALLS or CALLG Instruction
The CALLS and CALLG instructions save a clear T bit, although the T bit in the PSL is unchanged. This is done so that a debugger or trace program proceeding from a BPT fault does not get a spurious trace from the RET that matches the CALL.
Previous | Next | Contents | Index |
![]() ![]() ![]() ![]() |
privacy and legal statement | ||
4515PRO_040.HTML |