Date:	Fri, 17 Dec 1993 11:24:02 +1100
From:	Bill Metzenthen <BILLM AT vaxc DOT cc DOT monash DOT edu DOT au>
Subject:	Re: suggestion for NPX initialization
To:	djgpp AT sun DOT soe DOT clarkson DOT edu

Dieter ("buers AT dg1 DOT chemie DOT uni-konstanz DOT de") writes:

> In go32/npx.asm the invalid operation bit is cleared in the NPX
> control word. This means that 0.0/0.0 will give an exception. Since we
> don't have signal(), there is no easy way to trap this exception in
> the program.  I would suggest, to initialize the control word in
> npx.asm to 0x137f, which yields correct rounding and best precision
> and doesn't give any exceptions. You will get NaNs and Infs as

This sounds like the ieee defaults vs signal() argument to me. There
are advantages to either approach. I prefer to see something drastic
happen as the default, i.e. unless a program has been carefully
crafted to account for or eliminate all 0.0/0.0 etc then the
occurrence of such instructions should be regarded as fatal. I guess
that most programmers are not careful with floating point code (and
are even unaware of many of the issues) and are better helped by
having a program crash rather than (possibly) produce garbage.

For those programs which are carefully designed, it is easy enough to
add an instruction such as
          asm volatile ("fldcw 0x137f");
to the beginning of main(). This is not portable, but then again there
is no practical portable way of handling all possible error conditions
if ieee-style defaults are used.

> result instead.  Also -- an may be more important -- then the result
> of a calculation does not depend on the status of the NPX when the
> program is called.

I don't understand this statement. Provided that the FPU is properly
initialized (set the cw, clear the sw, etc) then the results never
depend upon the state of the FPU before the initialization.


--Bill

- Raw text -