Problem with changing an interrupt...

Thread View: alt.msdos.programmer

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by David Carlson Wed, 28 Oct 1992 22:27

#10

Author: David Carlson
Date: Wed, 28 Oct 1992 22:27

19 lines
1016 bytes

Hi all,

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?

		Any help is appreciated--please E-mail, as I don't read
this newsgroup regularly...

			Thanks,

				David
			(carlson@ucunix.san.uc.edu)

Re: Problem with changing an interrupt...

#12

Author: DAVID SCOTT PASCHAL
Date: Thu, 29 Oct 1992 00:32

27 lines
2081 bytes

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

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads