Re: Number of significand bits in long double?

On Thu, 2005-Aug-04 12:30:30 -0700, Steve Kargl wrote:
>fpsetprec is deprecated.  In addition, one finds "... fpsetprec()
>functions provide functionality unavailable on many platforms.  At
>present, they are implemented only on the i386 and amd64 platforms".

So I see.  I didn't read the man page in detail, I just tracked down a
function that could change the precision.  fpsetprec() refers to
fenv(3) but that doesn't appear to (publicly) include provision for
changing precision.  On the i386 and amd64, you could fiddle with
the control word in fenv_t but that's not portable either.

AFAIK, only i386 (and presumably amd64) support the sort of default
rounding that fpsetprec() fiddles with.  Therefore it doesn't really
make sense to implement them elsewhere.

The underlying instruction is fldcw.  By default, FreeBSD initialises
the FPU using __INITIAL_NPXCW__ (defined in /sys/i386/include/npx.h).

Long double on various FreeBSD architectures is:
Alpha:	53 bits (no hardware long double)
ARM:    53 bits (not sure if ARM supports anything else)
amd64:	64 bits (can be restricted to 24 or 53 bits)
i386:	64 bits (can be restricted to 24 or 53 bits)
iA64:   64 bits
PPC:    53 bits (though I believe the h/w supports 106 or 112 bits)
SPARC:  113 bits

You are going to need to implement at least two different sets of
long double math routines (since the polynomial expansions will be
be different for 64 and 113 bits).  I don't see the problem with
adding machine-dependent fldcw/fstcw calls on the i386 code.

>> See the LDBL_* macros in <float.h> for native precision.
>
>That's the problem.  The LDBL* macros misrepresent the
>actual precision used.

I had a closer look.  In 4.x, LDBL_* just points to DBL_*.  imp_at_
changed it to reflect the native hardware precision in v1.9.

IMHO, it would be nice to run the i386 in native precision but that
opens up a can of worms (since expressions will wind up being
evaluated in different precisions depending on whether the compiler
needs to spill registers onto the stack and whether temporary
variables are registers or stack).

You probably need to have a chat to bde_at_

-- 
Peter Jeremy