From cec54960bbbfa351cab7dab75eb1418585e4fe64 Mon Sep 17 00:00:00 2001 From: John Hauser Date: Wed, 17 Dec 2014 19:09:39 -0800 Subject: Finalized documentation for TestFloat Release 3. --- COPYING.txt | 2 +- README.html | 8 +- README.txt | 11 +- doc/TestFloat-general.html | 507 +++++++++++++++++++++++++++------------------ doc/TestFloat-history.html | 21 +- doc/TestFloat-source.html | 190 +++++++++-------- doc/testfloat.html | 32 ++- doc/testfloat_gen.html | 79 +++---- doc/testfloat_ver.html | 54 ++--- doc/testsoftfloat.html | 22 +- doc/timesoftfloat.html | 34 ++- 11 files changed, 527 insertions(+), 433 deletions(-) diff --git a/COPYING.txt b/COPYING.txt index c7d4700..335f14b 100644 --- a/COPYING.txt +++ b/COPYING.txt @@ -2,7 +2,7 @@ License for Berkeley TestFloat Release 3 John R. Hauser -2014 ________ +2014 Dec 17 The following applies to the whole of TestFloat Release 3 as well as to each source file individually. diff --git a/README.html b/README.html index 8831206..b89928f 100644 --- a/README.html +++ b/README.html @@ -11,14 +11,14 @@

John R. Hauser
-2014 ________
+2014 Dec 17

-Berkeley TestFloat is ___. -*** +Berkeley TestFloat is a small collection of programs for testing that an +implementation of binary floating-point conforms to the IEEE Standard for +Floating-Point Arithmetic. TestFloat is distributed in the form of C source code. -Building the TestFloat sources creates ___.

diff --git a/README.txt b/README.txt index 1f98497..e2ff85e 100644 --- a/README.txt +++ b/README.txt @@ -2,13 +2,12 @@ Package Overview for Berkeley TestFloat Release 3 John R. Hauser -2014 ________ +2014 Dec 17 -Berkeley TestFloat is ___. -*** -TestFloat -is distributed in the form of C source code. Building the TestFloat sources -creates ___. +Berkeley TestFloat is a small collection of programs for testing that an +implementation of binary floating-point conforms to the IEEE Standard for +Floating-Point Arithmetic. TestFloat is distributed in the form of C source +code. The TestFloat package is documented in the following files in the "doc" subdirectory: diff --git a/doc/TestFloat-general.html b/doc/TestFloat-general.html index 1618d4a..d72807e 100644 --- a/doc/TestFloat-general.html +++ b/doc/TestFloat-general.html @@ -11,49 +11,38 @@

John R. Hauser
-2014 ______
-

- -

-*** CONTENT DONE. -

- -

-*** REPLACE QUOTATION MARKS. -
-*** REPLACE APOSTROPHES. -
-*** REPLACE EM DASH. +2014 Dec 17

Contents

-

-*** CHECK.
-*** FIX FORMATTING. -

- -
-    Introduction
-    Limitations
-    Acknowledgments and License
-    What TestFloat Does
-    Executing TestFloat
-    Operations Tested by TestFloat
-        Conversion Operations
-        Basic Arithmetic Operations
-        Fused Multiply-Add Operations
-        Remainder Operations
-        Round-to-Integer Operations
-        Comparison Operations
-    Interpreting TestFloat Output
-    Variations Allowed by the IEEE Floating-Point Standard
-        Underflow
-        NaNs
-        Conversions to Integer
-    Contact Information
-
+
+ +++ + + + + + + + + + + + + + + + + + + + +
1. Introduction
2. Limitations
3. Acknowledgments and License
4. What TestFloat Does
5. Executing TestFloat
6. Operations Tested by TestFloat
6.1. Conversion Operations
6.2. Basic Arithmetic Operations
6.3. Fused Multiply-Add Operations
6.4. Remainder Operations
6.5. Round-to-Integer Operations
6.6. Comparison Operations
7. Interpreting TestFloat Output
8. Variations Allowed by the IEEE Floating-Point Standard
8.1. Underflow
8.2. NaNs
8.3. Conversions to Integer
9. Contact Information
+

1. Introduction

@@ -89,8 +78,8 @@ Details about the standard are available elsewhere.

The current version of TestFloat is Release 3. -The set of TestFloat programs as well as the programs' arguments and behavior -have changed some compared to earlier TestFloat releases. +The set of TestFloat programs as well as the programs’ arguments and +behavior have changed some compared to earlier TestFloat releases.

@@ -119,15 +108,20 @@ bugs can be found through links posted on the TestFloat Web page The TestFloat package was written by me, John R. Hauser. Release 3 of TestFloat is a completely new implementation supplanting earlier releases. -This project was done in the employ of the University of California, Berkeley, -within the Department of Electrical Engineering and Computer Sciences, first -for the Parallel Computing Laboratory (Par Lab) and then for the ASPIRE Lab. +This project (Release 3 only, not earlier releases) was done in +the employ of the University of California, Berkeley, within the Department of +Electrical Engineering and Computer Sciences, first for the Parallel Computing +Laboratory (Par Lab) and then for the ASPIRE Lab. The work was officially overseen by Prof. Krste Asanovic, with funding provided by these sources:
+++ - + + - + +
Par Lab:Par Lab: Microsoft (Award #024263), Intel (Award #024894), and U.C. Discovery (Award #DIG07-10227), with additional support from Par Lab affiliates Nokia, @@ -135,7 +129,8 @@ NVIDIA, Oracle, and Samsung.
ASPIRE Lab:ASPIRE Lab: DARPA PERFECT program (Award #HR0011-12-2-0016), with additional support from ASPIRE industrial sponsor Intel and ASPIRE affiliates Google, Nokia, NVIDIA, @@ -191,8 +186,8 @@ ENHANCEMENTS, OR MODIFICATIONS.

TestFloat is designed to test a floating-point implementation by comparing its -behavior with that of TestFloat's own internal floating-point implemented in -software. +behavior with that of TestFloat’s own internal floating-point implemented +in software. For each operation to be tested, the TestFloat programs can generate a large number of test cases, made up of simple pattern tests intermixed with weighted random inputs. @@ -263,19 +258,20 @@ for programs testfloat_ver and testfloat. TestFloat normally compares an implementation of floating-point against the Berkeley SoftFloat software implementation of floating-point, also created by me. -The SoftFloat functions are linked into each TestFloat program's executable. +The SoftFloat functions are linked into each TestFloat program’s +executable. Information about SoftFloat can be found at the Web page http://www.jhauser.us/arithmetic/SoftFloat.html.

For testing SoftFloat itself, the TestFloat package includes a -testsoftfloat program that compares SoftFloat's floating-point -against another software floating-point implementation. +testsoftfloat 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 low. +bug-free, the chance that it would mimic any of SoftFloat’s bugs is low. Consequently, an error in one or the other floating-point version should appear as an unexpected difference between the two implementations. Note that testing SoftFloat should be necessary only when compiling a new @@ -347,9 +343,11 @@ These results can then be piped to testfloat_ver to be checked for correctness. Assuming a vertical bar (|) indicates a pipe between programs, the complete process could be written as a single command like so: +

-     testfloat_gen ... <type> | <program-that-invokes-op> | testfloat_ver ... <function>
+testfloat_gen ... <type> | <program-that-invokes-op> | testfloat_ver ... <function>
+
The program in the middle is not supplied by TestFloat but must be created independently. If for some reason this program cannot take command-line arguments, the @@ -363,9 +361,11 @@ A second method for running TestFloat is similar but has expected results for each case. With this additional information, the job done by testfloat_ver can be folded into the invoking program to give the following command: +
-     testfloat_gen ... <function> | <program-that-invokes-op-and-compares-results>
+testfloat_gen ... <function> | <program-that-invokes-op-and-compares-results>
+
Again, the program that actually invokes the floating-point operation is not supplied by TestFloat but must be created independently. Depending on circumstance, it may be preferable either to let @@ -429,8 +429,8 @@ multiplication, division, and square root operations; for each format, the floating-point remainder operation defined by the IEEE Standard;
  • -for each format, a ``round to integer'' operation that rounds to the nearest -integer value in the same format; and +for each format, a “round to integer” operation that rounds to the +nearest integer value in the same format; and
  • comparisons between two values in the same floating-point format. @@ -451,8 +451,8 @@ is called f32, 64-bit double-precision is extF80, and 128-bit quadruple-precision is f128. TestFloat generally uses the same names for operations as Berkeley SoftFloat, -except that TestFloat's names never include the M that SoftFloat -uses to indicate that values are passed through pointers. +except that TestFloat’s names never include the M that +SoftFloat uses to indicate that values are passed through pointers.

    6.1. Conversion Operations

    @@ -462,21 +462,23 @@ All conversions among the floating-point formats and all conversions between a floating-point format and 32-bit and 64-bit integers can be tested. The conversion operations are: +
    -     ui32_to_f32      ui64_to_f32      i32_to_f32       i64_to_f32
-     ui32_to_f64      ui64_to_f64      i32_to_f64       i64_to_f64
-     ui32_to_extF80   ui64_to_extF80   i32_to_extF80    i64_to_extF80
-     ui32_to_f128     ui64_to_f128     i32_to_f128      i64_to_f128
-
-     f32_to_ui32      f64_to_ui32      extF80_to_ui32   f128_to_ui32
-     f32_to_ui64      f64_to_ui64      extF80_to_ui64   f128_to_ui64
-     f32_to_i32       f64_to_i32       extF80_to_i32    f128_to_i32
-     f32_to_i64       f64_to_i64       extF80_to_i64    f128_to_i64
-
-     f32_to_f64       f64_to_f32       extF80_to_f32    f128_to_f32
-     f32_to_extF80    f64_to_extF80    extF80_to_f64    f128_to_f64
-     f32_to_f128      f64_to_f128      extF80_to_f128   f128_to_extF80
+ui32_to_f32      ui64_to_f32      i32_to_f32       i64_to_f32
+ui32_to_f64      ui64_to_f64      i32_to_f64       i64_to_f64
+ui32_to_extF80   ui64_to_extF80   i32_to_extF80    i64_to_extF80
+ui32_to_f128     ui64_to_f128     i32_to_f128      i64_to_f128
+
+f32_to_ui32      f64_to_ui32      extF80_to_ui32   f128_to_ui32
+f32_to_ui64      f64_to_ui64      extF80_to_ui64   f128_to_ui64
+f32_to_i32       f64_to_i32       extF80_to_i32    f128_to_i32
+f32_to_i64       f64_to_i64       extF80_to_i64    f128_to_i64
+
+f32_to_f64       f64_to_f32       extF80_to_f32    f128_to_f32
+f32_to_extF80    f64_to_extF80    extF80_to_f64    f128_to_f64
+f32_to_f128      f64_to_f128      extF80_to_f128   f128_to_extF80
    +
    Abbreviations ui32 and ui64 indicate 32-bit and 64-bit unsigned integer types, while i32 and i64 indicate their signed counterparts. @@ -495,22 +497,27 @@ operations requires amendment. For testfloat only, conversions to an integer type have names that explicitly specify the rounding mode and treatment of inexactness. Thus, instead of +
    -     <float>_to_<int>
+<float>_to_<int>
    +
    as listed above, operations converting to integer type have names of these forms: +
    -     <float>_to_<int>_r_<round>
-     <float>_to_<int>_rx_<round>
+<float>_to_<int>_r_<round>
+<float>_to_<int>_rx_<round>
    -The <round> component is one of `near_even', -`near_maxMag', `minMag', `min', or -`max', choosing the rounding mode. +
    +The <round> component is one of +‘near_even’, ‘near_maxMag’, +‘minMag’, ‘min’, or +‘max’, choosing the rounding mode. Any other indication of rounding mode is ignored. -The operations with `_r_' in their names never raise the -inexact exception, while those with `_rx_' raise the -inexact exception whenever the result is not exact. +The operations with ‘_r_’ in their names never raise +the inexact exception, while those with ‘_rx_’ +raise the inexact exception whenever the result is not exact.

    @@ -518,7 +525,8 @@ TestFloat assumes that conversions from floating-point to an integer type should raise the invalid exception if the input cannot be rounded to an integer representable by the result format. In such a circumstance, if the result type is an unsigned integer, TestFloat -expects the result of the operation to be the type's largest integer value. +expects the result of the operation to be the type’s largest integer +value. If the result type is a signed integer and conversion overflows, TestFloat expects the result to be the largest-magnitude integer with the same sign as the input. @@ -533,12 +541,14 @@ exception.

    The following standard arithmetic operations can be tested: +

    -     f32_add      f32_sub      f32_mul      f32_div      f32_sqrt
-     f64_add      f64_sub      f64_mul      f64_div      f64_sqrt
-     extF80_add   extF80_sub   extF80_mul   extF80_div   extF80_sqrt
-     f128_add     f128_sub     f128_mul     f128_div     f128_sqrt
+f32_add      f32_sub      f32_mul      f32_div      f32_sqrt
+f64_add      f64_sub      f64_mul      f64_div      f64_sqrt
+extF80_add   extF80_sub   extF80_mul   extF80_div   extF80_sqrt
+f128_add     f128_sub     f128_mul     f128_div     f128_sqrt
    +
    The double-extended-precision (extF80) operations can be rounded to reduced precision under rounding precision control.

    @@ -550,11 +560,13 @@ For all floating-point formats except 80-bit double-extended-precision, TestFloat can test the fused multiply-add operation defined by the 2008 IEEE Floating-Point Standard. The fused multiply-add operations are: +
    -     f32_mulAdd
-     f64_mulAdd
-     f128_mulAdd
+f32_mulAdd
+f64_mulAdd
+f128_mulAdd
    +

    @@ -566,29 +578,34 @@ exception even if the third operand is a NaN.

    6.4. Remainder Operations

    -For each format, TestFloat can test the IEEE Standard's remainder operation. +For each format, TestFloat can test the IEEE Standard’s remainder +operation. These operations are: +

    -     f32_rem
-     f64_rem
-     extF80_rem
-     f128_rem
+f32_rem
+f64_rem
+extF80_rem
+f128_rem
    +
    The remainder operations are always exact and so require no rounding.

    6.5. Round-to-Integer Operations

    -For each format, TestFloat can test the IEEE Standard's round-to-integer +For each format, TestFloat can test the IEEE Standard’s round-to-integer operation. For most TestFloat programs, these operations are: +

    -     f32_roundToInt
-     f64_roundToInt
-     extF80_roundToInt
-     f128_roundToInt
+f32_roundToInt
+f64_roundToInt
+extF80_roundToInt
+f128_roundToInt
    +

    @@ -596,35 +613,40 @@ Just as for conversions to integer types (section 6.1 above), the all-in-one testfloat program is again an exception. For testfloat only, the round-to-integer operations have names of these forms: +

    -     <float>_roundToInt_r_<round>
-     <float>_roundToInt_x
+<float>_roundToInt_r_<round>
+<float>_roundToInt_x
    -For the `_r_' versions, the inexact exception is never -raised, and the <round> component specifies the rounding -mode as one of `near_even', `near_maxMag', -`minMag', `min', or `max'. +
    +For the ‘_r_’ versions, the inexact exception +is never raised, and the <round> component specifies the +rounding mode as one of ‘near_even’, +‘near_maxMag’, ‘minMag’, +‘min’, or ‘max’. The usual indication of rounding mode is ignored. -In contrast, the `_x' versions accept the usual indication of -rounding mode and raise the inexact exception whenever the result is not -exact. -This irregular system follows the IEEE Standard's precise specification for the -round-to-integer operations. +In contrast, the ‘_x’ versions accept the usual +indication of rounding mode and raise the inexact exception whenever the +result is not exact. +This irregular system follows the IEEE Standard’s precise specification +for the round-to-integer operations.

    6.6. Comparison Operations

    The following floating-point comparison operations can be tested: +

    -     f32_eq      f32_le      f32_lt
-     f64_eq      f64_le      f64_lt
-     extF80_eq   extF80_le   extF80_lt
-     f128_eq     f128_le     f128_lt
+f32_eq      f32_le      f32_lt
+f64_eq      f64_le      f64_lt
+extF80_eq   extF80_le   extF80_lt
+f128_eq     f128_le     f128_lt
    -The abbreviation eq stands for ``equal'' (=), le -stands for ``less than or equal'' (≤), and lt stands for -``less than'' (<). +
    +The abbreviation eq stands for “equal” (=), +le stands for “less than or equal” (≤), and +lt stands for “less than” (<).

    @@ -635,12 +657,14 @@ The equality comparisons, on the other hand, are defined by default to raise the invalid exception only for signaling NaNs, not for quiet NaNs. For completeness, the following additional operations can be tested if supported: +

    -     f32_eq_signaling      f32_le_quiet      f32_lt_quiet
-     f64_eq_signaling      f64_le_quiet      f64_lt_quiet
-     extF80_eq_signaling   extF80_le_quiet   extF80_lt_quiet
-     f128_eq_signaling     f128_le_quiet     f128_lt_quiet
+f32_eq_signaling      f32_le_quiet      f32_lt_quiet
+f64_eq_signaling      f64_le_quiet      f64_lt_quiet
+extF80_eq_signaling   extF80_le_quiet   extF80_lt_quiet
+f128_eq_signaling     f128_le_quiet     f128_lt_quiet
    +
    The signaling equality comparisons are identical to the standard operations except that the invalid exception should be raised for any NaN input. @@ -658,8 +682,8 @@ Any rounding mode is ignored.

    7. Interpreting TestFloat Output

    -The ``errors'' reported by TestFloat programs may or may not really represent -errors in the system being tested. +The “errors” reported by TestFloat programs may or may not really +represent errors in the system being tested. For each test case tried, the results from the floating-point implementation being tested could differ from the expected results for several reasons:

      @@ -694,14 +718,16 @@ For each reported error (or apparent error), 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. +subsequent “continuation” lines are indented with a tab.

      Each error reported is of the form: +

      -     <inputs>  => <observed-output>  expected: <expected-output>
+<inputs>  => <observed-output>  expected: <expected-output>
      +
      The <inputs> are the inputs to the operation. Each output (observed and expected) is shown as a pair: the result value first, followed by the exception flags. @@ -709,10 +735,12 @@ first, followed by the exception flags.

      For example, two typical error lines could be +

      -     800.7FFF00  87F.000100  => 001.000000 ...ux  expected: 001.000000 ....x
-     081.000004  000.1FFFFF  => 001.000000 ...ux  expected: 001.000000 ....x
+800.7FFF00  87F.000100  => 001.000000 ...ux  expected: 001.000000 ....x
+081.000004  000.1FFFFF  => 001.000000 ...ux  expected: 001.000000 ....x
      +
      In the first line, the inputs are 800.7FFF00 and 87F.000100, and the observed result is 001.000000 with flags ...ux. @@ -732,8 +760,9 @@ Four are floating-point types: 32-bit single-precision, 64-bit double-precision, 80-bit double-extended-precision, and 128-bit quadruple-precision. The remaining five types are 32-bit and 64-bit -unsigned integers, 32-bit and 64-bit two's-complement -signed integers, and Boolean values (the results of comparison operations). +unsigned integers, 32-bit and 64-bit +two’s-complement signed 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 represented as 8 hexadecimal digits. @@ -749,47 +778,93 @@ 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 64-bit 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 less than +1
-
      +
      + + + + + + + + + + + + + + + + + + +
      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.FFFFFFFFFFFFFlargest representable number less than +1
      +
      The following categories are easily distinguished (assuming the xs are not all 0): -
      -     000.xxxxxxxxxxxxx    positive subnormal (denormalized) numbers
-     7FF.xxxxxxxxxxxxx    positive NaNs
-     800.xxxxxxxxxxxxx    negative subnormal numbers
-     FFF.xxxxxxxxxxxxx    negative NaNs
-
      +
      + + + + + + + + + + + +
      000.xxxxxxxxxxxxx    positive subnormal (denormalized) numbers
      7FF.xxxxxxxxxxxxxpositive NaNs
      800.xxxxxxxxxxxxxnegative subnormal numbers
      FFF.xxxxxxxxxxxxxnegative NaNs
      +

      128-bit 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
-                                              less than +1
-
      +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      + 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.FFFFFFFFFFFFFFFFFFFFFFFFFFFFlargest representable number less than +1
      +

      @@ -801,19 +876,27 @@ and will be 1 otherwise. Hence, the same values listed above appear in 80-bit double-extended-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 less than +1
-
      +
      + + + + + + + + + + + + + + + + + + +
      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.FFFFFFFFFFFFFFFFlargest representable number less than +1
      +

      @@ -826,11 +909,13 @@ 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 32-bit single-precision subfields as follows: +

      -     x000 .... ....  .  .... .... .... .... .... ....    sign       (1 bit)
-     .... xxxx xxxx  .  .... .... .... .... .... ....    exponent   (8 bits)
-     .... .... ....  .  0xxx xxxx xxxx xxxx xxxx xxxx    fraction  (23 bits)
+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. @@ -841,27 +926,37 @@ The most significant hexadecimal digit of the fraction can be at most

      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 less than +1
-
      +
      + + + + + + + + + + + + + + + +
      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.7FFFFFlargest representable number less than +1
      +
      Again, certain categories are easily distinguished (assuming the xs are not all 0): -
      -     000.xxxxxx    positive subnormal (denormalized) numbers
-     0FF.xxxxxx    positive NaNs
-     800.xxxxxx    negative subnormal numbers
-     8FF.xxxxxx    negative NaNs
-
      +
      + + + + + + + + +
      000.xxxxxx    positive subnormal (denormalized) numbers
      0FF.xxxxxxpositive NaNs
      800.xxxxxxnegative subnormal numbers
      8FF.xxxxxxnegative NaNs
      +

      @@ -871,13 +966,21 @@ 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 exception
-     i    infinite exception ("divide by zero")
-     o    overflow exception
-     u    underflow exception
-     x    inexact exception
-
      +
      + + + + + + + + + + + + +
      v    invalid exception
      iinfinite exception (“divide by zero”)
      ooverflow exception
      uunderflow exception
      xinexact exception
      +
      For example, the notation ...ux indicates that the underflow and inexact exception flags were set and that the other three flags (invalid, infinite, and overflow) were not diff --git a/doc/TestFloat-history.html b/doc/TestFloat-history.html index daed701..3b9b833 100644 --- a/doc/TestFloat-history.html +++ b/doc/TestFloat-history.html @@ -11,16 +11,9 @@

      John R. Hauser
      -2014 _____
      +2014 Dec 17

      -

      -*** CONTENT DONE. -

      - -

      -*** REPLACE QUOTATION MARKS. -

      Releases of Berkeley TestFloat parallel those of Berkeley SoftFloat, on which @@ -35,7 +28,8 @@ corresponding release of SoftFloat.

      • -Complete rewrite, funded by the University of California, Berkeley. +Complete rewrite, funded by the University of California, Berkeley, and +consequently having a different use license than earlier releases. Visible changes included different names for testable functions and options.
      • @@ -68,8 +62,8 @@ package).
        • -Improved wording for the legal restrictions on using TestFloat releases -through 2c. +Improved the wording for the legal restrictions on using TestFloat releases +through 2c (not applicable to Release 3 or later).
        @@ -121,7 +115,7 @@ random bits for the entire machine word width.)
      • Created testsoftfloat, with its own simpler complete software -floating-point (``slowfloat'') for comparison purposes. +floating-point (“slowfloat”) for comparison purposes.
      • Made some changes to the source file structure, including renaming @@ -147,7 +141,8 @@ to control whether tininess should be detected before or after rounding.
        • -Original release. +Original release, based on work done for the International Computer Science +Institute (ICSI) in Berkeley, California.
        diff --git a/doc/TestFloat-source.html b/doc/TestFloat-source.html index 9c42e59..6851036 100644 --- a/doc/TestFloat-source.html +++ b/doc/TestFloat-source.html @@ -11,38 +11,33 @@

        John R. Hauser
        -2014 _____
        -

        - -

        -*** CONTENT DONE. -

        - -

        -*** REPLACE QUOTATION MARKS. +2014 Dec 17

        Contents

        -

        -*** CHECK.
        -*** FIX FORMATTING. -

        -
        -1. Introduction
        -2. Limitations
        -3. Acknowledgments and License
        -4. TestFloat Package Directory Structure
        -5. Dependence on Berkeley SoftFloat
        -6. Issues for Porting TestFloat to a New Target
        -    6.1. Standard Headers <stdbool.h> and <stdint.h>
        -    6.2. Standard Header <fenv.h>
        -    6.3. Macros for Build Options
        -    6.4. Specializing the testfloat Program
        -    6.5. Improving the Random Number Functions
        -7. Contact Information
        + +++ + + + + + + + + + + + + + + +
        1. Introduction
        2. Limitations
        3. Acknowledgments and License
        4. TestFloat Package Directory Structure
        5. Dependence on Berkeley SoftFloat
        6. Issues for Porting TestFloat to a New Target
        6.1. Standard Headers <stdbool.h> and + <stdint.h>
        6.2. Standard Header <fenv.h>
        6.3. Macros for Build Options
        6.4. Specializing the testfloat Program
        6.5. Improving the Random Number Functions
        7. Contact Information
        @@ -112,7 +107,7 @@ strictly required. integer types. If these headers are not supplied with the C compiler, minimal substitutes must be provided. -TestFloat's dependence on these headers is detailed later in +TestFloat’s dependence on these headers is detailed later in section 6.1, Standard Headers <stdbool.h> and <stdint.h>.

        @@ -124,15 +119,20 @@ and <stdint.h>. The TestFloat package was written by me, John R. Hauser. Release 3 of TestFloat is a completely new implementation supplanting earlier releases. -This project was done in the employ of the University of California, Berkeley, -within the Department of Electrical Engineering and Computer Sciences, first -for the Parallel Computing Laboratory (Par Lab) and then for the ASPIRE Lab. +This project (Release 3 only, not earlier releases) was done in +the employ of the University of California, Berkeley, within the Department of +Electrical Engineering and Computer Sciences, first for the Parallel Computing +Laboratory (Par Lab) and then for the ASPIRE Lab. The work was officially overseen by Prof. Krste Asanovic, with funding provided by these sources:
        +++ - + + - + +
        Par Lab:Par Lab: Microsoft (Award #024263), Intel (Award #024894), and U.C. Discovery (Award #DIG07-10227), with additional support from Par Lab affiliates Nokia, @@ -140,7 +140,8 @@ NVIDIA, Oracle, and Samsung.
        ASPIRE Lab:ASPIRE Lab: DARPA PERFECT program (Award #HR0011-12-2-0016), with additional support from ASPIRE industrial sponsor Intel and ASPIRE affiliates Google, Nokia, NVIDIA, @@ -199,26 +200,30 @@ Because TestFloat is targeted to multiple platforms, its source code is slightly scattered between target-specific and target-independent directories and files. The supplied directory structure is as follows: +
        -     doc
-     source
-         subj-C
-     build
-         template
-         Linux-386-GCC
-         Linux-x86_64-GCC
-         Win32-MinGW
-         Win64-MinGW-w64
+doc
+source
+    subj-C
+build
+    template
+    Linux-386-GCC
+    Linux-386-SSE2-GCC
+    Linux-x86_64-GCC
+    Win32-MinGW
+    Win32-SSE2-MinGW
+    Win64-MinGW-w64
        +
        The majority of the TestFloat sources are provided in the source directory. The subj-C subdirectory contains the sources that configure the all-in-one testfloat program to test the C -compiler's implementation of the standard C types float, +compiler’s implementation of the standard C types float, double, and possibly long double. -The `subj' in subj-C is an abbreviation -of subject, referring to the floating-point that is the subject of the -test. +The ‘subj’ in subj-C is an +abbreviation of subject, referring to the floating-point that is the +subject of the test. If testfloat is retargeted to test other floating-point implementations, the corresponding source files would be expected to be in other subdirectories alongside subj-C, with names of @@ -231,8 +236,8 @@ Program.

        The build directory is intended to contain a subdirectory for each target platform for which builds of the TestFloat programs may be created. -For each build target, the target's subdirectory is where all derived object -files and the completed TestFloat executables are created. +For each build target, the target’s subdirectory is where all derived +object files and the completed TestFloat executables are created. The template subdirectory is not an actual build target but contains sample files for creating new target directories.

        @@ -243,18 +248,21 @@ are intended to follow a naming system of <execution-environment>-<compiler>. For the example targets, <execution-environment> is -Linux-386, Linux-x86_64, -Win32, or Win64, and +Linux-386, Linux-386-SSE2, +Linux-x86_64, Win32, +Win32-SSE2, or Win64, and <compiler> is GCC, MinGW, or MinGW-w64.

        As supplied, each target directory contains two files: +

        -     Makefile
-     platform.h
+Makefile
+platform.h
        +
        The provided Makefile is written for GNU make. A build of TestFloat for the specific target is begun by executing the make command with the target directory as the current directory. @@ -269,9 +277,10 @@ Every C source file of TestFloat contains a #include for platform.h. In many cases, the contents of platform.h can be as simple as one or two lines of code. -If the target's compiler or library has bugs or other shortcomings, workarounds -for these issues may be possible with target-specific declarations in -platform.h, without the need to modify the main TestFloat sources. +If the target’s compiler or library has bugs or other shortcomings, +workarounds for these issues may be possible with target-specific declarations +in platform.h, without the need to modify the main TestFloat +sources.

        @@ -310,8 +319,8 @@ clients. This list must include softfloat.h and may also include other header files referenced by softfloat.h, such as softfloat_types.h. This macro is used only to establish build dependencies between the SoftFloat -header files and TestFloat's source files, in case the SoftFloat header files -are changed. +header files and TestFloat’s source files, in case the SoftFloat header +files are changed.

        SOFTFLOAT_LIB
        The full path of the compiled SoftFloat library (usually @@ -336,29 +345,33 @@ For older or nonstandard compilers, substitutes for <stdbool.h> and <stdint.h> may need to be created. TestFloat depends on these names from <stdbool.h>: +
        -     bool
-     true
-     false
+bool
+true
+false
        +
        and on these names from <stdint.h>: +
        -     uint16_t
-     uint32_t
-     uint64_t
-     int32_t
-     int64_t
-     UINT64_C
-     INT64_C
-     uint_least8_t
-     uint_fast8_t
-     uint_fast16_t
-     uint_fast32_t
-     uint_fast64_t
-     int_fast16_t
-     int_fast32_t
-     int_fast64_t
+uint16_t
+uint32_t
+uint64_t
+int32_t
+int64_t
+UINT64_C
+INT64_C
+uint_least8_t
+uint_fast8_t
+uint_fast16_t
+uint_fast32_t
+uint_fast64_t
+int_fast16_t
+int_fast32_t
+int_fast64_t
        +

        @@ -408,18 +421,18 @@ Must be defined if the TestFloat programs are to support the 128-bit quadruple-precision floating-point format. -Following the usual custom for C, the content of a macro's +Following the usual custom for C, the content of a macro’s definition is irrelevant; -what matters is a macro's effect on #ifdef directives. +what matters is a macro’s effect on #ifdef directives.

        It is recommended that any definition of macro LITTLEENDIAN be -made in a build target's platform.h header file, because +made in a build target’s platform.h header file, because endianness is expected to be determined inflexibly by the target machine. On the other hand, the EXTFLOAT80 and FLOAT128 macros are not dictated by the target and hence might be better located in the -target's Makefile (or its equivalent). +target’s Makefile (or its equivalent).

        @@ -427,7 +440,7 @@ target's Makefile (or its equivalent).

        The supplied sources for the all-in-one testfloat program cause -testfloat to test the C compiler's float and +testfloat to test the C compiler’s float and double types for C operations +, -, *, /, etc. The supplied version is also capable of testing C type long @@ -445,7 +458,7 @@ Indicates that type long double is 128-bit quadruple-precision floating-point. -By default, testfloat assumes that only the IEEE Standard's +By default, testfloat assumes that only the IEEE Standard’s original four rounding modes (near_even, minMag, min, and max) are supported by the floating-point being tested. @@ -464,15 +477,18 @@ Indicates that the subject floating-point supports rounding mode

        To test a new and/or different implementation of floating-point, testfloat must normally be retargeted to invoke this other -floating-point instead of C's floating-point. +floating-point instead of C’s floating-point. Two source files define the functions that testfloat uses to invoke floating-point operations for testing: +

        -     subjfloat_config.h
-     subjfloat.c
+subjfloat_config.h
+subjfloat.c
        -For the default target of testing C's floating-point, these files are contained -in directory source/subj-C as discussed earlier. +
        +For the default target of testing C’s floating-point, these files are +contained in directory source/subj-C as discussed +earlier. For a different subject floating-point, it is recommended that appropriate versions of subjfloat_config.h and subjfloat.c be stored in a sibling subj-<target> directory, @@ -531,8 +547,8 @@ UNIX-derived systems), TestFloat can be improved by overriding the given

        Rather than modifying the supplied file random.c, it is -recommended instead that a new, alternate file be created and the target's -Makefile be modified to refer to that alternate file in place of +recommended instead that a new, alternate file be created and the +target’s Makefile be modified to refer to that alternate file in place of random.c.

        diff --git a/doc/testfloat.html b/doc/testfloat.html index 7779214..4460651 100644 --- a/doc/testfloat.html +++ b/doc/testfloat.html @@ -11,19 +11,7 @@

        John R. Hauser
        -2014 ______
        -

        - -

        -*** CONTENT DONE. -

        - -

        -*** REPLACE QUOTATION MARKS. -
        -*** REPLACE APOSTROPHES. -
        -*** REPLACE EM DASH. +2014 Dec 17

        @@ -49,7 +37,7 @@ While the processes of generating inputs and examining results are generic, a particular build of testfloat is limited to testing only the one implementation of floating-point it has been compiled to invoke. For example, while one instance of testfloat might be compiled to -execute a computer's hardware instruction for floating-point addition, a +execute a computer’s hardware instruction for floating-point addition, a different version might be compiled to call a subroutine called myAddFloat that is linked into the testfloat program. To test a new implementation of floating-point (a new set of machine @@ -65,16 +53,16 @@ Standard, and tests the C operations of +, -, *, /, type conversions, etc. This tests the floating-point arithmetic seen by C programs. Depending on the compiler and the options selected during compilation, this may -or may not be the same as the computer's floating-point hardware, if any. +or may not be the same as the computer’s floating-point hardware, if any.

        The testfloat program will ordinarily test an operation for all rounding modes defined by the IEEE Floating-Point Standard, 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. +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 double-extended-precision operations affected by rounding precision control, testfloat also tests all three rounding precision modes, one after the other. @@ -93,9 +81,11 @@ output, refer to

        The testfloat program is executed as a command with this syntax: +

        -     testfloat [<option>...] <function>
+testfloat [<option>...] <function>
        +
        Square brackets ([ ]) denote optional arguments, <option> is a supported option, and <function> is the name of either a testable operation or a @@ -249,9 +239,11 @@ The set -all1 comprises all one-operand operations, while -all2 is all two-operand operations. A function set is used in place of an operation name in the testfloat command line, such as +
        -     testfloat [<option>...] -all1
+testfloat [<option>...] -all1
        +

        diff --git a/doc/testfloat_gen.html b/doc/testfloat_gen.html index 43e6d20..3cbdf9a 100644 --- a/doc/testfloat_gen.html +++ b/doc/testfloat_gen.html @@ -11,19 +11,7 @@

        John R. Hauser
        -2014 ______
        -

        - -

        -*** CONTENT DONE. -

        - -

        -*** REPLACE QUOTATION MARKS. -
        -*** REPLACE APOSTROPHES. -
        -*** REPLACE EM DASH. +2014 Dec 17

        @@ -55,8 +43,8 @@ cases as they are supplied. Depending on use, the total output from testfloat_gen can be large, so piping to another program may be the best choice to avoid consuming inordinate file space. -The format of testfloat_gen's output is raw hexadecimal text, -described in the section below titled Output Format. +The format of testfloat_gen’s output is raw hexadecimal +text, described in the section below titled Output Format.

        @@ -65,10 +53,12 @@ described in the section below titled Output Format.

        The testfloat_gen program is executed as a command in one of these forms: +

        -     testfloat_gen [<option>...] <type>
-     testfloat_gen [<option>...] <function>
+testfloat_gen [<option>...] <type>
+testfloat_gen [<option>...] <function>
        +
        Square brackets ([ ]) denote optional arguments, and <option> is a supported option, documented below. A testfloat_gen command expects either a <type> @@ -81,7 +71,7 @@ usage is written.

        A <type> can be one of the following:

        - +
        @@ -139,7 +129,8 @@ If a <function> operation name is given, then each line of output from testfloat_gen contains not only the operands for that operation (as would be generated by an appropriate <type> argument) but also the expected results as determined by -testfloat_gen's internal floating-point emulation (SoftFloat). +testfloat_gen’s internal floating-point emulation +(SoftFloat). The available operation names are listed in TestFloat-general.html. In all cases, floating-point operations have two results: @@ -283,17 +274,21 @@ integer value or one, two, or three floating-point values. Each value is written to output as a raw hexadecimal number. When there is more than one value per line, they are separated by spaces. For example, output from executing +
        -     testfloat_gen f64 2
+testfloat_gen f64 2
        +
        might look like this: +
        -     3F90EB5825D6851E C3E0080080000000
-     41E3C00000000000 C182024F8AE474A8
-     7FD80FFFFFFFFFFF 7FEFFFFFFFFFFF80
-     3FFFED6A25C534BE 3CA1000000020000
-     ...
+3F90EB5825D6851E C3E0080080000000
+41E3C00000000000 C182024F8AE474A8
+7FD80FFFFFFFFFFF 7FEFFFFFFFFFFF80
+3FFFED6A25C534BE 3CA1000000020000
+...
        +
        with each hexadecimal number being one 64-bit floating-point value. Note that, for floating-point values, the sign and exponent are at the @@ -310,28 +305,38 @@ operation name, each line of output has not only the operands for the operation but also the expected output, consisting of a result value and the exception flags that are raised. For example, the output from +
        -     testfloat_gen f64_add
+testfloat_gen f64_add
        +
        could include these lines: +
        -     3F90EB5825D6851E C3E0080080000000 C3E0080080000000 01
-     41E3C00000000000 C182024F8AE474A8 41E377F6C1D46E2D 01
-     7FD80FFFFFFFFFFF 7FEFFFFFFFFFFF80 7FF0000000000000 05
-     3FFFED6A25C534BE 3CA1000000020000 3FFFED6A25C534BF 01
-     ...
+3F90EB5825D6851E C3E0080080000000 C3E0080080000000 01
+41E3C00000000000 C182024F8AE474A8 41E377F6C1D46E2D 01
+7FD80FFFFFFFFFFF 7FEFFFFFFFFFFF80 7FF0000000000000 05
+3FFFED6A25C534BE 3CA1000000020000 3FFFED6A25C534BF 01
+...
        +
        On each line, the first two numbers are the operands for the floating-point addition, and the third and fourth numbers are the expected floating-point result (the sum) and the exception flags raised. Exception flags are encoded with one bit per flag as follows:
        -
        ui32 unsigned 32-bit integers
        - - - - - +
        bit 0   inexact exception
        bit 1 underflow exception
        bit 2 overflow exception
        bit 3 infinite exception ("divide by zero")
        bit 4 invalid exception
        + + + + + + + + + + +
        bit 0   inexact exception
        bit 1underflow exception
        bit 2overflow exception
        bit 3infinite exception (“divide by zero”)
        bit 4invalid exception

        diff --git a/doc/testfloat_ver.html b/doc/testfloat_ver.html index 4d1540e..2e7e3fe 100644 --- a/doc/testfloat_ver.html +++ b/doc/testfloat_ver.html @@ -11,19 +11,7 @@

        John R. Hauser
        -2014 ______
        -

        - -

        -*** CONTENT DONE. -

        - -

        -*** REPLACE QUOTATION MARKS. -
        -*** REPLACE APOSTROPHES. -
        -*** REPLACE EM DASH. +2014 Dec 17

        @@ -52,7 +40,7 @@ The test cases to be verified are read by testfloat_ver from standard input. This input will typically be piped from another program that, for each test case, invokes the floating-point operation and writes out the results. -The format of testfloat_ver's input is raw hexadecimal text, +The format of testfloat_ver’s input is raw hexadecimal text, described in the section below titled Input Format.

        @@ -71,9 +59,11 @@ its output, refer to

        The testfloat_ver program is executed as a command with this syntax: +

        -     testfloat_ver [<option>...] <function>
+testfloat_ver [<option>...] <function>
        +
        Square brackets ([ ]) denote optional arguments, <option> is a supported option, and <function> is the name of a testable operation. @@ -205,17 +195,21 @@ the exception flags that were raised. These values are all expected to be provided as raw hexadecimal numbers separated on the line by spaces. For example, for the command +
        -     testfloat_ver f64_add
+testfloat_ver f64_add
        +
        valid input could include these lines: +
        -     3F90EB5825D6851E C3E0080080000000 C3E0080080000000 01
-     41E3C00000000000 C182024F8AE474A8 41E377F6C1D46E2D 01
-     7FD80FFFFFFFFFFF 7FEFFFFFFFFFFF80 7FF0000000000000 05
-     3FFFED6A25C534BE 3CA1000000020000 3FFFED6A25C534BF 01
-     ...
+3F90EB5825D6851E C3E0080080000000 C3E0080080000000 01
+41E3C00000000000 C182024F8AE474A8 41E377F6C1D46E2D 01
+7FD80FFFFFFFFFFF 7FEFFFFFFFFFFF80 7FF0000000000000 05
+3FFFED6A25C534BE 3CA1000000020000 3FFFED6A25C534BF 01
+...
        +
        On each line above, the first two hexadecimal numbers represent the 64-bit floating-point operands, the third hexadecimal number is the 64-bit floating-point result of the operation (the sum), and @@ -235,12 +229,18 @@ encoded significand.

        Exception flags are encoded with one bit per flag as follows:

        - - - - - - +
        bit 0   inexact exception
        bit 1 underflow exception
        bit 2 overflow exception
        bit 3 infinite exception ("divide by zero")
        bit 4 invalid exception
        + + + + + + + + + + +
        bit 0   inexact exception
        bit 1underflow exception
        bit 2overflow exception
        bit 3infinite exception (“divide by zero”)
        bit 4invalid exception

        diff --git a/doc/testsoftfloat.html b/doc/testsoftfloat.html index 49215de..306f221 100644 --- a/doc/testsoftfloat.html +++ b/doc/testsoftfloat.html @@ -11,19 +11,7 @@

        John R. Hauser
        -2014 ______
        -

        - -

        -*** CONTENT DONE. -

        - -

        -*** REPLACE QUOTATION MARKS. -
        -*** REPLACE APOSTROPHES. -
        -*** REPLACE EM DASH. +2014 Dec 17

        @@ -70,9 +58,11 @@ and/or a single rounding precision with appropriate command-line options.

        The testsoftfloat program is executed as a command with this syntax: +

        -     testsoftfloat [<option>...] <function>
+testsoftfloat [<option>...] <function>
        +
        Square brackets ([ ]) denote optional arguments, <option> is a supported option, and <function> is the name of either a testable function or a @@ -208,9 +198,11 @@ The set -all1 comprises all one-operand operations, while -all2 is all two-operand operations. A function set is used in place of a function name in the testsoftfloat command line, such as +
        -     testsoftfloat [<option>...] -all1
+testsoftfloat [<option>...] -all1
        +

        diff --git a/doc/timesoftfloat.html b/doc/timesoftfloat.html index b214611..bb4e947 100644 --- a/doc/timesoftfloat.html +++ b/doc/timesoftfloat.html @@ -11,19 +11,7 @@

        John R. Hauser
        -2014 ______
        -

        - -

        -*** CONTENT DONE. -

        - -

        -*** REPLACE QUOTATION MARKS. -
        -*** REPLACE APOSTROPHES. -
        -*** REPLACE EM DASH. +2014 Dec 17

        @@ -38,14 +26,14 @@ floating-point conforms to the IEEE Standard for Binary Floating-Point Arithmetic. Although timesoftfloat does not test floating-point correctness like other TestFloat programs, nevertheless timesoftfloat is a -partner to TestFloat's testsoftfloat program. +partner to TestFloat’s testsoftfloat program. For more about TestFloat generally and testsoftfloat specifically, see file TestFloat-general.html.

        -Ordinarily, timesoftfloat will measure a function's speed +Ordinarily, timesoftfloat will measure a function’s speed separately for each rounding mode defined by the IEEE Floating-Point Standard, one after the other. If an operation is not supposed to require rounding, it will by default be @@ -63,13 +51,13 @@ options.

        For each function and mode evaluated, timesoftfloat reports the -measured speed of the function in Mops/s, or ``millions of operations per -second''. +measured speed of the function in Mop/s, or “millions of operations per +second”. The speeds reported by timesoftfloat may be affected somewhat by other software executing at the same time as timesoftfloat. Be aware also that the exact execution time of any SoftFloat function depends -partly on the values of arguments and the state of the processor's caches at -the time the function is called. +partly on the values of arguments and the state of the processor’s caches +at the time the function is called. Your actual experience with SoftFloat may differ from the speeds reported by timesoftfloat for all these reasons.

        @@ -89,9 +77,11 @@ SoftFloat implementation.

        The timesoftfloat program is executed as a command with this syntax: +

        -     timesoftfloat [<option>...] <function>
+timesoftfloat [<option>...] <function>
        +
        Square brackets ([ ]) denote optional arguments, <option> is a supported option, and <function> is the name of either a testable function or a @@ -181,9 +171,11 @@ The set -all1 comprises all one-operand operations, obviously all operations. A function set is used in place of a function name in the timesoftfloat command line, such as +
        -     timesoftfloat [<option>...] -all1
+timesoftfloat [<option>...] -all1
        +

        -- cgit v1.1