Xref: utzoo comp.os.msdos.programmer:2937 alt.msdos.programmer:2366
Path: utzoo!utgpu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!sdd.hp.com!ucsd!ucbvax!pasteur!eucalyptus.Berkeley.EDU!karlson
From: karlson@eucalyptus.Berkeley.EDU (Eric Karlson)
Newsgroups: comp.os.msdos.programmer,alt.msdos.programmer
Subject: Re: Trapping Floating Point Errors in Turbo C
Message-ID: <10423@pasteur.Berkeley.EDU>
Date: 24 Jan 91 21:56:00 GMT
References: <21650@netcom.UUCP>
Sender: news@pasteur.Berkeley.EDU
Reply-To: karlson@eucalyptus.Berkeley.EDU (Eric Karlson)
Organization: University of California at Berkeley
Lines: 16

I am not completely sure of this, but some time back when I was searching
for just this sort of info, I seem to recall finding a reference that
implied that the 8087 interrupt came in on INT 2 (the same as the memory
parity error, I believe). Again, take this with a grain of salt, it was some
time ago and I never did find an explicit statement on this matter.

My primary comment is about the CS:IP at the time of interrupt.  Even if
you do find a way of getting that, it won't give you what you want.  The
reason is that the 8087 runs in parrallel to the 80X86, so when the 8087
signals an interrupt, the main processor could be doing something entirely
unrelated to what caused the 8087 to get an error (if your math routines
are written so that they will never return until the 8087 has finished the
work for that procedure, then this is a lie, but said routine do not HAVE
to be written this way).

							Eric Karlson