Xref: utzoo comp.lang.c:38995 comp.sys.ibm.pc.hardware:8359
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!unisoft!hoptoad!wet!smiller
From: smiller@wet.UUCP (Gregory Shane Miller)
Newsgroups: comp.lang.c,comp.sys.ibm.pc.hardware
Subject: Borland C and _8087/matherr bugs? HELP
Keywords: Borland C FPU 8087
Message-ID: <2397@wet.UUCP>
Date: 3 May 91 04:31:01 GMT
Followup-To: comp.sys.ibm.pc.hardware
Organization: Wetware Diversions, San Francisco
Lines: 37


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 ]