xref: /original-bsd/lib/libm/mc68881/README (revision e59fb703)
1These routines were produced by someone who is not a great authority on
2floating point, and may not be entirely correct.  Where possible I tested
3the special cases for routines.
4
5The directory testieee contains test programs for IEEE-format machines.
6I took a stab at making them work on the vax, but gave up as dealing with
7exceptions (e.g. underflow, overflow, reserved operand) was just too tedious.
8
9Note: it is possible to build a library with MACHINE=ieee but a couple
10of warnings:
11
12	Be careful when compiling floor.c.  These routines rely on
13	certain variables being only double precision.  If these
14	variables are placed in 68881 registers, they will be extended
15	precision and the routines will produce incorrect results.
16	Unless your compiler does its own register allocation, this
17	is not likely to be a problem as none of the variables in
18	question are declared "register".  If you are using GCC
19	you can specify -ffloat-store to avoid this problem.
20
21	The C version of drem() in ieee/support.c appears to compute
22	the incorrect results for drem(+-1, +-2).  It yields 1 when
23	it should be -1 and -1 when it should be 1.  "should be" is
24	based on what the VAX version yields and by cranking through
25	the formula.
26
27If you do build using MACHINE=ieee and run the tests in testieee you
28will note that some routines return errors:
29
30	floor/ceil/rint report that they got 0 when expecting -0.
31	Don't really know which is correct, is floor(-0) == 0 or -0?
32	For C it shouldn't really matter since 0 is the same as -0
33	in comparisons.
34
35	scalb(-1, -2100) returns 0 instead of -0.  2 ** -2100 is
36	effectively 0 but -anything * 0 == -0 according to the 68881.
37	Similarly for scalb(-pi, 2100).  It returns INF instead
38	of -INF.  2 ** 2100 is effectively INF but -anything * INF
39	is -INF.  What is correct?
40
41	drem(+-1, +-2) fails as mentioned above.  This is a real error.
42
43----
44Mike Hibler
45U of Utah CS Dept.
46mike@cs.utah.edu
47