Xref: utzoo comp.os.msdos.programmer:3296 alt.msdos.programmer:2396
Path: utzoo!utgpu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!uwm.edu!ogicse!pdxgate!eecs!mwizard
From: mwizard@eecs.cs.pdx.edu (Craig Nelson)
Newsgroups: comp.os.msdos.programmer,alt.msdos.programmer
Subject: Re: Trapping Floating Point Errors in Turbo C
Message-ID: <1566@pdxgate.UUCP>
Date: 12 Feb 91 02:50:54 GMT
References: <21650@netcom.UUCP>
Sender: news@pdxgate.UUCP
Lines: 45

resnicks@netcom.UUCP (Steve Resnick) writes:


>I have a problem - I need to trap floating point errors from the floating
>point hardware. Currently, I am using signal() to do this, but signal doesn't
>give me some of the information I need. I assume that the 80n87 and the
>emulator (EMU.LIB) both generate an interrupt in the event of a floating
>point exception. My question is, what interrupt is generated, and if the
>ISR for that interrupt is shared, what do I need to check on the PIC to
>determine the source of the interupt?  One of the things I want, which
>I can't get out of signal, is the CS:IP at the time of the exception, 
>so that I can point the finger at a specific routine.
> 
>Thanx, in advance,

>Steve


	If you check the interrupt table (we all have one lieing around) you
 will see a floating point error generates an interrupt 75h.  Dealing with
 this problem strictly from Turbo C might present problems unless you have the
 new IDE that came with Turbo C++.  If you have the new or old Turbo Debugger
 then you should have Turbo Assembler as well and the answer is simple. With
 what you are asking for you should solve the problem by writing a new ISR
 and storing its location in the vector table at the proper position.  In case
 you're wondering, on an 80x86 based machine its 0000:01D4h.  Write a small
 routine (using assembly language is advised) and make sure the stack is not
 modified during execution. This routine is going to be used simpley as a place
 to stash a breakpoint during debugging.  You can use the interrupt function
 type if you really want to, but I like making things as hard as possible.
	After installing the interrupt function in the vector location (please
 remember to save where the old one is in some global variables) You should
 be able to set a breakpoint in the new interrupt handler and run the program.
 To install the new handler refer to the Turbo C reference guide for the
 syntax and semantics on the getvect() and setvect() routines.  
	After all that work the last of your questions (what routine is causing
 this to happen) should be on the stack (hopefully by this time you are well
 familiar with Turbo Debugger).  The order of items on the stack when you enter
 the ISR will be as follows: flags at time of interrupt, then cs:ip.
	One more chunk of advice.  If you are using the EMU.LIB for all this
 then checking cs:ip won't do you any good.  It will contain the emulation
 code for whatever Borland created in their little black room to emulate a
 coprocessor.

		Craig  (mwizard@eecs.ee.pdx.edu)