smiller@wet.UUCP (Gregory Shane Miller) (05/03/91)
I have Borland C (version 2.01). I wanted to use the _8087 environment
var to check if a FPU was installed (_8087 is given in dos.h). In one
version of my FPU program, it always was set 0 (no FPU) and in another
version, always set !0 (FPU). What gives? Is this a bug? Mind you,
except that I assign a value myself, there's no way I could misprogram
its value. (BTW - I complied the .Cs with -f87 and linked to fp87 and
maths [ I was using small mode ]).
I looked in c0.asm (arced in the examples Borland provides) to see how
they arrived at its value. Am I crazy, or does it assign a value depending
on what's in the DOS environment space?! (c0.asm/c0x.obj provides the startup
code for any Borland EXE or COM).
I've decided to use the BIOS data info to get a correct and consistent
answer on this question (0040:0010 bit 2). Does anybody think this
wouldn't work on *all* systems?
On a related issue, what gives with the matherr function? On my system,
the FPU is so slow that if my AT is in turbo mode the CLK FREQ to the
'287 causes wierd overflow errors. To test that, I wrote a 2 line program:
double x,y;
main()
{
y = (double).32432432;
x = y/M_PI;
}
And when you run the program it terminates: Floating point error: overflow
*NOW* if I write my own matherr() function to catch any FP exceptions and
use the same code above - my matherr() is never called. OK - running the
poor chip too fast isn't too smart but why no consistency?
Ideas? Thanks.
--
G. Shane Miller [ smiller@wet.UUCP (415) 453-4926 ]srlncnc@dosli.govt.nz (Chris Crook) (05/07/91)
In article <2397@wet.UUCP> smiller@wet.UUCP (Gregory Shane Miller) writes: > >I looked in c0.asm (arced in the examples Borland provides) to see how >they arrived at its value. Am I crazy, or does it assign a value depending >on what's in the DOS environment space?! (c0.asm/c0x.obj provides the startup >code for any Borland EXE or COM). > No - you're not crazy. Borland provide the option of over-riding the system derived value by setting an enviroment variable. Thus you can effectively disable the FPU at run time by setting the 87 enviroment variable, i.e. SET 87=N This doesn't answer much of your question, but it may be a start. Chris Crook srlncnc@badger.dosli.govt.nz
alexande@borland.com (Mark Alexander) (05/08/91)
In article <2397@wet.UUCP> smiller@wet.UUCP (Gregory Shane Miller) writes: >On a related issue, what gives with the matherr function? On my system, >the FPU is so slow that if my AT is in turbo mode the CLK FREQ to the >'287 causes wierd overflow errors. To test that, I wrote a 2 line program: > >double x,y; >main() >{ > y = (double).32432432; > x = y/M_PI; >} > >And when you run the program it terminates: Floating point error: overflow >*NOW* if I write my own matherr() function to catch any FP exceptions and >use the same code above - my matherr() is never called. OK - running the >poor chip too fast isn't too smart but why no consistency? The error message was printed by the FPU exception (NMI) handler in the library, not by matherr(). Matherr() handles errors for the math library (negative numbers passed to log(), etc.). You can trap FPU exceptions by using signal(SIGFPE,...).