🚀 go-pugleaf

In article <Bwurq1.4M3@ucunix.san.uc.edu>, carlson@ucunix.san.uc.edu (David Carlson) writes:
|>I've encountered the following problem:
|>
|>	After changing the address of the divide by zero interrupt in
|>the interrupt vector table to an address containing my replacement code,
|>I attempted to test it by dividing by zero.  This results in an infinite
|>loop of my replacement code.  However, if I directly  interrupt
|>with an assembler INT 00H instruction,  it works fine.
|>	Does anyone know why this is?  What makes INT 00H different from
|>a real divide by zero?

Hi.  On the 286 and 386 with all those "additional" interrupts defined to
support protected mode, some processor exceptions (internally-generated
interrupts) are classed as faults (instruction is restartable because the
processor pushes the address of the offending instruction as the return address
from the interrupt), traps (instruction is not restartable because the return
address points to the instruction after that which caused the interrupt), and
aborts (these are severe errors).  Interrupts invoked with the INT instruction
are always classified as traps.
Divide-by-zero is classified as a fault, so if your divide-by-zero handler is
not aborting the program or specifically jumping to a certain point in the
program, you're returning back to the divide instruction, which then causes
another divide-by-zero error ad nauseum.

Tschuess,
David Paschal