avoid easily avoidable loss of precision when |x| is nearly 1.
Extended (64-bit) precision only moves the meaning of "nearly" here.
This probably could be done better by splitting up the range into
|x| <= 0.5 and |x| > 0.5 like the C version. However, ucbtest
does't report any errors in this version. Perhaps the C version
should be used anyway. It's only 25% slower now on a P5, provided
the C version of sqrt() isn't used, and the C version could be
optimized better.
Errors checked by: ucbtest
at runtime.
etc/make.conf:
Nuked HAVE_FPU option.
lib/msun/Makefile:
Always build the i387 objects. Copy the i387 source files at build
time so that the i387 objects have different names. This is simpler
than renaming the files in the cvs repository or repeating half of
bsd.lib.mk to add explicit rules.
lib/msun/src/*.c:
Renamed all functions that have an i387-specific version by adding
`__generic_' to their names.
lib/msun/src/get_hw_float.c:
New file for getting machdep.hw_float from the kernel.
sys/i386/include/asmacros.h:
Abuse the ENTRY() macro to generate jump vectors and associated code.
This works much like PIC PLT dynamic initialization. The PIC case is
messy. The old i387 entry points are renamed. Renaming is easier
here because the names are given by macro expansions.
log10(x) = log10e * log(x). The formula would work if the RHS were
evaluated in extended precision with an extended precision log().
This actually happened with the i387 log() because it returns excess
precision.
Found by: ucbtest
This defeats the point of log1p(). ucbtest reports errors of +-5e+15
ULPs. A correct version would use the i387 fyl2xp1 instruction for
small x and maybe scale to small x. The C version does the scaling
reasonably efficiently, and fyl2px1 is slow (at least on P5s), so not
much is lost by always using the C version (only 25% for small x even
with the broken i387 version; 50% for large x).
doesn't need to be included in files that have nothing to do with
syscalls.
Added missing `.text' to START_ENTRY so that ENTRY() works when
invoked in the data section.
I notice info(1) has some problems moving back and forth through the
resulting info file, but emacs doesn't, so i figure it's rather a
problem with info(1) itself. To the least, this file installs now
finally.
