Aren/NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Import of .txt files from TestFloat-2A, after ripping the \r's out, sigh.

Browse Source
This commit is contained in:
ross 2001-03-13 06:23:17 +00:00
parent 122b058a16
commit 3fc4c3244f
5 changed files with 1645 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
regress/lib/libc/ieeefp/testfloat/notes/README.txt Normal file
View File

@ -0,0 +1,50 @@
Package Overview for TestFloat Release 2a
John R. Hauser
1998 December 16
TestFloat is a program for testing that a floating-point implementation
conforms to the IEC/IEEE Standard for Binary Floating-Point Arithmetic.
TestFloat is distributed in the form of C source code. The TestFloat
package actually provides two related programs:
-- The `testfloat' program tests a system's floating-point for conformance
to the IEC/IEEE Standard. This program uses the SoftFloat software
floating-point implementation as a basis for comparison.
-- The `testsoftfloat' program tests SoftFloat itself for conformance to
the IEC/IEEE Standard. These tests are performed by comparing against a
separate, slower software floating-point that is included in the TestFloat
package.
TestFloat depends on SoftFloat, but SoftFloat is not included in the
TestFloat package. SoftFloat can be obtained through the Web page `http://
HTTP.CS.Berkeley.EDU/~jhauser/arithmetic/SoftFloat.html'.
TestFloat is documented in three text files:
testfloat.txt Documentation for using the TestFloat programs
(both `testfloat' and `testsoftfloat').
testfloat-source.txt Documentation for porting and compiling TestFloat.
testfloat-history.txt History of major changes to TestFloat.
The following file is also provided:
systemBugs.txt Information about processor bugs found using
TestFloat.
Other files in the package comprise the source code for TestFloat.
Please be aware that some work is involved in porting this software to other
targets. It is not just a matter of getting `make' to complete without
error messages. I would have written the code that way if I could, but
there are fundamental differences between systems that I can't make go away.
You should not attempt to compile the TestFloat sources without first
reading `testfloat-source.txt'.
At the time of this writing, the most up-to-date information about
TestFloat and the latest release can be found at the Web page `http://
HTTP.CS.Berkeley.EDU/~jhauser/arithmetic/TestFloat.html'.

323
regress/lib/libc/ieeefp/testfloat/notes/systemBugs.txt Normal file
View File

@ -0,0 +1,323 @@
Known Floating-point Bugs Detected by TestFloat
John R. Hauser
1997 December 15
-------------------------------------------------------------------------------
Introduction
Several popular systems have bugs that TestFloat is very likely to run
across. The ones I know of are documented here. First off, TestFloat finds
no errors in the following processors/machines:
AMD 486 DX4's
Sun UltraSPARC 1's and 2's
On the other hand, bugs are found in these processors/machines:
Older Intel Pentiums (with the divide bug)
Intel Pentium Pros
Sun SPARCstation 1's and IPX's
Sun SPARCstation 10's
HP Precision Architecture processors, with HP-UX prior to version 10.10
For some reason, most of the bugs found involve conversions from floating-
point to integer formats.
The bugs are shown as actual TestFloat error lines, along with a brief
explanation. The error lines given are not necesarily exhaustive and were
not necessarily output in the order shown.
This document does not pretend to be an authoritative bug listing for all
commercial processors. The vast majority of processors are absent from this
list because I have never run TestFloat on such machines and I thus have no
knowledge of what bugs TestFloat might find in them.
The latest version of this file can be found at the Web page `http://
http.cs.berkeley.edu/~jhauser/arithmetic/testfloat.html'.
-------------------------------------------------------------------------------
Older Intel Pentiums (with the divide bug)
The following conversion problems are found on Pentiums that also suffer
from the infamous floating-point divide bug. These bugs have been fixed on
newer Pentiums. (TestFloat does not find the divide bug.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
floatx80_to_int32
-- A few small fractions are treated as though they were zero.
Errors found in floatx80_to_int32, rounding nearest_even:
3FFB.8000000000000000 soft: 00000000 ....x syst: 00000000 .....
3FFC.8000000000000000 soft: 00000000 ....x syst: 00000000 .....
3FFC.C000000000000000 soft: 00000000 ....x syst: 00000000 .....
BFFB.8000000000000000 soft: 00000000 ....x syst: 00000000 .....
BFFC.8000000000000000 soft: 00000000 ....x syst: 00000000 .....
Errors found in floatx80_to_int32, rounding to_zero:
3FFB.8000000000000000 soft: 00000000 ....x syst: 00000000 .....
3FFC.8000000000000000 soft: 00000000 ....x syst: 00000000 .....
3FFC.C000000000000000 soft: 00000000 ....x syst: 00000000 .....
BFFB.8000000000000000 soft: 00000000 ....x syst: 00000000 .....
BFFC.8000000000000000 soft: 00000000 ....x syst: 00000000 .....
BFFC.C000000000000000 soft: 00000000 ....x syst: 00000000 .....
Errors found in floatx80_to_int32, rounding down:
3FFB.8000000000000000 soft: 00000000 ....x syst: 00000000 .....
3FFC.8000000000000000 soft: 00000000 ....x syst: 00000000 .....
3FFC.C000000000000000 soft: 00000000 ....x syst: 00000000 .....
BFFB.8000000000000000 soft: FFFFFFFF ....x syst: 00000000 .....
BFFC.8000000000000000 soft: FFFFFFFF ....x syst: 00000000 .....
BFFC.C000000000000000 soft: FFFFFFFF ....x syst: 00000000 .....
Errors found in floatx80_to_int32, rounding up:
3FFB.8000000000000000 soft: 00000001 ....x syst: 00000000 .....
3FFC.8000000000000000 soft: 00000001 ....x syst: 00000000 .....
3FFC.C000000000000000 soft: 00000001 ....x syst: 00000000 .....
BFFB.8000000000000000 soft: 00000000 ....x syst: 00000000 .....
BFFC.8000000000000000 soft: 00000000 ....x syst: 00000000 .....
3FFB.8000000000000000 is the fraction 1/16; 3FFC.8000000000000000 is 1/8;
and 3FFC.C000000000000000 is 3/16. Both positive and negative inputs are
affected.
-- Some (all?) positive floating-point values between 2^32 - 1/2
(401E.FFFFFFFF00000000) and 2^32 (401F.0000000000000000) are rounded to
zero when the rounding mode is nearest/even or up.
Errors found in floatx80_to_int32, rounding nearest_even:
401E.FFFFFFFF80000000 soft: 7FFFFFFF v.... syst: 00000000 ....x
401E.FFFFFFFFC00001FE soft: 7FFFFFFF v.... syst: 00000000 ....x
401E.FFFFFFFFF8000000 soft: 7FFFFFFF v.... syst: 00000000 ....x
401E.FFFFFFFFFEC00000 soft: 7FFFFFFF v.... syst: 00000000 ....x
401E.FFFFFFFFFF002000 soft: 7FFFFFFF v.... syst: 00000000 ....x
401E.FFFFFFFFFFC00000 soft: 7FFFFFFF v.... syst: 00000000 ....x
401E.FFFFFFFFFFE00000 soft: 7FFFFFFF v.... syst: 00000000 ....x
401E.FFFFFFFFFFFD7FFE soft: 7FFFFFFF v.... syst: 00000000 ....x
401E.FFFFFFFFFFFFFFFE soft: 7FFFFFFF v.... syst: 00000000 ....x
401E.FFFFFFFFFFFFFFFF soft: 7FFFFFFF v.... syst: 00000000 ....x
Errors found in floatx80_to_int32, rounding up:
401E.FFFFFFFF00800000 soft: 7FFFFFFF v.... syst: 00000000 ....x
401E.FFFFFFFF80000000 soft: 7FFFFFFF v.... syst: 00000000 ....x
401E.FFFFFFFFEFFFC000 soft: 7FFFFFFF v.... syst: 00000000 ....x
401E.FFFFFFFFFC000000 soft: 7FFFFFFF v.... syst: 00000000 ....x
401E.FFFFFFFFFE7FFFFF soft: 7FFFFFFF v.... syst: 00000000 ....x
401E.FFFFFFFFFFF00000 soft: 7FFFFFFF v.... syst: 00000000 ....x
401E.FFFFFFFFFFFE0800 soft: 7FFFFFFF v.... syst: 00000000 ....x
401E.FFFFFFFFFFFF7FFB soft: 7FFFFFFF v.... syst: 00000000 ....x
401E.FFFFFFFFFFFFFFFE soft: 7FFFFFFF v.... syst: 00000000 ....x
401E.FFFFFFFFFFFFFFFF soft: 7FFFFFFF v.... syst: 00000000 ....x
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-------------------------------------------------------------------------------
Intel Pentium Pros
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
floatx80_to_int32
-- The inexact flag is sometimes raised instead of the invalid flag for
floating-point inputs under -(2^32) (C01F.0000000000000000). This bug is
sporadic. It appears to be deterministic but dependent on the sequence
of operations executed.
Errors found in floatx80_to_int32, rounding nearest_even:
C01F.C000000000000002 soft: 80000000 v.... syst: 80000000 ....x
C021.F00000000000003F soft: 80000000 v.... syst: 80000000 ....x
Errors found in floatx80_to_int32, rounding to_zero:
C021.F00000000000003F soft: 80000000 v.... syst: 80000000 ....x
Errors found in floatx80_to_int32, rounding up:
C01F.C000000000000007 soft: 80000000 v.... syst: 80000000 ....x
C01F.C000000000001000 soft: 80000000 v.... syst: 80000000 ....x
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-------------------------------------------------------------------------------
Sun SPARCstation 1's and IPX's
Some older SPARCstations appear confused about whether underflow tininess is
detected before or after rounding. For conversions from double precision
to single precision, tininess is detected after rounding, while for all
quadruple-precision operations it is detected before rounding. Single- and
double-precision multipies go both ways:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
float32_mul, float64_mul
-- For multiplies, underflow tininess is detected _before_ rounding if one
of the inputs is subnormal, and _after_ rounding otherwise. If tininess
is assumed to be detected before rounding, the following errors are
generated:
Errors found in float32_mul, rounding nearest_even:
001.000001 07E.7FFFFE soft: 001.000000 ...ux syst: 001.000000 ....x
001.000001 87E.7FFFFE soft: 801.000000 ...ux syst: 801.000000 ....x
001.000002 07E.7FFFFC soft: 001.000000 ...ux syst: 001.000000 ....x
001.000002 87E.7FFFFC soft: 801.000000 ...ux syst: 801.000000 ....x
001.000004 07E.7FFFF8 soft: 001.000000 ...ux syst: 001.000000 ....x
Errors found in float32_mul, rounding down:
001.000001 87E.7FFFFE soft: 801.000000 ...ux syst: 801.000000 ....x
001.000002 87E.7FFFFC soft: 801.000000 ...ux syst: 801.000000 ....x
001.000004 87E.7FFFF8 soft: 801.000000 ...ux syst: 801.000000 ....x
001.000008 87E.7FFFF0 soft: 801.000000 ...ux syst: 801.000000 ....x
001.000010 87E.7FFFE0 soft: 801.000000 ...ux syst: 801.000000 ....x
Errors found in float32_mul, rounding up:
001.000001 07E.7FFFFE soft: 001.000000 ...ux syst: 001.000000 ....x
001.000002 07E.7FFFFC soft: 001.000000 ...ux syst: 001.000000 ....x
001.000004 07E.7FFFF8 soft: 001.000000 ...ux syst: 001.000000 ....x
001.000008 07E.7FFFF0 soft: 001.000000 ...ux syst: 001.000000 ....x
001.000010 07E.7FFFE0 soft: 001.000000 ...ux syst: 001.000000 ....x
Errors found in float64_mul, rounding nearest_even:
001.0000000000001 3FE.FFFFFFFFFFFFE
soft: 001.0000000000000 ...ux syst: 001.0000000000000 ....x
001.0000000000001 BFE.FFFFFFFFFFFFE
soft: 801.0000000000000 ...ux syst: 801.0000000000000 ....x
001.0000000000002 3FE.FFFFFFFFFFFFC
soft: 001.0000000000000 ...ux syst: 001.0000000000000 ....x
001.0000000000002 BFE.FFFFFFFFFFFFC
soft: 801.0000000000000 ...ux syst: 801.0000000000000 ....x
001.0000000000004 3FE.FFFFFFFFFFFF8
soft: 001.0000000000000 ...ux syst: 001.0000000000000 ....x
Errors found in float64_mul, rounding down:
001.0000000000001 BFE.FFFFFFFFFFFFE
soft: 801.0000000000000 ...ux syst: 801.0000000000000 ....x
001.0000000000002 BFE.FFFFFFFFFFFFC
soft: 801.0000000000000 ...ux syst: 801.0000000000000 ....x
001.0000000000004 BFE.FFFFFFFFFFFF8
soft: 801.0000000000000 ...ux syst: 801.0000000000000 ....x
001.0000000000008 BFE.FFFFFFFFFFFF0
soft: 801.0000000000000 ...ux syst: 801.0000000000000 ....x
001.0000000000010 BFE.FFFFFFFFFFFE0
soft: 801.0000000000000 ...ux syst: 801.0000000000000 ....x
Errors found in float64_mul, rounding up:
001.0000000000001 3FE.FFFFFFFFFFFFE
soft: 001.0000000000000 ...ux syst: 001.0000000000000 ....x
001.0000000000002 3FE.FFFFFFFFFFFFC
soft: 001.0000000000000 ...ux syst: 001.0000000000000 ....x
001.0000000000004 3FE.FFFFFFFFFFFF8
soft: 001.0000000000000 ...ux syst: 001.0000000000000 ....x
001.0000000000008 3FE.FFFFFFFFFFFF0
soft: 001.0000000000000 ...ux syst: 001.0000000000000 ....x
001.0000000000010 3FE.FFFFFFFFFFFE0
soft: 001.0000000000000 ...ux syst: 001.0000000000000 ....x
If we assume tininess should be detected after rounding, we get the
following errors:
Errors found in float32_mul, rounding nearest_even:
000.7FFC00 07F.000400 soft: 001.000000 ....x syst: 001.000000 ...ux
000.7FFC00 87F.000400 soft: 801.000000 ....x syst: 801.000000 ...ux
000.7FFE00 07F.000200 soft: 001.000000 ....x syst: 001.000000 ...ux
000.7FFE00 87F.000200 soft: 801.000000 ....x syst: 801.000000 ...ux
000.7FFF00 07F.000100 soft: 001.000000 ....x syst: 001.000000 ...ux
Errors found in float32_mul, rounding down:
000.7FFC00 87F.000400 soft: 801.000000 ....x syst: 801.000000 ...ux
000.7FFE00 87F.000200 soft: 801.000000 ....x syst: 801.000000 ...ux
000.7FFF00 87F.000100 soft: 801.000000 ....x syst: 801.000000 ...ux
000.7FFF80 87F.000080 soft: 801.000000 ....x syst: 801.000000 ...ux
000.7FFFC0 87F.000040 soft: 801.000000 ....x syst: 801.000000 ...ux
Errors found in float32_mul, rounding up:
000.7FFC00 07F.000400 soft: 001.000000 ....x syst: 001.000000 ...ux
000.7FFE00 07F.000200 soft: 001.000000 ....x syst: 001.000000 ...ux
000.7FFF00 07F.000100 soft: 001.000000 ....x syst: 001.000000 ...ux
000.7FFF80 07F.000080 soft: 001.000000 ....x syst: 001.000000 ...ux
000.7FFFC0 07F.000040 soft: 001.000000 ....x syst: 001.000000 ...ux
Errors found in float64_mul, rounding nearest_even:
000.FFFFFFE000000 3FF.0000002000000
soft: 001.0000000000000 ....x syst: 001.0000000000000 ...ux
000.FFFFFFE000000 BFF.0000002000000
soft: 801.0000000000000 ....x syst: 801.0000000000000 ...ux
000.FFFFFFF000000 3FF.0000001000000
soft: 001.0000000000000 ....x syst: 001.0000000000000 ...ux
000.FFFFFFF000000 BFF.0000001000000
soft: 801.0000000000000 ....x syst: 801.0000000000000 ...ux
000.FFFFFFF800000 3FF.0000000800000
soft: 001.0000000000000 ....x syst: 001.0000000000000 ...ux
Errors found in float64_mul, rounding down:
000.FFFFFFE000000 BFF.0000002000000
soft: 801.0000000000000 ....x syst: 801.0000000000000 ...ux
000.FFFFFFF000000 BFF.0000001000000
soft: 801.0000000000000 ....x syst: 801.0000000000000 ...ux
000.FFFFFFF800000 BFF.0000000800000
soft: 801.0000000000000 ....x syst: 801.0000000000000 ...ux
000.FFFFFFFC00000 BFF.0000000400000
soft: 801.0000000000000 ....x syst: 801.0000000000000 ...ux
000.FFFFFFFE00000 BFF.0000000200000
soft: 801.0000000000000 ....x syst: 801.0000000000000 ...ux
Errors found in float64_mul, rounding up:
000.FFFFFFE000000 3FF.0000002000000
soft: 001.0000000000000 ....x syst: 001.0000000000000 ...ux
000.FFFFFFF000000 3FF.0000001000000
soft: 001.0000000000000 ....x syst: 001.0000000000000 ...ux
000.FFFFFFF800000 3FF.0000000800000
soft: 001.0000000000000 ....x syst: 001.0000000000000 ...ux
000.FFFFFFFC00000 3FF.0000000400000
soft: 001.0000000000000 ....x syst: 001.0000000000000 ...ux
000.FFFFFFFE00000 3FF.0000000200000
soft: 001.0000000000000 ....x syst: 001.0000000000000 ...ux
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-------------------------------------------------------------------------------
Sun SPARCstation 10's
Like other SPARCstations, some SPARCstation 10's are inconsistent regarding
underflow tininess, detecting it after rounding for single- and double-
precision operations and before rounding for quadruple-precision operations.
The following bug has also been observed.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
float32_to_int32_round_to_zero, float64_to_int32_round_to_zero
-- Single- and double-precision NaNs are converted to the integer zero.
(The invalid exception flag is raised correctly.)
Errors found in float32_to_int32_round_to_zero:
8FF.5D36AC soft: 7FFFFFFF v.... syst: 00000000 v....
0FF.7FFFC0 soft: 7FFFFFFF v.... syst: 00000000 v....
8FF.7C0000 soft: 7FFFFFFF v.... syst: 00000000 v....
0FF.2AB7ED soft: 7FFFFFFF v.... syst: 00000000 v....
0FF.03FFFF soft: 7FFFFFFF v.... syst: 00000000 v....
Errors found in float64_to_int32_round_to_zero:
7FF.45AD84DB2524A soft: 7FFFFFFF v.... syst: 00000000 v....
7FF.CFEE063EE0512 soft: 7FFFFFFF v.... syst: 00000000 v....
7FF.89FF03AB7DBA2 soft: 7FFFFFFF v.... syst: 00000000 v....
7FF.FFFFFFFFFF800 soft: 7FFFFFFF v.... syst: 00000000 v....
FFF.68A6410E91BF6 soft: 7FFFFFFF v.... syst: 00000000 v....
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-------------------------------------------------------------------------------
HP Precision Architecture processors, with HP-UX prior to version 10.10
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
float32_to_int32_round_to_zero, float64_to_int32_round_to_zero
-- When the floating-point value is too large, the overflow and inexact
exception flags are raised instead of the invalid flag.
Errors found in float32_to_int32_round_to_zero:
89E.000007 soft: 80000000 v.... syst: 80000000 ..o.x
0A2.000020 soft: 7FFFFFFF v.... syst: 7FFFFFFF ..o.x
8FA.7C0000 soft: 80000000 v.... syst: 80000000 ..o.x
Errors found in float64_to_int32_round_to_zero:
7FD.0448700002F1C soft: 7FFFFFFF v.... syst: 7FFFFFFF ..o.x
DAA.F000000000000 soft: 80000000 v.... syst: 80000000 ..o.x
41E.063DA00005E65 soft: 7FFFFFFF v.... syst: 7FFFFFFF ..o.x
47E.FFFF800000000 soft: 7FFFFFFF v.... syst: 7FFFFFFF ..o.x
51F.0000000000004 soft: 7FFFFFFF v.... syst: 7FFFFFFF ..o.x
DDA.0000001FFFFFF soft: 80000000 v.... syst: 80000000 ..o.x
D70.00000000003FF soft: 80000000 v.... syst: 80000000 ..o.x
C7E.0000100000000 soft: 80000000 v.... syst: 80000000 ..o.x
47E.000000000007F soft: 7FFFFFFF v.... syst: 7FFFFFFF ..o.x
D57.000000000FFFF soft: 80000000 v.... syst: 80000000 ..o.x
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

57
regress/lib/libc/ieeefp/testfloat/notes/testfloat-history.txt Normal file
View File

@ -0,0 +1,57 @@
History of Major Changes to TestFloat, up to Release 2a
John R. Hauser
1998 December 17
The TestFloat releases parallel those of SoftFloat, on which TestFloat is
based. Each TestFloat release also incorporates all bug fixes from the
corresponding release of SoftFloat.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Release 2a (1998 December)
-- Added support for testing conversions between floating-point and 64-bit
integers.
-- Improved the makefiles.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Release 2 (1997 June)
-- Integrated the generation of test cases and the checking of system
results into a single program. (Before they were separate programs,
normally joined by explicit command-line pipes.)
-- Improved the sequence of test cases.
-- Added support for testing extended double precision and quadruple
precision.
-- Made program output more readable, and added new command arguments.
-- Reduced dependence on the quality of the standard `random' function for
generating test cases. (Previously naively expected `random' to be able
to generate good random bits for the entire machine word width.)
-- Created `testsoftfloat', with its own simpler complete software floating-
point (``slowfloat'') for comparison purposes.
-- Made some changes to the source file structure, including renaming
`environment.h' to `milieu.h' (to avoid confusion with environment
variables).
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Release 1a (1996 July)
-- Added the `-tininessbefore' and `-tininessafter' options to control
whether tininess should be detected before or after rounding.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Release 1 (1996 July)
-- Original release.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

444
regress/lib/libc/ieeefp/testfloat/notes/testfloat-source.txt Normal file
View File

@ -0,0 +1,444 @@
TestFloat Release 2a Source Documentation
John R. Hauser
1998 December 16
-------------------------------------------------------------------------------
Introduction
TestFloat is a program for testing that a floating-point implementation
conforms to the IEC/IEEE Standard for Binary Floating-Point Arithmetic.
All standard operations supported by the system can be tested, except for
conversions to and from decimal. Any of the following machine formats can
be tested: single precision, double precision, extended double precision,
and/or quadruple precision. Testing extended double-precision or quadruple-
precision formats requires a C compiler that supports 64-bit integer
arithmetic.
This document gives information needed for compiling and/or porting
TestFloat.
The source code for TestFloat is intended to be relatively machine-
independent. TestFloat is written in C, and should be compilable using
any ISO/ANSI C compiler. At the time of this writing, the program has
been successfully compiled using the GNU C Compiler (`gcc') for several
platforms. Because ISO/ANSI C does not provide access to some features
of IEC/IEEE floating-point such as the exception flags, porting TestFloat
unfortunately involves some machine-dependent coding.
TestFloat depends on SoftFloat, which is a software implementation of
floating-point that conforms to the IEC/IEEE Standard. SoftFloat is not
included with the TestFloat sources. It can be obtained from the Web
page `http://HTTP.CS.Berkeley.EDU/~jhauser/arithmetic/SoftFloat.html'.
In addition to a program for testing a machine's floating-point, the
TestFloat package includes a variant for testing SoftFloat called
`testsoftfloat'. The sources for both programs are intermixed, and both are
described here.
The first release of TestFloat (Release 1) was called _FloatTest_. The old
name has been obsolete for some time.
-------------------------------------------------------------------------------
Limitations
TestFloat as written requires an ISO/ANSI-style C compiler. No attempt has
been made to accomodate compilers that are not ISO-conformant. Older ``K&R-
style'' compilers are not adequate for compiling TestFloat. All testing I
have done so far has been with the GNU C Compiler. Compilation with other
compilers should be possible but has not been tested.
The TestFloat sources assume that source code file names can be longer than
8 characters. In order to compile under an MS-DOS-style system, many of the
source files will need to be renamed, and the source and makefiles edited
appropriately. Once compiled, the TestFloat program does not depend on the
existence of long file names.
The underlying machine is assumed to be binary with a word size that is a
power of 2. Bytes are 8 bits. Testing of extended double-precision and
quadruple-precision formats depends on the C compiler implementing a 64-bit
integer type. If the largest integer type supported by the C compiler is
32 bits, only single- and double-precision operations can be tested.
-------------------------------------------------------------------------------
Contents
Introduction
Limitations
Contents
Legal Notice
TestFloat Source Directory Structure
Target-Independent Modules
Target-Specific Modules
Target-Specific Header Files
processors/*.h
testfloat/*/milieu.h
Target-Specific Floating-Point Subroutines
Steps to Creating the TestFloat Executables
Improving the Random Number Generator
Contact Information
-------------------------------------------------------------------------------
Legal Notice
TestFloat was written by John R. Hauser.
THIS SOFTWARE IS DISTRIBUTED AS IS, FOR FREE. Although reasonable effort
has been made to avoid it, THIS SOFTWARE MAY CONTAIN FAULTS THAT WILL AT
TIMES RESULT IN INCORRECT BEHAVIOR. USE OF THIS SOFTWARE IS RESTRICTED TO
PERSONS AND ORGANIZATIONS WHO CAN AND WILL TAKE FULL RESPONSIBILITY FOR ANY
AND ALL LOSSES, COSTS, OR OTHER PROBLEMS ARISING FROM ITS USE.
-------------------------------------------------------------------------------
TestFloat Source Directory Structure
Because TestFloat is targeted to multiple platforms, its source code
is slightly scattered between target-specific and target-independent
directories and files. The directory structure is as follows:
processors
testfloat
templates
386-Win32-gcc
SPARC-Solaris-gcc
The two topmost directories and their contents are:
testfloat - Most of the source code needed for TestFloat.
processors - Target-specific header files that are not specific to
TestFloat.
Within the `testfloat' directory are subdirectories for each of the
targeted platforms. The TestFloat source code is distributed with targets
`386-Win32-gcc' and `SPARC-Solaris-gcc' (and perhaps others) already
prepared. These can be used as examples for porting to new targets. Source
files that are not within these target-specific subdirectories are intended
to be target-independent.
The naming convention used for the target-specific directories is
`<processor>-<executable-type>-<compiler>'. The names of the supplied
target directories should be interpreted as follows:
<processor>:
386 - Intel 386-compatible processor.
SPARC - SPARC processor (as used by Sun machines).
<executable-type>:
Win32 - Microsoft Win32 executable.
Solaris - Sun Solaris executable.
<compiler>:
gcc - GNU C Compiler.
You do not need to maintain this convention if you do not want to.
Alongside the supplied target-specific directories there is a `templates'
directory containing a set of ``generic'' target-specific source files.
A new target directory can be created by copying the `templates' directory
and editing the files inside. (Complete instructions for porting TestFloat
to a new target are in the section _Steps_to_Creating_the_TestFloat_
_Executables_.) Note that the `templates' directory will not work as a
target directory without some editing. To avoid confusion, it would be wise
to refrain from editing the files inside `templates' directly.
In addition to the distributed sources, TestFloat depends on the existence
of an appropriately-compiled SoftFloat binary and the corresponding header
file `softfloat.h'. SoftFloat is not included with the TestFloat sources.
It can be obtained from the Web page `http://HTTP.CS.Berkeley.EDU/~jhauser/
arithmetic/SoftFloat.html'.
As distributed, the makefiles for TestFloat assume the existence of three
sibling directories:
processors
softfloat
testfloat
Only the `processors' and `testfloat' directories are included in the
TestFloat package. The `softfloat' directory is assumed to contain a
target-specific subdirectory within which the SoftFloat header file and
compiled binary can be found. (See the source documentation accompanying
SoftFloat.) The `processors' directory distributed with TestFloat is
intended to be identical to that included with the SoftFloat source.
These are the defaults, but other organizations of the sources are possible.
The TestFloat makefiles and `milieu.h' files (see below) are easily edited
to accomodate other arrangements.
-------------------------------------------------------------------------------
Target-Independent Modules
The TestFloat program is composed of a number of modules, some target-
specific and some target-independent. The target-independent modules are as
follows:
-- The `fail' module provides a common routine for writing an error message
and aborting.
-- The `random' module generates random integer values.
-- The `writeHex' module defines routines for writing the various types in
the hexadecimal form used by TestFloat.
-- The `testCases' module generates test cases for the various types.
-- The `testLoops' module contains various routines for exercising two
implementations of a function and reporting any differences observed.
-- The `slowfloat' module provides the simple floating-point implementation
used by `testsoftfloat' for comparing against SoftFloat. The heart
of `slowfloat' is found in either `slowfloat-32' or `slowfloat-64',
depending on whether the `BITS64' macro is defined.
-- The `systfloat' module gives a SoftFloat-like interface to the machine's
floating-point.
-- The `testFunction' module implements `testfloat's main loop for testing a
function for all of the relevant rounding modes and rounding precisions.
(The `testsoftfloat' program contains its own version of this code.)
-- The `testfloat' and `testsoftfloat' modules are the main modules for the
`testfloat' and `testsoftfloat' programs.
Except possibly for `systfloat', these modules should not need to be
modified.
The `systfloat' module uses the floating-point operations of the C language
to access a machine's floating-point. Unfortunately, some IEC/IEEE
floating-point operations are not accessible within ISO/ANSI C. The
following machine functions cannot be tested unless an alternate `systfloat'
module is provided:
<float>_to_int32 (rounded according to rounding mode)
<float>_to_int64 (rounded according to rounding mode)
<float>_round_to_int
<float>_rem
<float>_sqrt, except float64_sqrt
<float>_eq_signaling
<float>_le_quiet
<float>_lt_quiet
The `-list' option to `testfloat' will show the operations the program is
prepared to test. The section _Target-Specific_Floating-Point_Subroutines_
later in this document explains how to create a target-specific `systfloat'
module to change the set of testable functions.
-------------------------------------------------------------------------------
Target-Specific Modules
No target-specific modules are needed for `testsoftfloat'.
The `testfloat' program uses two target-specific modules:
-- The `systmodes' module defines functions for setting the modes
controlling the system's floating-point, including the rounding mode and
the rounding precision for extended double precision.
-- The `systflags' module provides a function for clearing and examining the
system's floating-point exception flags.
These modules must be supplied for each target. They can be implemented in
any way desired, so long as all is reflected in the target's makefile. For
the targets that come with the distributed source, each of these modules is
implemented as a single assembly language or C language source file.
-------------------------------------------------------------------------------
Target-Specific Header Files
The purpose of the two target-specific header files is detailed below.
In the following, the `*' symbol is used in place of the name of a specific
target, such as `386-Win32-gcc' or `SPARC-Solaris-gcc', or in place of some
other text as explained below.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
processors/*.h
The target-specific `processors' header file defines integer types
of various sizes, and also defines certain C preprocessor macros that
characterize the target. The two examples supplied are `386-gcc.h' and
`SPARC-gcc.h'. The naming convention used for processor header files is
`<processor>-<compiler>.h'. The `processors' header file used to compile
TestFloat should be the same as that used to compile SoftFloat.
If 64-bit integers are supported by the compiler, the macro name `BITS64'
should be defined here along with the corresponding 64-bit integer
types. In addition, the function-like macro `LIT64' must be defined for
constructing 64-bit integer literals (constants). The `LIT64' macro is used
consistently in the TestFloat code to annotate 64-bit literals.
If an inlining attribute (such as an `inline' keyword) is provided by the
compiler, the macro `INLINE' should be defined to the appropriate keyword.
If not, `INLINE' can be set to the keyword `static'. The `INLINE' macro
appears in the TestFloat source code before every function that should be
inlined by the compiler.
For maximum flexibility, the TestFloat source files do not include the
`processors' header file directly; rather, this file is included by the
target-specific `milieu.h' header, and `milieu.h' is included by the source
files.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
testfloat/*/milieu.h
The `milieu.h' header file provides declarations that are needed to
compile TestFloat. In particular, it is through this header file that
the appropriate `processors' header is included to characterize the target
processor. In addition, deviations from ISO/ANSI C by the compiler (such as
names not properly declared in system header files) are corrected in this
header if possible.
If the preprocessor macro `BITS64' is defined in the `processors' header
file but only the 32-bit version of SoftFloat is actually used, the `BITS64'
macro should be undefined here after the `processors' header has defined it.
If the C compiler implements the `long double' floating-point type of C
as extended double precision, then `LONG_DOUBLE_IS_FLOATX80' should be
defined here. Alternatively, if the C `long double' type is implemented as
quadruple precision, `LONG_DOUBLE_IS_FLOAT128' should be defined. At most
one of these macros should be defined. A C compiler is allowed to implement
`long double' the same as `double', in which case neither of these macros
should be defined.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-------------------------------------------------------------------------------
Target-Specific Floating-Point Subroutines
This section applies only to `testfloat' and not to `testsoftfloat'.
By default, TestFloat tests a machine's floating-point by testing the
floating-point operations of the C language. Unfortunately, some IEC/IEEE
floating-point operations are not defined within ISO/ANSI C. If a machine
implements such ``non-C'' operations, target-specific subroutines for
the operations can be supplied to allow TestFloat to test these machine
features. Typically, such subroutines will need to be written in assembly
language, although equivalent functions can sometimes be found among the
system's software libraries.
The following machine functions cannot be tested by TestFloat unless target-
specific subroutines are supplied for them:
<float>_to_int32 (rounded according to rounding mode)
<float>_to_int64 (rounded according to rounding mode)
<float>_round_to_int
<float>_rem
<float>_sqrt, except float64_sqrt
<float>_eq_signaling
<float>_le_quiet
<float>_lt_quiet
In addition to these, none of the `floatx80' functions can be tested by
default if the C `long double' type is something other than extended double
precision; and likewise, none of the `float128' functions can be tested by
default if `long double' is not quadruple precision. Since `long double'
cannot be both extended double precision and quadruple precision at the
same time, at least one of these types cannot be tested by TestFloat without
appropriate subroutines being supplied for that type. (On the other hand,
few systems implement _both_ extended double-precision and quadruple-
precision floating-point; and unless a system does implement both, it does
not need both tested.)
Note that the `-list' option to `testfloat' will show the operations
TestFloat is prepared to test.
TestFloat's `systfloat' module supplies the system version of the functions
to be tested. The names of the `systfloat' subroutines are the same as the
function names used as arguments to the `testfloat' command but with `syst_'
prefixed--thus, for example, `syst_float32_add' and `syst_int32_to_float32'.
The default `systfloat' module maps these system functions to the standard
C operations; so `syst_float32_add', for example, is implemented using the
C `+' operation for the single-precision `float' type. For each system
function supplied by `systfloat', a corresponding `SYST_<function>'
preprocessor macro is defined in `systfloat.h' to indicate that the function
exists to be tested (e.g., `SYST_FLOAT32_ADD'). The `systfloat.h' header
file also declares function prototypes for the `systfloat' functions.
(The `systfloat.h' file that comes with the TestFloat package declares
prototypes for all of the possible `systfloat' functions, whether defined in
`systfloat' or not. There is no penalty for declaring a function prototype
that is never used.)
A target-specific version of the `systfloat' module can easily be created to
replace the generic one. This in fact has been done for the example targets
`386-Win32-gcc' and `SPARC-Solaris-gcc'. For each target, an assembly
language `systfloat.S' has been created in the target directory along with
a corresponding `systfloat.h' header file defining the `SYST_<function>'
macros for the functions implemented. The makefiles of the targets have
been edited to use these target-specific versions of `systfloat' rather than
the generic one.
The `systfloat' modules of the example targets have been written entirely
in assembly language in order to bypass any peculiarities of the C compiler.
Although this is probably a good idea, it is certainly not required.
-------------------------------------------------------------------------------
Steps to Creating the TestFloat Executables
Porting and/or compiling TestFloat involves the following steps:
1. Port SoftFloat and create a SoftFloat binary. (Refer to the
documentation accompanying SoftFloat.)
2. If one does not already exist, create an appropriate target-specific
subdirectory under `testfloat' by copying the given `templates'
directory. The remaining steps occur within the target-specific
subdirectory.
3. Edit the files `milieu.h' and `Makefile' to reflect the current
environment.
4. Make `testsoftfloat' by executing `make testsoftfloat' (or `make
testsoftfloat.exe', or whatever the `testsoftfloat' executable is
called). Verify that SoftFloat is working correctly by testing it with
`testsoftfloat'.
If you only wanted `testsoftfloat', you are done. The steps for `testfloat'
continue:
5. In the target-specific subdirectory, implement the `systmodes' and
`systflags' modules. (The `syst_float_set_rounding_precision' function
need not do anything if the system does not support extended double
precision.)
6. If the target machine supports standard floating-point functions that are
not accessible within ISO/ANSI C, or if the C compiler cannot be trusted
to use the machine's floating-point directly, create a target-specific
`systfloat' module.
7. In the target-specific subdirectory, execute `make'.
-------------------------------------------------------------------------------
Improving the Random Number Generator
If you are serious about using TestFloat for testing floating-point, you
should consider replacing the supplied `random.c' with a better target-
specific one. The standard C `rand' function is rather poor on some
systems, and consequently `random.c' has been written to assume very little
about the quality of `rand'. As a result, the `rand' function is called
more frequently than it might need to be, shortening the time before
the random number generator repeats, and possibly wasting time as well.
If `rand' is better on your system, or if another better random number
generator is available (such as `rand48' on most Unix systems), TestFloat
can be improved by overriding the given `random.c' with a target-specific
one.
-------------------------------------------------------------------------------
Contact Information
At the time of this writing, the most up-to-date information about
TestFloat and the latest release can be found at the Web page `http://
HTTP.CS.Berkeley.EDU/~jhauser/arithmetic/TestFloat.html'.

771
regress/lib/libc/ieeefp/testfloat/notes/testfloat.txt Normal file
View File

@ -0,0 +1,771 @@
TestFloat Release 2a General Documentation
John R. Hauser
1998 December 16
-------------------------------------------------------------------------------
Introduction
TestFloat is a program for testing that a floating-point implementation
conforms to the IEC/IEEE Standard for Binary Floating-Point Arithmetic.
All standard operations supported by the system can be tested, except for
conversions to and from decimal. Any of the following machine formats can
be tested: single precision, double precision, extended double precision,
and/or quadruple precision.
TestFloat actually comes in two variants: one is a program for testing
a machine's floating-point, and the other is a program for testing
the SoftFloat software implementation of floating-point. (Information
about SoftFloat can be found at the SoftFloat Web page, `http://
HTTP.CS.Berkeley.EDU/~jhauser/arithmetic/SoftFloat.html'.) The version that
tests SoftFloat is expected to be of interest only to people compiling the
SoftFloat sources. However, because the two versions share much in common,
they are discussed together in all the TestFloat documentation.
This document explains how to use the TestFloat programs. It does not
attempt to define or explain the IEC/IEEE Standard for floating-point.
Details about the standard are available elsewhere.
The first release of TestFloat (Release 1) was called _FloatTest_. The old
name has been obsolete for some time.
-------------------------------------------------------------------------------
Limitations
TestFloat's output is not always easily interpreted. Detailed knowledge
of the IEC/IEEE Standard and its vagaries is needed to use TestFloat
responsibly.
TestFloat performs relatively simple tests designed to check the fundamental
soundness of the floating-point under test. TestFloat may also at times
manage to find rarer and more subtle bugs, but it will probably only find
such bugs by accident. Software that purposefully seeks out various kinds
of subtle floating-point bugs can be found through links posted on the
TestFloat Web page (`http://HTTP.CS.Berkeley.EDU/~jhauser/arithmetic/
TestFloat.html').
-------------------------------------------------------------------------------
Contents
Introduction
Limitations
Contents
Legal Notice
What TestFloat Does
Executing TestFloat
Functions Tested by TestFloat
Conversion Functions
Standard Arithmetic Functions
Remainder and Round-to-Integer Functions
Comparison Functions
Interpreting TestFloat Output
Variations Allowed by the IEC/IEEE Standard
Underflow
NaNs
Conversions to Integer
TestFloat Options
-help
-list
-level <num>
-errors <num>
-errorstop
-forever
-checkNaNs
-precision32, -precision64, -precision80
-nearesteven, -tozero, -down, -up
-tininessbefore, -tininessafter
Function Sets
Contact Information
-------------------------------------------------------------------------------
Legal Notice
TestFloat was written by John R. Hauser.
THIS SOFTWARE IS DISTRIBUTED AS IS, FOR FREE. Although reasonable effort
has been made to avoid it, THIS SOFTWARE MAY CONTAIN FAULTS THAT WILL AT
TIMES RESULT IN INCORRECT BEHAVIOR. USE OF THIS SOFTWARE IS RESTRICTED TO
PERSONS AND ORGANIZATIONS WHO CAN AND WILL TAKE FULL RESPONSIBILITY FOR ANY
AND ALL LOSSES, COSTS, OR OTHER PROBLEMS ARISING FROM ITS USE.
-------------------------------------------------------------------------------
What TestFloat Does
TestFloat tests a system's floating-point by comparing its behavior with
that of TestFloat's own internal floating-point implemented in software.
For each operation tested, TestFloat generates a large number of test cases,
made up of simple pattern tests intermixed with weighted random inputs.
The cases generated should be adequate for testing carry chain propagations,
plus the rounding of adds, subtracts, multiplies, and simple operations like
conversions. TestFloat makes a point of checking all boundary cases of the
arithmetic, including underflows, overflows, invalid operations, subnormal
inputs, zeros (positive and negative), infinities, and NaNs. For the
interesting operations like adds and multiplies, literally millions of test
cases can be checked.
TestFloat is not remarkably good at testing difficult rounding cases for
divisions and square roots. It also makes no attempt to find bugs specific
to SRT divisions and the like (such as the infamous Pentium divide bug).
Software that tests for such failures can be found through links on the
TestFloat Web page, `http://HTTP.CS.Berkeley.EDU/~jhauser/arithmetic/
TestFloat.html'.
NOTE!
It is the responsibility of the user to verify that the discrepancies
TestFloat finds actually represent faults in the system being tested.
Advice to help with this task is provided later in this document.
Furthermore, even if TestFloat finds no fault with a floating-point
implementation, that in no way guarantees that the implementation is bug-
free.
For each operation, TestFloat can test all four rounding modes required
by the IEC/IEEE Standard. TestFloat verifies not only that the numeric
results of an operation are correct, but also that the proper floating-point
exception flags are raised. All five exception flags are tested, including
the inexact flag. TestFloat does not attempt to verify that the floating-
point exception flags are actually implemented as sticky flags.
For machines that implement extended double precision with rounding
precision control (such as Intel's 80x86), TestFloat can test the add,
subtract, multiply, divide, and square root functions at all the standard
rounding precisions. The rounding precision can be set equivalent to single
precision, to double precision, or to the full extended double precision.
Rounding precision control can only be applied to the extended double-
precision format and only for the five standard arithmetic operations: add,
subtract, multiply, divide, and square root. Other functions can be tested
only at full precision.
As a rule, TestFloat is not particular about the bit patterns of NaNs that
appear as function results. Any NaN is considered as good a result as
another. This laxness can be overridden so that TestFloat checks for
particular bit patterns within NaN results. See the sections _Variations_
_Allowed_by_the_IEC/IEEE_Standard_ and _TestFloat_Options_ for details.
Not all IEC/IEEE Standard functions are supported by all machines.
TestFloat can only test functions that exist on the machine. But even if
a function is supported by the machine, TestFloat may still not be able
to test the function if it is not accessible through standard ISO C (the
programming language in which TestFloat is written) and if the person who
compiled TestFloat did not provide an alternate means for TestFloat to
invoke the machine function.
TestFloat compares a machine's floating-point against the SoftFloat software
implementation of floating-point, also written by me. SoftFloat is built
into the TestFloat executable and does not need to be supplied by the user.
If SoftFloat is wanted for some other reason (to compile a new version
of TestFloat, for instance), it can be found separately at the Web page
`http://HTTP.CS.Berkeley.EDU/~jhauser/arithmetic/SoftFloat.html'.
For testing SoftFloat itself, the TestFloat package includes a program that
compares SoftFloat's floating-point against _another_ software floating-
point implementation. The second software floating-point is simpler and
slower than SoftFloat, and is completely independent of SoftFloat. Although
the second software floating-point cannot be guaranteed to be bug-free, the
chance that it would mimic any of SoftFloat's bugs is remote. Consequently,
an error in one or the other floating-point version should appear as an
unexpected discrepancy between the two implementations. Note that testing
SoftFloat should only be necessary when compiling a new TestFloat executable
or when compiling SoftFloat for some other reason.
-------------------------------------------------------------------------------
Executing TestFloat
TestFloat is intended to be executed from a command line interpreter. The
`testfloat' program is invoked as follows:
testfloat [<option>...] <function>
Here square brackets ([]) indicate optional items, while angled brackets
(<>) denote parameters to be filled in.
The `<function>' argument is a name like `float32_add' or `float64_to_int32'.
The complete list of function names is given in the next section,
_Functions_Tested_by_TestFloat_. It is also possible to test all machine
functions in a single invocation. The various options to TestFloat are
detailed in the section _TestFloat_Options_ later in this document. If
`testfloat' is executed without any arguments, a summary of TestFloat usage
is written.
TestFloat will ordinarily test a function for all four rounding modes, one
after the other. If the rounding mode is not supposed to have any affect
on the results--for instance, some operations do not require rounding--only
the nearest/even rounding mode is checked. For extended double-precision
operations affected by rounding precision control, TestFloat also tests all
three rounding precision modes, one after the other. Testing can be limited
to a single rounding mode and/or rounding precision with appropriate options
(see _TestFloat_Options_).
As it executes, TestFloat writes status information to the standard error
output, which should be the screen by default. In order for this status to
be displayed properly, the standard error stream should not be redirected
to a file. The discrepancies TestFloat finds are written to the standard
output stream, which is easily redirected to a file if desired. Ordinarily,
the errors TestFloat reports and the ongoing status information appear
intermixed on the same screen.
The version of TestFloat for testing SoftFloat is called `testsoftfloat'.
It is invoked the same as `testfloat',
testsoftfloat [<option>...] <function>
and operates similarly.
-------------------------------------------------------------------------------
Functions Tested by TestFloat
TestFloat tests all operations required by the IEC/IEEE Standard except for
conversions to and from decimal. The operations are
-- Conversions among the supported floating-point formats, and also between
integers (32-bit and 64-bit) and any of the floating-point formats.
-- The usual add, subtract, multiply, divide, and square root operations
for all supported floating-point formats.
-- For each format, the floating-point remainder operation defined by the
IEC/IEEE Standard.
-- For each floating-point format, a ``round to integer'' operation that
rounds to the nearest integer value in the same format. (The floating-
point formats can hold integer values, of course.)
-- Comparisons between two values in the same floating-point format.
Detailed information about these functions is given below. In the function
names used by TestFloat, single precision is called `float32', double
precision is `float64', extended double precision is `floatx80', and
quadruple precision is `float128'. TestFloat uses the same names for
functions as SoftFloat.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Conversion Functions
All conversions among the floating-point formats and all conversion between
a floating-point format and 32-bit and 64-bit signed integers can be tested.
The conversion functions are:
int32_to_float32 int64_to_float32
int32_to_float64 int64_to_float32
int32_to_floatx80 int64_to_floatx80
int32_to_float128 int64_to_float128
float32_to_int32 float32_to_int64
float32_to_int32 float64_to_int64
floatx80_to_int32 floatx80_to_int64
float128_to_int32 float128_to_int64
float32_to_float64 float32_to_floatx80 float32_to_float128
float64_to_float32 float64_to_floatx80 float64_to_float128
floatx80_to_float32 floatx80_to_float64 floatx80_to_float128
float128_to_float32 float128_to_float64 float128_to_floatx80
These conversions all round according to the current rounding mode as
necessary. Conversions from a smaller to a larger floating-point format are
always exact and so require no rounding. Conversions from 32-bit integers
to double precision or to any larger floating-point format are also exact,
and likewise for conversions from 64-bit integers to extended double and
quadruple precisions.
ISO/ANSI C requires that conversions to integers be rounded toward zero.
Such conversions can be tested with the following functions that ignore any
rounding mode:
float32_to_int32_round_to_zero float32_to_int64_round_to_zero
float64_to_int32_round_to_zero float64_to_int64_round_to_zero
floatx80_to_int32_round_to_zero floatx80_to_int64_round_to_zero
float128_to_int32_round_to_zero float128_to_int64_round_to_zero
TestFloat assumes that conversions from floating-point to integer should
raise the invalid exception if the source value cannot be rounded to a
representable integer of the desired size (32 or 64 bits). If such a
conversion overflows, TestFloat expects the largest integer with the same
sign as the operand to be returned. If the floating-point operand is a NaN,
TestFloat allows either the largest postive or largest negative integer to
be returned.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Standard Arithmetic Functions
The following standard arithmetic functions can be tested:
float32_add float32_sub float32_mul float32_div float32_sqrt
float64_add float64_sub float64_mul float64_div float64_sqrt
floatx80_add floatx80_sub floatx80_mul floatx80_div floatx80_sqrt
float128_add float128_sub float128_mul float128_div float128_sqrt
The extended double-precision (`floatx80') functions can be rounded to
reduced precision under rounding precision control.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Remainder and Round-to-Integer Functions
For each format, TestFloat can test the IEC/IEEE Standard remainder and
round-to-integer functions. The remainder functions are:
float32_rem
float64_rem
floatx80_rem
float128_rem
The round-to-integer functions are:
float32_round_to_int
float64_round_to_int
floatx80_round_to_int
float128_round_to_int
The remainder functions are always exact and so do not require rounding.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Comparison Functions
The following floating-point comparison functions can be tested:
float32_eq float32_le float32_lt
float64_eq float64_le float64_lt
floatx80_eq floatx80_le floatx80_lt
float128_eq float128_le float128_lt
The abbreviation `eq' stands for ``equal'' (=); `le' stands for ``less than
or equal'' (<=); and `lt' stands for ``less than'' (<).
The IEC/IEEE Standard specifies that the less-than-or-equal and less-than
functions raise the invalid exception if either input is any kind of NaN.
The equal functions, for their part, are defined not to raise the invalid
exception on quiet NaNs. For completeness, the following additional
functions can be tested if supported:
float32_eq_signaling float32_le_quiet float32_lt_quiet
float64_eq_signaling float64_le_quiet float64_lt_quiet
floatx80_eq_signaling floatx80_le_quiet floatx80_lt_quiet
float128_eq_signaling float128_le_quiet float128_lt_quiet
The `signaling' equal functions are identical to the standard functions
except that the invalid exception should be raised for any NaN input.
Likewise, the `quiet' comparison functions should be identical to their
counterparts except that the invalid exception is not raised for quiet NaNs.
Obviously, no comparison functions ever require rounding. Any rounding mode
is ignored.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-------------------------------------------------------------------------------
Interpreting TestFloat Output
The ``errors'' reported by TestFloat may or may not really represent errors
in the system being tested. For each test case tried, TestFloat performs
the same floating-point operation for the two implementations being compared
and reports any unexpected difference in the results. The two results could
differ for several reasons:
-- The IEC/IEEE Standard allows for some variation in how conforming
floating-point behaves. Two implementations can occasionally give
different results without either being incorrect.
-- The trusted floating-point emulation could be faulty. This could be
because there is a bug in the way the enulation is coded, or because a
mistake was made when the code was compiled for the current system.
-- TestFloat may not work properly, reporting discrepancies that do not
exist.
-- Lastly, the floating-point being tested could actually be faulty.
It is the responsibility of the user to determine the causes for the
discrepancies TestFloat reports. Making this determination can require
detailed knowledge about the IEC/IEEE Standard. Assuming TestFloat is
working properly, any differences found will be due to either the first or
last of these reasons. Variations in the IEC/IEEE Standard that could lead
to false error reports are discussed in the section _Variations_Allowed_by_
_the_IEC/IEEE_Standard_.
For each error (or apparent error) TestFloat reports, a line of text
is written to the default output. If a line would be longer than 79
characters, it is divided. The first part of each error line begins in the
leftmost column, and any subsequent ``continuation'' lines are indented with
a tab.
Each error reported by `testfloat' is of the form:
<inputs> soft: <output-from-emulation> syst: <output-from-system>
The `<inputs>' are the inputs to the operation. Each output is shown as a
pair: the result value first, followed by the exception flags. The `soft'
label stands for ``software'' (or ``SoftFloat''), while `syst' stands for
``system,'' the machine's floating-point.
For example, two typical error lines could be
800.7FFF00 87F.000100 soft: 001.000000 ....x syst: 001.000000 ...ux
081.000004 000.1FFFFF soft: 001.000000 ....x syst: 001.000000 ...ux
In the first line, the inputs are `800.7FFF00' and `87F.000100'. The
internal emulation result is `001.000000' with flags `....x', and the
system result is the same but with flags `...ux'. All the items composed of
hexadecimal digits and a single period represent floating-point values (here
single precision). These cases were reported as errors because the flag
results differ.
In addition to the exception flags, there are seven data types that may
be represented. Four are floating-point types: single precision, double
precision, extended double precision, and quadruple precision. The
remaining three types are 32-bit and 64-bit two's-complement integers and
Boolean values (the results of comparison operations). Boolean values are
represented as a single character, either a `0' or a `1'. 32-bit integers
are written as 8 hexadecimal digits in two's-complement form. Thus,
`FFFFFFFF' is -1, and `7FFFFFFF' is the largest positive 32-bit integer.
64-bit integers are the same except with 16 hexadecimal digits.
Floating-point values are written in a correspondingly primitive form.
Double-precision values are represented by 16 hexadecimal digits that give
the raw bits of the floating-point encoding. A period separates the 3rd and
4th hexadecimal digits to mark the division between the exponent bits and
fraction bits. Some notable double-precision values include:
000.0000000000000 +0
3FF.0000000000000 1
400.0000000000000 2
7FF.0000000000000 +infinity
800.0000000000000 -0
BFF.0000000000000 -1
C00.0000000000000 -2
FFF.0000000000000 -infinity
3FE.FFFFFFFFFFFFF largest representable number preceding +1
The following categories are easily distinguished (assuming the `x's are not
all 0):
000.xxxxxxxxxxxxx positive subnormal (denormalized) numbers
7FF.xxxxxxxxxxxxx positive NaNs
800.xxxxxxxxxxxxx negative subnormal numbers
FFF.xxxxxxxxxxxxx negative NaNs
Quadruple-precision values are written the same except with 4 hexadecimal
digits for the sign and exponent and 28 for the fraction. Notable values
include:
0000.0000000000000000000000000000 +0
3FFF.0000000000000000000000000000 1
4000.0000000000000000000000000000 2
7FFF.0000000000000000000000000000 +infinity
8000.0000000000000000000000000000 -0
BFFF.0000000000000000000000000000 -1
C000.0000000000000000000000000000 -2
FFFF.0000000000000000000000000000 -infinity
3FFE.FFFFFFFFFFFFFFFFFFFFFFFFFFFF largest representable number
preceding +1
Extended double-precision values are a little unusual in that the leading
significand bit is not hidden as with other formats. When correctly
encoded, the leading significand bit of an extended double-precision value
will be 0 if the value is zero or subnormal, and will be 1 otherwise.
Hence, the same values listed above appear in extended double-precision as
follows (note the leading `8' digit in the significands):
0000.0000000000000000 +0
3FFF.8000000000000000 1
4000.8000000000000000 2
7FFF.8000000000000000 +infinity
8000.0000000000000000 -0
BFFF.8000000000000000 -1
C000.8000000000000000 -2
FFFF.8000000000000000 -infinity
3FFE.FFFFFFFFFFFFFFFF largest representable number preceding +1
The representation of single-precision values is unusual for a different
reason. Because the subfields of standard single-precision do not fall
on neat 4-bit boundaries, single-precision outputs are slightly perturbed.
These are written as 9 hexadecimal digits, with a period separating the 3rd
and 4th hexadecimal digits. Broken out into bits, the 9 hexademical digits
cover the single-precision subfields as follows:
x000 .... .... . .... .... .... .... .... .... sign (1 bit)
.... xxxx xxxx . .... .... .... .... .... .... exponent (8 bits)
.... .... .... . 0xxx xxxx xxxx xxxx xxxx xxxx fraction (23 bits)
As shown in this schematic, the first hexadecimal digit contains only
the sign, and will be either `0' or `8'. The next two digits give the
biased exponent as an 8-bit integer. This is followed by a period and
6 hexadecimal digits of fraction. The most significant hexadecimal digit
of the fraction can be at most a `7'.
Notable single-precision values include:
000.000000 +0
07F.000000 1
080.000000 2
0FF.000000 +infinity
800.000000 -0
87F.000000 -1
880.000000 -2
8FF.000000 -infinity
07E.7FFFFF largest representable number preceding +1
Again, certain categories are easily distinguished (assuming the `x's are
not all 0):
000.xxxxxx positive subnormal (denormalized) numbers
0FF.xxxxxx positive NaNs
800.xxxxxx negative subnormal numbers
8FF.xxxxxx negative NaNs
Lastly, exception flag values are represented by five characters, one
character per flag. Each flag is written as either a letter or a period
(`.') according to whether the flag was set or not by the operation. A
period indicates the flag was not set. The letter used to indicate a set
flag depends on the flag:
v invalid flag
z division-by-zero flag
o overflow flag
u underflow flag
x inexact flag
For example, the notation `...ux' indicates that the underflow and inexact
exception flags were set and that the other three flags (invalid, division-
by-zero, and overflow) were not set. The exception flags are always shown
following the value returned as the result of the operation.
The output from `testsoftfloat' is of the same form, except that the results
are labeled `true' and `soft':
<inputs> true: <simple-software-result> soft: <SoftFloat-result>
The ``true'' result is from the simpler, slower software floating-point,
which, although not necessarily correct, is more likely to be right than
the SoftFloat (`soft') result.
-------------------------------------------------------------------------------
Variations Allowed by the IEC/IEEE Standard
The IEC/IEEE Standard admits some variation among conforming
implementations. Because TestFloat expects the two implementations being
compared to deliver bit-for-bit identical results under most circumstances,
this leeway in the standard can result in false errors being reported if
the two implementations do not make the same choices everywhere the standard
provides an option.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Underflow
The standard specifies that the underflow exception flag is to be raised
when two conditions are met simultaneously: (1) _tininess_ and (2) _loss_
_of_accuracy_. A result is tiny when its magnitude is nonzero yet smaller
than any normalized floating-point number. The standard allows tininess to
be determined either before or after a result is rounded to the destination
precision. If tininess is detected before rounding, some borderline cases
will be flagged as underflows even though the result after rounding actually
lies within the normal floating-point range. By detecting tininess after
rounding, a system can avoid some unnecessary signaling of underflow.
Loss of accuracy occurs when the subnormal format is not sufficient
to represent an underflowed result accurately. The standard allows
loss of accuracy to be detected either as an _inexact_result_ or as a
_denormalization_loss_. If loss of accuracy is detected as an inexact
result, the underflow flag is raised whenever an underflowed quantity
cannot be exactly represented in the subnormal format (that is, whenever the
inexact flag is also raised). A denormalization loss, on the other hand,
occurs only when the subnormal format is not able to represent the result
that would have been returned if the destination format had infinite range.
Some underflowed results are inexact but do not suffer a denormalization
loss. By detecting loss of accuracy as a denormalization loss, a system can
once again avoid some unnecessary signaling of underflow.
The `-tininessbefore' and `-tininessafter' options can be used to control
whether TestFloat expects tininess on underflow to be detected before or
after rounding. (See _TestFloat_Options_ below.) One or the other is
selected as the default when TestFloat is compiled, but these command
options allow the default to be overridden.
Most (possibly all) systems detect loss of accuracy as an inexact result.
The current version of TestFloat can only test for this case.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NaNs
The IEC/IEEE Standard gives the floating-point formats a large number of
NaN encodings and specifies that NaNs are to be returned as results under
certain conditions. However, the standard allows an implementation almost
complete freedom over _which_ NaN to return in each situation.
By default, TestFloat does not check the bit patterns of NaN results. When
the result of an operation should be a NaN, any NaN is considered as good
as another. This laxness can be overridden with the `-checkNaNs' option.
(See _TestFloat_Options_ below.) In order for this option to be sensible,
TestFloat must have been compiled so that its internal floating-point
implementation (SoftFloat) generates the proper NaN results for the system
being tested.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Conversions to Integer
Conversion of a floating-point value to an integer format will fail if the
source value is a NaN or if it is too large. The IEC/IEEE Standard does not
specify what value should be returned as the integer result in these cases.
Moreover, according to the standard, the invalid exception can be raised or
an unspecified alternative mechanism may be used to signal such cases.
TestFloat assumes that conversions to integer will raise the invalid
exception if the source value cannot be rounded to a representable integer.
When the conversion overflows, TestFloat expects the largest integer with
the same sign as the operand to be returned. If the floating-point operand
is a NaN, TestFloat allows either the largest postive or largest negative
integer to be returned. The current version of TestFloat provides no means
to alter these conventions.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-------------------------------------------------------------------------------
TestFloat Options
The `testfloat' (and `testsoftfloat') program accepts several command
options. If mutually contradictory options are given, the last one has
priority.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-help
The `-help' option causes a summary of program usage to be written, after
which the program exits.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-list
The `-list' option causes a list of testable functions to be written,
after which the program exits. Some machines do not implement all of the
functions TestFloat can test, plus it may not be possible to test functions
that are inaccessible from the C language.
The `testsoftfloat' program does not have this option. All SoftFloat
functions can be tested by `testsoftfloat'.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-level <num>
The `-level' option sets the level of testing. The argument to `-level' can
be either 1 or 2. The default is level 1. Level 2 performs many more tests
than level 1. Testing at level 2 can take as much as a day (even longer for
`testsoftfloat'), but can reveal bugs not found by level 1.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-errors <num>
The `-errors' option instructs TestFloat to report no more than the
specified number of errors for any combination of function, rounding mode,
etc. The argument to `-errors' must be a nonnegative decimal number. Once
the specified number of error reports has been generated, TestFloat ends the
current test and begins the next one, if any. The default is `-errors 20'.
Against intuition, `-errors 0' causes TestFloat to report every error it
finds.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-errorstop
The `-errorstop' option causes the program to exit after the first function
for which any errors are reported.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-forever
The `-forever' option causes a single operation to be repeatedly tested.
Only one rounding mode and/or rounding precision can be tested in a single
invocation. If not specified, the rounding mode defaults to nearest/even.
For extended double-precision operations, the rounding precision defaults
to full extended double precision. The testing level is set to 2 by this
option.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-checkNaNs
The `-checkNaNs' option causes TestFloat to verify the bitwise correctness
of NaN results. In order for this option to be sensible, TestFloat must
have been compiled so that its internal floating-point implementation
(SoftFloat) generates the proper NaN results for the system being tested.
This option is not available to `testsoftfloat'.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-precision32, -precision64, -precision80
For extended double-precision functions affected by rounding precision
control, the `-precision32' option restricts testing to only the cases
in which rounding precision is equivalent to single precision. The other
rounding precision options are not tested. Likewise, the `-precision64'
and `-precision80' options fix the rounding precision equivalent to double
precision or extended double precision, respectively. These options are
ignored for functions not affected by rounding precision control.
These options are not available if extended double precision is not
supported by the machine or if extended double precision functions cannot be
tested.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-nearesteven, -tozero, -down, -up
The `-nearesteven' option restricts testing to only the cases in which the
rounding mode is nearest/even. The other rounding mode options are not
tested. Likewise, `-tozero' forces rounding to zero; `-down' forces
rounding down; and `-up' forces rounding up. These options are ignored for
functions that are exact and thus do not round.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-tininessbefore, -tininessafter
The `-tininessbefore' option indicates that the system detects tininess
on underflow before rounding. The `-tininessafter' option indicates that
tininess is detected after rounding. TestFloat alters its expectations
accordingly. These options override the default selected when TestFloat was
compiled. Choosing the wrong one of these two options should cause error
reports for some (not all) functions.
For `testsoftfloat', these options operate more like the rounding precision
and rounding mode options, in that they restrict the tests performed by
`testsoftfloat'. By default, `testsoftfloat' tests both cases for any
function for which there is a difference.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-------------------------------------------------------------------------------
Function Sets
Just as TestFloat can test an operation for all four rounding modes in
sequence, multiple operations can be tested with a single invocation of
TestFloat. Three sets are recognized: `-all1', `-all2', and `-all'. The
set `-all1' comprises all one-operand functions; `-all2' is all two-operand
functions; and `-all' is all functions. A function set can be used in place
of a function name in the TestFloat command line, such as
testfloat [<option>...] -all
-------------------------------------------------------------------------------
Contact Information
At the time of this writing, the most up-to-date information about
TestFloat and the latest release can be found at the Web page `http://
HTTP.CS.Berkeley.EDU/~jhauser/arithmetic/TestFloat.html'.