Chapter Seventeen (Part 1)
|Table of Content||
Chapter Seventeen (Part 3)
INTERRUPTS, TRAPS AND EXEPTIONS (Part 2)
17.3.1 - Divide Error Exception (INT 0)
17.3.2 - Single Step (Trace) Exception (INT 1)
17.3.3 - Breakpoint Exception (INT 3)
Overflow Exception (INT 4/INTO)
17.3.5 - Bounds Exception (INT 5/BOUND)
17.3.6 - Invalid Opcode Exception (INT 6)
17.3.7 - Coprocessor Not Available (INT 7)
Exceptions occur (are raised) when an abnormal condition occurs during execution. There are fewer than eight possible exceptions on machines running in real mode. Protected mode execution provides many others, but we will not consider those here, we will only consider those exceptions interesting to those working in real mode.
Although exception handlers are user defined, the 80x86 hardware defines the exceptions that can occur. The 80x86 also assigns a fixed interrupt number to each of the exceptions. The following sections describe each of these exceptions in detail.
In general, an exception handler should preserve all
registers. However, there are several special cases where you may want to tweak a register
value before returning. For example, if you get a bounds violation, you may want to modify
the value in the register specified by the
bound instruction before
returning. Nevertheless, you should not arbitrarily modify registers in an exception
handling routine unless you intend to immediately abort the execution of your program.
17.3.1 Divide Error Exception (INT 0)
This exception occurs whenever you attempt to divide a
value by zero or the quotient does not fit in the destination register when using the
idiv instructions. Note that the FPU's fdiv and fdivr instructions do not
raise this exception.
MS-DOS provides a generic divide exception handler that prints a message like "divide error" and returns control to MS-DOS. If you want to handle division errors yourself, you must write your own exception handler and patch the address of this routine into location 0:0.
On 8086, 8088, 80186, and 80188 processors, the return
address on the stack points at the next instruction after the divide instruction. On the
80286 and later processors, the return address points at the beginning of the divide
instruction (include any prefix bytes that appear). When a divide exception occurs, the
80x86 registers are unmodified; that is, they contain the values they held when the 80x86
first executed the
When a divide exception occurs, there are three reasonable things you can attempt: abort the program (the easy way out), jump to a section of code that attempts to continue program execution in view of the error (e.g., as the user to reenter a value), or attempt to figure out why the error occurred, correct it, and reexecute the division instruction. Few people choose this last alternative because it is so difficult.
17.3.2 Single Step (Trace) Exception (INT 1)
The single step exception occurs after every instruction if the trace bit in the flags register is equal to one. Debuggers and other programs will often set this flag so they can trace the execution of a program.
When this exception occurs, the return address on the stack is the address of the next instruction to execute. The trap handler can decode this opcode and decide how to proceed. Most debuggers use the trace exception to check for watchpoints and other events that change dynamically during program execution. Debuggers that use the trace exception for single stepping often disassemble the next instruction using the return address on the stack as a pointer to that instruction's opcode bytes.
Generally, a single step exception handler should preserve all 80x86 registers and other state information. However, you will see an interesting use of the trace exception later in this text where we will purposely modify register values to make one instruction behave like another.
Interrupt one is also shared by the debugging exceptions capabilities of 80386 and later processors. These processors provide on-chip support via debugging registers. If some condition occurs that matches a value in one of the debugging registers, the 80386 and later CPUs will generate a debugging exception that uses interrupt vector one.
17.3.3 Breakpoint Exception (INT 3)
The breakpoint exception is actually a trap, not an
exception. It occurs when the CPU executes an
int 3 instruction. However, we
will consider it an exception since programmers rarely put
int 3 instructions
directly into their programs. Instead, a debugger like Codeview often manages the
placement and removal of
int 3 instructions.
When the 80x86 calls a breakpoint exception handling
routine, the return address on the stack is the address of the next instruction after the
breakpoint opcode. Note, however, that there are actually two
instructions that transfer control through this vector. Generally, though, it is the
int 3 instruction whose opcode is 0cch; otherwise it is the two byte
equivalent: 0cdh, 03h.
17.3.4 Overflow Exception (INT 4/INTO)
The overflow exception, like
int 3, is
technically a trap. The CPU only raises this exception when you execute an
instruction and the overflow flag is set. If the overflow flag is clear, the
instruction is effectively a
nop, if the overflow flag is set,
int 4 instruction
. Programmers can insert an
instruction after an integer computation to check for an arithmetic overflow. Using
is equivalent to the following code sequence:
<< Some integer arithmetic code »
One big advantage to the
into instruction is
that it does not flush the pipeline or prefetch queue if the overflow flag is not set.
Therefore, using the
into instruction is a good technique if you provide a
single overflow handler (that is, you don't have some special code for each sequence where
an overflow could occur).
The return address on the stack is the address of the next
into. Generally, an overflow handler does not return to
that address. Instead, it will usually abort the program or pop the return address and
flags off the stack and attempt the computation in a different way.
17.3.5 Bounds Exception (INT 5/BOUND)
will cause a conditional exception. If the specified register is outside the specified
bound instruction is equivalent to an
instruction; if the register is within the specified bounds, the
instruction is effectively a nop.
The return address that
bound pushes is the
address of the
bound instruction itself, not the instruction following
If you return from the exception without modifying the value in the register (or adjusting
the bounds), you will generate an infinite loop because the code will reexecute the
instruction and repeat this process over and over again.
One sneaky trick with the
bound instruction is
to generate a global minimum and maximum for an array of signed integers. The following
code demonstrates how you can do this:
; This program demonstrates how to compute the minimum and maximum values ; for an array of signed integers using the bound instruction .xlist .286 include stdlib.a includelib stdlib.lib .list dseg segment para public 'data' ; The following two values contain the bounds for the BOUND instruction. LowerBound word ? UpperBound word ? ; Save the INT 5 address here: OldInt5 dword ? ; Here is the array we want to compute the minimum and maximum for: Array word 1, 2, -5, 345, -26, 23, 200, 35, -100, 20, 45 word 62, -30, -1, 21, 85, 400, -265, 3, 74, 24, -2 word 1024, -7, 1000, 100, -1000, 29, 78, -87, 60 ArraySize = ($-Array)/2 dseg ends cseg segment para public 'code' assume cs:cseg, ds:dseg ; Our interrupt 5 ISR. It compares the value in AX with the upper and ; lower bounds and stores AX in one of them (we know AX is out of range ; by virtue of the fact that we are in this ISR). ; ; Note: in this particular case, we know that DS points at dseg, so this ; ISR will get cheap and not bother reloading it. ; ; Warning: This code does not handle the conflict between bound/int5 and ; the print screen key. Pressing prtsc while executing this code may ; produce incorrect results (see the text). BoundISR proc near cmp ax, LowerBound jl NewLower ; Must be an upper bound violation. mov UpperBound, ax iret NewLower: mov LowerBound, ax iret BoundISR endp Main proc mov ax, dseg mov ds, ax meminit ; Begin by patching in the address of our ISR into int 5's vector. mov ax, 0 mov es, ax mov ax, es:[5*4] mov word ptr OldInt5, ax mov ax, es:[5*4 + 2] mov word ptr OldInt5+2, ax mov word ptr es:[5*4], offset BoundISR mov es:[5*4 + 2], cs ; Okay, process the array elements. Begin by initializing the upper ; and lower bounds values with the first element of the array. mov ax, Array mov LowerBound, ax mov UpperBound, ax ; Now process each element of the array: mov bx, 2 ;Start with second element. mov cx, ArraySize GetMinMax: mov ax, Array[bx] bound ax, LowerBound add bx, 2 ;Move on to next element. loop GetMinMax ;Repeat for each element. printf byte "The minimum value is %d\n" byte "The maximum value is %d\n",0 dword LowerBound, UpperBound ; Okay, restore the interrupt vector: mov ax, 0 mov es, ax mov ax, word ptr OldInt5 mov es:[5*4], ax mov ax, word ptr OldInt5+2 mov es:[5*4+2], ax Quit: ExitPgm ;DOS macro to quit program. Main endp cseg ends sseg segment para stack 'stack' stk db 1024 dup ("stack ") sseg ends zzzzzzseg segment para public 'zzzzzz' LastBytes db 16 dup (?) zzzzzzseg ends end Main
If the array is large and the values appearing in the array
are relatively random, this code demonstrates a fast way to determine the minimum and
maximum values in the array. The alternative, comparing each element against the upper and
lower bounds and storing the value if outside the range, is generally a slower approach.
True, if the
bound instruction causes a trap, this is much slower than the
compare and store method. However, it a large array with random values, the bounds
violation will rarely occur. Most of the time the
bound instruction will
execute in 7-13 clock cycles and it will not flush the pipeline or the prefetch queue.
Warning: IBM, in their infinite wisdom, decided to use
5 as the print screen operation. The default
int 5 handler will dump
the current contents of the screen to the printer. This has two implications for those who
would like to use the
bound instruction in their programs. First, if you do
not install your own
int 5 handler and you execute a
instruction that generates a bound exception, you will cause the machine to print the
contents of the screen. Second, if you press the PrtSc key with your
int 5 handler
installed, BIOS will invoke your handler. The former case is a programming error, but this
latter case means you have to make your bounds exception handler a little smarter. It
should look at the byte pointed at by the return address. If this is an
instruction opcode (0cdh), then you need to call the original
int 5 handler,
or simply return from interrupt (do you want them pressing the PrtSc key at that point?).
If it is not an
int 5 opcode, then this exception was probably raised by the
instruction. Note that when executing a
bound instruction the return address
may not be pointing directly at a
bound opcode (0c2h). It may be pointing at
a prefix byte to the
bound instruction (e.g., segment, addressing mode, or
size override). Therefore, it is best to check for the
int 5 opcode.
17.3.6 Invalid Opcode Exception (INT 6)
The 80286 and later processors raise this exception if you attempt to execute an opcode that does not correspond to a legal 80x86 instruction. These processors also raise this exception if you attempt to execute a bound, lds, les, lidt, or other instruction that requires a memory operand but you specify a register operand in the mod/rm field of the mod/reg/rm byte.
The return address on the stack points at the illegal
opcode. By examining this opcode, you can extend the instruction set of the 80x86. For
example, you could run 80486 code on an 80386 processor by providing subroutines that
mimic the extra 80486 instructions (like
17.3.7 Coprocessor Not Available (INT 7)
The 80286 and later processors raise this exception if you attempt to execute an FPU (or other coprocessor) instruction without having the coprocessor installed. You can use this exception to simulate the coprocessor in software.
On entry to the exception handler, the return address points at the coprocessor opcode that generated the exception.
 For more details on exceptions in protected mode, see the bibliography.
 Note that on the 80486 and later processors, the bound instruction may actually be slower than the corresponding straight line code.
Chapter Seventeen: Interrupts, Traps
and Exeptions (Part 2)
29 SEP 1996