From f215e02bf85f68d3a6106c2a1f4f7f063f819064 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Thu, 11 Apr 2024 10:17:27 +0200 Subject: Adding upstream version 7.0.14-dfsg. Signed-off-by: Daniel Baumann --- .../testfloat/doc/TestFloat-general.html | 1148 ++++++++++++++++++++ .../testfloat/doc/TestFloat-history.html | 272 +++++ .../testfloat/doc/TestFloat-source.html | 639 +++++++++++ src/libs/softfloat-3e/testfloat/doc/testfloat.html | 286 +++++ .../softfloat-3e/testfloat/doc/testfloat_gen.html | 367 +++++++ .../softfloat-3e/testfloat/doc/testfloat_ver.html | 270 +++++ .../softfloat-3e/testfloat/doc/testsoftfloat.html | 236 ++++ .../softfloat-3e/testfloat/doc/timesoftfloat.html | 196 ++++ 8 files changed, 3414 insertions(+) create mode 100644 src/libs/softfloat-3e/testfloat/doc/TestFloat-general.html create mode 100644 src/libs/softfloat-3e/testfloat/doc/TestFloat-history.html create mode 100644 src/libs/softfloat-3e/testfloat/doc/TestFloat-source.html create mode 100644 src/libs/softfloat-3e/testfloat/doc/testfloat.html create mode 100644 src/libs/softfloat-3e/testfloat/doc/testfloat_gen.html create mode 100644 src/libs/softfloat-3e/testfloat/doc/testfloat_ver.html create mode 100644 src/libs/softfloat-3e/testfloat/doc/testsoftfloat.html create mode 100644 src/libs/softfloat-3e/testfloat/doc/timesoftfloat.html (limited to 'src/libs/softfloat-3e/testfloat/doc') diff --git a/src/libs/softfloat-3e/testfloat/doc/TestFloat-general.html b/src/libs/softfloat-3e/testfloat/doc/TestFloat-general.html new file mode 100644 index 00000000..55f67d71 --- /dev/null +++ b/src/libs/softfloat-3e/testfloat/doc/TestFloat-general.html @@ -0,0 +1,1148 @@ + + + + +Berkeley TestFloat General Documentation + + + + +

Berkeley TestFloat Release 3e: General Documentation

+ +

+John R. Hauser
+2018 January 20
+

+ + +

+ +

+ +++ + + + + + + + + + + + + + + + + + + + +

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

+ +

+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. +All operations required by the original 1985 version of the IEEE Floating-Point +Standard can be tested, except for conversions to and from decimal. +With the current release, the following binary formats can be tested: +16-bit half-precision, 32-bit single-precision, +64-bit double-precision, 80-bit +double-extended-precision, and/or 128-bit quadruple-precision. +TestFloat cannot test decimal floating-point. +

+ +

+Included in the TestFloat package are the testsoftfloat and +timesoftfloat programs for testing the Berkeley SoftFloat software +implementation of floating-point and for measuring its speed. +Information about SoftFloat can be found at the SoftFloat Web page, +http://www.jhauser.us/arithmetic/SoftFloat.html. +The testsoftfloat and timesoftfloat programs are +expected to be of interest only to people compiling the SoftFloat sources. +

+ +

+This document explains how to use the TestFloat programs. +It does not attempt to define or explain much of the IEEE Floating-Point +Standard. +Details about the standard are available elsewhere. +

+ +

+The current version of TestFloat is Release 3e. +This version differs from earlier releases 3b through 3d in only minor ways. +Compared to the original Release 3: +

+Release 3b added the ability to test the 16-bit +half-precision format. +
+Release 3c added the ability to test a rarely used rounding mode, +round to odd, also known as jamming. +
+Release 3d modified the code for testing C arithmetic to +potentially include testing newer library functions sqrtf, +sqrtl, fmaf, fma, and fmal. +

+This release adds a few more small improvements, including modifying the +expected behavior of rounding mode odd and fixing a minor bug in +the all-in-one testfloat program. +

+ +

+Compared to Release 2c and earlier, the set of TestFloat programs, as well as +the programs’ arguments and behavior, changed some with +Release 3. +For more about the evolution of TestFloat releases, see +TestFloat-history.html. +

+ + +

2. Limitations

+ +

+TestFloat output is not always easily interpreted. +Detailed knowledge of the IEEE Floating-Point 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 chance. +Software that purposefully seeks out various kinds of subtle floating-point +bugs can be found through links posted on the TestFloat Web page, +http://www.jhauser.us/arithmetic/TestFloat.html. +

+ + +

3. Acknowledgments and License

+ +

+The TestFloat package was written by me, John R. Hauser. +Release 3 of TestFloat was a completely new implementation +supplanting earlier releases. +The project to create Release 3 (now through 3e) 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: +Microsoft (Award #024263), Intel (Award #024894), and U.C. Discovery +(Award #DIG07-10227), with additional support from Par Lab affiliates Nokia, +NVIDIA, Oracle, and Samsung. +
ASPIRE Lab: +DARPA PERFECT program (Award #HR0011-12-2-0016), with additional support from +ASPIRE industrial sponsor Intel and ASPIRE affiliates Google, Nokia, NVIDIA, +Oracle, and Samsung. +
+

+ +

+The following applies to the whole of TestFloat Release 3e as well +as to each source file individually. +

+ +

+Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions are met: +

+
+Redistributions of source code must retain the above copyright notice, this +list of conditions, and the following disclaimer. +
+ +
+
+Redistributions in binary form must reproduce the above copyright notice, this +list of conditions, and the following disclaimer in the documentation and/or +other materials provided with the distribution. +
+ +
+
+Neither the name of the University nor the names of its contributors may be +used to endorse or promote products derived from this software without specific +prior written permission. +
+ +

+ +

+THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS “AS IS”, +AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ARE +DISCLAIMED. +IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, +INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, +BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF +LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE +OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF +ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +

+ + +

4. What TestFloat Does

+ +

+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. +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. +The cases generated should be adequate for testing carry chain propagations, +and the rounding of addition, subtraction, multiplication, 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 addition and multiplication, millions of +test cases may be checked. +

+ +

+TestFloat is not remarkably good at testing difficult rounding cases for +division and square root. +It also makes no attempt to find bugs specific to SRT division and the like +(such as the infamous Pentium division bug). +Software that tests for such failures can be found through links on the +TestFloat Web page, +http://www.jhauser.us/arithmetic/TestFloat.html. +

+ +

+NOTE!
+It is the responsibility of the user to verify that the discrepancies TestFloat +finds actually represent faults in the implementation 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 five rounding modes defined by the +IEEE Floating-Point Standard, plus possibly a sixth mode, round to odd +(depending on the options selected when TestFloat was built). +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 the 80-bit double-extended-precision format, TestFloat can +test the addition, subtraction, multiplication, division, and square root +operations at all three of the standard rounding precisions. +The rounding precision can be set to 32 bits, equivalent to +single-precision, to 64 bits, equivalent to double-precision, or +to the full 80 bits of the double-extended-precision. +Rounding precision control can be applied only to the double-extended-precision +format and only for the five basic arithmetic operations: addition, +subtraction, multiplication, division, and square root. +Other operations can be tested only at full precision. +

+ +

+As a rule, TestFloat is not particular about the bit patterns of NaNs that +appear as operation 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 section 8 below, Variations Allowed by the IEEE +Floating-Point Standard, plus the -checkNaNs and +-checkInvInts options documented 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. +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. +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. +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 +TestFloat executable or when compiling SoftFloat for some other reason. +

+ + +

5. Executing TestFloat

+ +

+The TestFloat package consists of five programs, all intended to be executed +from a command-line interpreter: +

+ + + + + + + + + + + + + + + + + + + + + +
+testfloat_gen    + +Generates test cases for a specific floating-point operation. +
+testfloat_ver + +Verifies whether the results from executing a floating-point operation are as +expected. +
+testfloat + +An all-in-one program that generates test cases, executes floating-point +operations, and verifies whether the results match expectations. +
+testsoftfloat    + +Like testfloat, but for testing SoftFloat. +
+timesoftfloat    + +A program for measuring the speed of SoftFloat (included in the TestFloat +package for convenience). +
+

+Each program has its own page of documentation that can be opened through the +links in the table above. +

+ +

+To test a floating-point implementation other than SoftFloat, one of three +different methods can be used. +The first method pipes output from testfloat_gen to a program +that: +(a) reads the incoming test cases, (b) invokes the +floating-point operation being tested, and (c) writes the +operation results to output. +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>
+

+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 +-prefix option of testfloat_gen can communicate +parameters through the pipe. +

+ +

+A second method for running TestFloat is similar but has +testfloat_gen supply not only the test inputs but also the +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>
+

+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 +testfloat_ver check and report suspected errors (first method) or +to include this step in the invoking program (second method). +

+ +

+The third way to use TestFloat is the all-in-one testfloat +program. +This program can perform all the steps of creating test cases, invoking the +floating-point operation, checking the results, and reporting suspected errors. +However, for this to be possible, testfloat must be compiled to +contain the method for invoking the floating-point operations to test. +Each build of testfloat is therefore capable of testing +only the floating-point implementation it was built to invoke. +To test a new implementation of floating-point, a new testfloat +must be created, linked to that specific implementation. +By comparison, the testfloat_gen and testfloat_ver +programs are entirely generic; +one instance is usable for testing any floating-point implementation, because +implementation-specific details are segregated in the custom program that +follows testfloat_gen. +

+ +

+Program testsoftfloat is another all-in-one program specifically +for testing SoftFloat. +

+ +

+Programs testfloat_ver, testfloat, and +testsoftfloat all report status and error information in a common +way. +As it executes, each of these programs 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. +Any discrepancies that are found are written to the standard output stream, +which is easily redirected to a file if desired. +Unless redirected, reported errors will appear intermixed with the ongoing +status information in the output. +

+ + +

6. Operations Tested by TestFloat

+ +

+TestFloat can test all operations required by the original 1985 IEEE +Floating-Point Standard except for conversions to and from decimal. +These operations are: +

+conversions among the supported floating-point formats, and also between +integers (32-bit and 64-bit, signed and unsigned) and +any of the floating-point formats; +
+for each floating-point format, the usual addition, subtraction, +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 +
+comparisons between two values in the same floating-point format. +

+In addition, TestFloat can also test +

+for each floating-point format except 80-bit +double-extended-precision, the fused multiply-add operation defined by the 2008 +IEEE Standard. +

+ +

+More information about all these operations is given below. +In the operation names used by TestFloat, 16-bit half-precision is +called f16, 32-bit single-precision is +f32, 64-bit double-precision is f64, +80-bit double-extended-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. +

+ +

6.1. Conversion Operations

+ +

+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_f16      ui64_to_f16      i32_to_f16       i64_to_f16
+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
+
+f16_to_ui32      f32_to_ui32      f64_to_ui32      extF80_to_ui32    f128_to_ui32
+f16_to_ui64      f32_to_ui64      f64_to_ui64      extF80_to_ui64    f128_to_ui64
+f16_to_i32       f32_to_i32       f64_to_i32       extF80_to_i32     f128_to_i32
+f16_to_i64       f32_to_i64       f64_to_i64       extF80_to_i64     f128_to_i64
+
+f16_to_f32       f32_to_f16       f64_to_f16       extF80_to_f16     f128_to_f16
+f16_to_f64       f32_to_f64       f64_to_f32       extF80_to_f32     f128_to_f32
+f16_to_extF80    f32_to_extF80    f64_to_extF80    extF80_to_f64     f128_to_f64
+f16_to_f128      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. +These conversions all round according to the current rounding mode as relevant. +Conversions from a smaller to a larger floating-point format are always exact +and so require no rounding. +Likewise, conversions from 32-bit integers to 64-bit +double-precision or to any larger floating-point format are also exact, as are +conversions from 64-bit integers to 80-bit +double-extended-precision and 128-bit quadruple-precision. +

+ +

+For the all-in-one testfloat program, this list of conversion +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>
+

+as listed above, operations converting to integer type have names of these +forms: +

+<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. +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. +

+ +

+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 in the result format. +In such a circumstance: +

+
+If the result type is an unsigned integer, TestFloat normally expects the +result of the operation to be the type’s largest integer value. +In the case that the input is a negative number (not a NaN), a zero result may +also be accepted. +
+ +
+
+If the result type is a signed integer and the input is a number (not a NaN), +TestFloat expects the result to be the largest-magnitude integer with the same +sign as the input. +When a NaN is converted to a signed integer type, TestFloat allows either the +largest postive or largest-magnitude negative integer to be returned. +
+ +

+Conversions to integer types are expected never to raise the overflow +exception. +

+ +

6.2. Basic Arithmetic Operations

+ +

+The following standard arithmetic operations can be tested: +

+f16_add      f16_sub      f16_mul      f16_div      f16_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. +

+ +

6.3. Fused Multiply-Add Operations

+ +

+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: +

+f16_mulAdd
+f32_mulAdd
+f64_mulAdd
+f128_mulAdd
+

+ +

+If one of the multiplication operands is infinite and the other is zero, +TestFloat expects the fused multiply-add operation to raise the invalid +exception even if the third operand is a quiet NaN. +

+ +

6.4. Remainder Operations

+ +

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

+f16_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 +operation. +For most TestFloat programs, these operations are: +

+f16_roundToInt
+f32_roundToInt
+f64_roundToInt
+extF80_roundToInt
+f128_roundToInt
+

+ +

+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
+

+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 particular +specification for the round-to-integer operations. +

+ +

6.6. Comparison Operations

+ +

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

+f16_eq      f16_le      f16_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 IEEE Standard specifies that, by default, the less-than-or-equal and +less-than comparisons raise the invalid exception if either input is any +kind of NaN. +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: +

+f16_eq_signaling      f16_le_quiet      f16_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. +Similarly, the quiet comparison operations should be identical to +their counterparts except that the invalid exception is not raised for +quiet NaNs. +

+ +

+Obviously, no comparison operations ever require rounding. +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. +For each test case tried, the results from the floating-point implementation +being tested could differ from the expected results for several reasons: +

+The IEEE Floating-Point Standard allows for some variation in how conforming +floating-point behaves. +Two implementations can sometimes 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 emulation is coded, or +because a mistake was made when the code was compiled for the current system. +
+The TestFloat program may not work properly, reporting differences 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 that are reported. +Making this determination can require detailed knowledge about the IEEE +Standard. +Assuming TestFloat is working properly, any differences found will be due to +either the first or last of the reasons above. +Variations in the IEEE Standard that could lead to false error reports are +discussed in section 8, Variations Allowed by the IEEE +Floating-Point Standard. +

+ +

+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. +

+ +

+Each error reported is of the form: +

+<inputs>  => <observed-output>  expected: <expected-output>
+

+The <inputs> are the inputs to the operation. +Each output (observed or expected) is shown as a pair: the result value first, +followed by the exception flags. +

+ +

+For example, two typical error lines could be +

+-00.7FFF00  -7F.000100  => +01.000000 ...ux  expected: +01.000000 ....x
++81.000004  +00.1FFFFF  => +01.000000 ...ux  expected: +01.000000 ....x
+

+In the first line, the inputs are -00.7FFF00 and +-7F.000100, and the observed result is +01.000000 +with flags ...ux. +The trusted emulation result is the same but with different flags, +....x. +Items such as -00.7FFF00 composed of a sign character +(+/-), hexadecimal digits, and a single +period represent floating-point values (here 32-bit +single-precision). +The two instances above were reported as errors because the exception flag +results differ. +

+ +

+Aside from the exception flags, there are ten data types that may be +represented. +Five are floating-point types: 16-bit half-precision, +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). +Boolean values are represented as a single character, either a 0 +(false) or a 1 (true). +A 32-bit integer is represented as 8 hexadecimal digits. +Thus, for a signed 32-bit integer, FFFFFFFF is +−1, and 7FFFFFFF is the largest positive value. +64-bit integers are the same except with 16 hexadecimal digits. +

+ +

+Floating-point values are written decomposed into their sign, encoded exponent, +and encoded significand. +First is the sign character (+ or -), +followed by the encoded exponent in hexadecimal, then a period +(.), and lastly the encoded significand in hexadecimal. +

+ +

+For 16-bit half-precision, notable values include: +

+ + + + + + + + + + + + + + + +
+00.000 +0
+0F.000 1
+10.000 2
+1E.3FF maximum finite value
+1F.000 +infinity

-00.000 −0
-0F.000 −1
-10.000 −2
-1E.3FF minimum finite value (largest magnitude, but negative)
-1F.000 −infinity
+

+Certain categories are easily distinguished (assuming the xs are +not all 0): +

+ + + + + + + + +
+00.xxx positive subnormal numbers
+1F.xxx positive NaNs
-00.xxx negative subnormal numbers
-1F.xxx negative NaNs
+

+ +

+Likewise for other formats: +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
32-bit single 64-bit double 128-bit quadruple

+00.000000 +000.0000000000000 +0000.0000000000000000000000000000 +0
+7F.000000 +3FF.0000000000000 +3FFF.0000000000000000000000000000 1
+80.000000 +400.0000000000000 +4000.0000000000000000000000000000 2
+FE.7FFFFF +7FE.FFFFFFFFFFFFF +7FFE.FFFFFFFFFFFFFFFFFFFFFFFFFFFF maximum finite value
+FF.000000 +7FF.0000000000000 +7FFF.0000000000000000000000000000 +infinity

-00.000000 -000.0000000000000 -0000.0000000000000000000000000000 −0
-7F.000000 -3FF.0000000000000 -3FFF.0000000000000000000000000000 −1
-80.000000 -400.0000000000000 -4000.0000000000000000000000000000 −2
-FE.7FFFFF -7FE.FFFFFFFFFFFFF -7FFE.FFFFFFFFFFFFFFFFFFFFFFFFFFFF minimum finite value
-FF.000000 -7FF.0000000000000 -7FFF.0000000000000000000000000000 −infinity

+00.xxxxxx +000.xxxxxxxxxxxxx +0000.xxxxxxxxxxxxxxxxxxxxxxxxxxxx positive subnormals
+FF.xxxxxx +7FF.xxxxxxxxxxxxx +7FFF.xxxxxxxxxxxxxxxxxxxxxxxxxxxx positive NaNs
-00.xxxxxx -000.xxxxxxxxxxxxx -0000.xxxxxxxxxxxxxxxxxxxxxxxxxxxx negative subnormals
-FF.xxxxxx -7FF.xxxxxxxxxxxxx -7FFF.xxxxxxxxxxxxxxxxxxxxxxxxxxxx negative NaNs
+

+ +

+The 80-bit double-extended-precision values are a little unusual +in that the leading bit of precision is not hidden as with other formats. +When canonically encoded, the leading significand bit of an 80-bit +double-extended-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 80-bit +double-extended-precision as follows (note the leading 8 digit in +the significands): +

+ + + + + + + + + + + + + + + + + + + + + +
+0000.0000000000000000 +0
+3FFF.8000000000000000 1
+4000.8000000000000000 2
+7FFE.FFFFFFFFFFFFFFFF maximum finite value
+7FFF.8000000000000000 +infinity

-0000.0000000000000000 −0
-3FFF.8000000000000000 −1
-4000.8000000000000000 −2
-7FFE.FFFFFFFFFFFFFFFF minimum finite value
-7FFF.8000000000000000 −infinity
+

+ +

+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 exception
i infinite exception (“divide by zero”)
o overflow exception
u underflow exception
x inexact 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 +set. +The exception flags are always written following the value returned as the +result of the operation. +

+ + +

8. Variations Allowed by the IEEE Floating-Point Standard

+ +

+The IEEE Floating-Point 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. +

+ +

8.1. 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. +All the TestFloat programs support options -tininessbefore and +-tininessafter to control whether TestFloat expects tininess on +underflow to be detected before or after rounding. +One or the other is selected as the default when TestFloat is compiled, but +these command options allow the default to be overridden. +

+ +

+Loss of accuracy occurs when the subnormal format is not sufficient to +represent an underflowed result accurately. +The original 1985 version of the IEEE Standard allowed loss of accuracy to be +detected either as an inexact result or as a +denormalization loss; +however, few if any systems ever chose the latter. +The latest standard requires that loss of accuracy be detected as an inexact +result, and TestFloat can test only for this case. +

+ +

8.2. NaNs

+ +

+The 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 of +programs testfloat_ver and testfloat. +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. +

+ +

8.3. 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 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. +In such cases, TestFloat expects the result value to be the largest-magnitude +positive or negative integer or zero, as detailed earlier in +section 6.1, Conversion Operations. +If option -checkInvInts is selected with programs +testfloat_ver and testfloat, integer results of +invalid operations are checked for an exact match. +In order for this option to be sensible, TestFloat must have been compiled so +that its internal floating-point implementation (SoftFloat) generates the +proper integer results for the system being tested. +

+ + +

9. 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://www.jhauser.us/arithmetic/TestFloat.html. +

+ + + + diff --git a/src/libs/softfloat-3e/testfloat/doc/TestFloat-history.html b/src/libs/softfloat-3e/testfloat/doc/TestFloat-history.html new file mode 100644 index 00000000..1c247de0 --- /dev/null +++ b/src/libs/softfloat-3e/testfloat/doc/TestFloat-history.html @@ -0,0 +1,272 @@ + + + + +Berkeley TestFloat History + + + + +

History of Berkeley TestFloat, to Release 3e

+ +

+John R. Hauser
+2018 January 20
+

+ + +

+Releases of Berkeley TestFloat normally parallel those of Berkeley SoftFloat, +on which TestFloat is based. +Each TestFloat release necessarily incorporates all bug fixes from the +corresponding release of SoftFloat. +

+ + +

Release 3e (2018 January)

+ +

+Fixed a problem with the all-in-one testfloat program whereby +function set -all1 incorrectly also tested the three-operand fused +multiply-add operations. + +
+Modified the expected behavior of rounding mode odd (jamming) when +rounding to an integer value (either conversion to an integer format or a +‘roundToInt’ function). +Previously, for those cases only, rounding mode odd was expected +to act the same as rounding to minimum magnitude. +Now, when rounding to an integer value, the nearest odd integer is expected, +consistent with the round-to-odd result of other operations. + +
+Added options -checkInvInts and -checkAll to programs +testfloat_ver and testfloat. + +
+Improved the checking of integer results of invalid operations. + +

+ + +

Release 3d (2017 August)

+ +

+When the all-in-one testfloat program is compiled to test the C +language’s arithmetic, added the ability to test library functions +sqrtf, sqrtl, fmaf, fma, +and fmal, which were added to the C Standard in 1999. + +

+ + +

Release 3c (2017 February)

+ +

+Added support for testing rounding mode odd (jamming). + +
+Made support for testing 64-bit double-precistion floating-point +be subject to macro FLOAT64 (akin to macros FLOAT16, +EXTFLOAT80, and FLOAT128 from before). + +
+Fixed some bugs that caused compilation to fail with certain combinations of +option macro settings. + +
+Corrected the types of two internal variables to be sig_atomic_t +instead of bool. + +
+Improved the formatting of some error reports (concerning where lines are +broken when they exceed 79 characters in length). + +

+ + +

Release 3b (2016 July)

+ +

+Added the ability to test the common 16-bit +“half-precision” floating-point format. + +
+Added a -seed option to programs testfloat_gen, +testfloat, and testsoftfloat for setting the seed for +the pseudo-random number generator used to generate test cases. + +
+Where a specific choice is needed for how tininess is detected on underflow, +changed the default to be the detection of tininess after rounding +(-tininessafter) instead of before rounding +(-tininessbefore). + +
+Modified the format of reported discrepancies to show the signs of +floating-point values using + and - characters. + +
+Documented the use of the INLINE macro, and fixed the sources for +the case that function inlining is not supported by the C compiler. + +
+Documented the possible need to define macro THREAD_LOCAL to match +how the SoftFloat library was built. + +
+Modified the provided Makefiles to allow some options to be overridden from the +make command. + +

+ + +

Release 3a (2015 October)

+ +

+Replaced the license text supplied by the University of California, Berkeley, +and fixed some minor build problems. + +

+ + +

Release 3 (2015 February)

+ +

+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 command +options. + +
+Reinstated separate programs for generating test cases +(testfloat_ver) and verifying test results +(testfloat_gen), as alternatives to the all-in-one +testfloat program (which remained supported). + +
+Added support for testing conversions between floating-point and unsigned +integers, both 32-bit and 64-bit. + +
+Added support for testing a fused multiply-add operation, for all testable +floating-point formats except 80-bit double-extended-precision. + +
+Added support for testing a fifth rounding mode, near_maxMag +(round to nearest, with ties to maximum magnitude, away from zero). + +
+Added timesoftfloat (previously found in the Berkeley SoftFloat +package). + +

+ + +

Release 2c (2015 January)

+ +

+Fixed mistakes affecting some 64-bit processors. + +
+Made minor updates to the documentation, including improved wording for the +legal restrictions on using TestFloat releases through 2c (not +applicable to Release 3 or later). + +

+ + +

+There was never a Release 2b. +

+ + +

Release 2a (1998 December)

+ +

+Added support for testing conversions between floating-point and +64-bit signed 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 80-bit double-extended-precision and +128-bit quadruple precision. + +
+Made program output more readable, and added new command arguments. + +
+Reduced dependence on the quality of the standard rand function +for generating test cases. +(Previously naively expected rand 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. + +

+ + + + diff --git a/src/libs/softfloat-3e/testfloat/doc/TestFloat-source.html b/src/libs/softfloat-3e/testfloat/doc/TestFloat-source.html new file mode 100644 index 00000000..24fb5946 --- /dev/null +++ b/src/libs/softfloat-3e/testfloat/doc/TestFloat-source.html @@ -0,0 +1,639 @@ + + + + +Berkeley TestFloat Source Documentation + + + + +

Berkeley TestFloat Release 3e: Source Documentation

+ +

+John R. Hauser
+2018 January 20
+

+ + +

+ +

+ +++ + + + + + + + + + + + + + + +

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

+ +

+This document gives information needed for compiling and/or porting Berkeley +TestFloat, a small collection of programs for testing that an implementation of +binary floating-point conforms to the IEEE Standard for Floating-Point +Arithmetic. +For basic documentation about TestFloat refer to +TestFloat-general.html. +

+ +

+The source code for TestFloat is intended to be relatively machine-independent. +Most programs in the TestFloat package should be compilable with any +ISO-Standard C compiler that also supports 64-bit integers. +If the all-in-one testfloat program will be used to test a new +floating-point implementation, additional effort will likely be required to +retarget that program to invoke the new floating-point operations. +TestFloat has been successfully compiled with the GNU C Compiler +(gcc) for several platforms. +

+ +

+Release 3 of TestFloat was a complete rewrite relative to +Release 2c or earlier. +The current version of TestFloat is Release 3e. +

+ +

+TestFloat depends on Berkeley SoftFloat, which is a software implementation of +binary floating-point that conforms to the IEEE Standard for Floating-Point +Arithmetic. +SoftFloat is not included with the TestFloat sources. +It can be obtained from the Web page +http://www.jhauser.us/arithmetic/SoftFloat.html. +

+ + +

2. Limitations

+ +

+TestFloat assumes the computer has an addressable byte size of either 8 or +16 bits. +(Nearly all computers in use today have 8-bit bytes.) +

+ +

+TestFloat is written entirely in C. +The C compiler used must conform at a minimum to the 1989 ANSI standard for the +C language (same as the 1990 ISO standard) and must in addition support basic +arithmetic on 64-bit integers. +Earlier releases of TestFloat were capable of testing 32-bit +single-precision and 64-bit double-precision floating-point +without requiring compiler support for 64-bit integers, but this +option is not supported starting with Release 3. +Since 1999, ISO standards for C have mandated compiler support for +64-bit integers. +A compiler conforming to the 1999 C Standard or later is recommended but not +strictly required. +

+ +

+C Standard header files <stdbool.h> and +<stdint.h> are required for defining standard Boolean and +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 +section 6.1, Standard Headers <stdbool.h> +and <stdint.h>. +

+ + +

3. Acknowledgments and License

+ +

+ ++++ + + + + + + + + + +

Par Lab: +Microsoft (Award #024263), Intel (Award #024894), and U.C. Discovery +(Award #DIG07-10227), with additional support from Par Lab affiliates Nokia, +NVIDIA, Oracle, and Samsung. +
ASPIRE Lab: +DARPA PERFECT program (Award #HR0011-12-2-0016), with additional support from +ASPIRE industrial sponsor Intel and ASPIRE affiliates Google, Nokia, NVIDIA, +Oracle, and Samsung. +
+

+ +

+The following applies to the whole of TestFloat Release 3e as well +as to each source file individually. +

+ +

+Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions are met: +

+
+Redistributions of source code must retain the above copyright notice, this +list of conditions, and the following disclaimer. +
+ +
+
+Redistributions in binary form must reproduce the above copyright notice, this +list of conditions, and the following disclaimer in the documentation and/or +other materials provided with the distribution. +
+ +
+
+Neither the name of the University nor the names of its contributors may be +used to endorse or promote products derived from this software without specific +prior written permission. +
+ +

+ +

+ + +

4. TestFloat Package 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 supplied directory structure is as follows: +

+doc
+source
+    subj-C
+build
+    template
+    Linux-386-GCC
+    Linux-386-SSE2-GCC
+    Linux-x86_64-GCC
+    Linux-ARM-VFPv2-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, +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. +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 +the form subj-<target>. +More about retargeting testfloat is found in +section 6.4, Specializing the testfloat +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. +The template subdirectory is not an actual build target but +contains sample files for creating new target directories. +

+ +

+Ignoring the template directory, the supplied target directories +are intended to follow a naming system of +<execution-environment>-<compiler>. +For the example targets, +<execution-environment> is +Linux-386, Linux-386-SSE2, +Linux-x86_64, +Linux-ARM-VFPv2, Win32, +Win32-SSE2, or Win64, and +<compiler> is GCC, +MinGW, or MinGW-w64. +

+ +

+All of the supplied target directories are merely examples that may or may not +be correct for compiling on any particular system. +There are currently no plans to include and maintain in the TestFloat package +the build files needed for a great many users’ compilation environments, +which can span a huge range of operating systems, compilers, and other tools. +

+ +

+As supplied, each target directory contains two files: +

+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. +A completely different build tool can be used if an appropriate +Makefile equivalent is created. +

+ +

+The platform.h header file exists to provide a location for +additional C declarations specific to the build target. +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. +

+ +

+It may not be necessary to build all of the TestFloat programs. +For testing a floating-point implementation, typically +testfloat_gen and testfloat will not both be used, +and testfloat_ver may not be needed either. +The Makefile (or equivalent) can be modified not to create unneeded programs. +This may be especially relevant for the all-in-one test program +testfloat, which might not build without special attention. +

+ + +

5. Dependence on Berkeley SoftFloat

+ +

+In addition to the distributed sources, TestFloat depends on the existence of a +compatible Berkeley SoftFloat library and the corresponding header file +softfloat.h. +As mentioned earlier, SoftFloat is a separate package available at Web page +http://www.jhauser.us/arithmetic/SoftFloat.html. +The SoftFloat library must be compiled before the TestFloat programs can be +built. +In the example Makefiles, the locations of the SoftFloat header files and +pre-compiled library are specified by these macros: +

+
+
SOFTFLOAT_INCLUDE_DIR +
+The path of the directory containing softfloat.h, as well as other +nonstandard header files referenced by softfloat.h, if any. +
SOFTFLOAT_H +
+A list of the full paths of all SoftFloat header files needed by SoftFloat +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. +
SOFTFLOAT_LIB +
+The full path of the compiled SoftFloat library (usually +softfloat.a or libsoftfloat.a). +
+

+ + +

6. Issues for Porting TestFloat to a New Target

+ +

6.1. Standard Headers `<stdbool.h>` and `<stdint.h>`

+ +

+The TestFloat sources make use of standard headers +<stdbool.h> and <stdint.h>, which have +been part of the ISO C Standard Library since 1999. +With any recent compiler, these standard headers are likely to be supported, +even if the compiler does not claim complete conformance to the latest ISO C +Standard. +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
+

+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_fast8_t
+int_fast16_t
+int_fast32_t
+int_fast64_t
+

+ + +

6.2. Standard Header `<fenv.h>`

+ +

+Because the supplied all-in-one testfloat program tests the +floating-point operations of the C language, it uses the facilities provided by +standard C header <fenv.h> to access the floating-point +environment of C, in particular to set the rounding mode and to access the +floating-point exception flags. +Like <stdbool.h> and <stdint.h>, +<fenv.h> has been part of the ISO C Standard Library since +1999, but older or nonstandard C compilers may not support it. +

+ +

+Some form of standard header <fenv.h> is needed only if the +testfloat program is wanted and the program will not be +retargeted to invoke a floating-point implementation in a way that bypasses the +standard C environment. +Typically, if testfloat is wanted, it will be retargeted to invoke +a new floating-point implementation directly, making +<fenv.h> irrelevant. +For more about retargeting testfloat, see section 6.4 +below, Specializing the testfloat Program. +

+ + +

6.3. Macros for Build Options

+ +

+The TestFloat source files are affected by several C preprocessor macros: +

+
+
LITTLEENDIAN +
+Must be defined for little-endian machines; +must not be defined for big-endian machines. +
INLINE +
+Can be defined to a sequence of tokens used to indicate that a C function +should be inlined. +If the compiler does not support the inlining of functions, this macro must not +be defined. +For compilers that conform to the C Standard’s rules for inline +functions, this macro can be defined as the single keyword inline. +For other compilers that follow a convention pre-dating the standardization of +inline, this macro may need to be defined to extern +inline. +
THREAD_LOCAL +
+Can be defined to a sequence of tokens that, when appearing at the start of a +variable declaration, indicates to the C compiler that the variable is +per-thread, meaning that each execution thread gets its own separate +instance of the variable. +This macro is used in the supplied version of Berkeley SoftFloat’s header +softfloat.h, in the declarations of variables +softfloat_roundingMode, softfloat_detectTininess, +extF80_roundingPrecision, and +softfloat_exceptionFlags. +To use the supplied, unmodified header softfloat.h, this macro +must be defined (or not defined) the same as when the SoftFloat library was +built. +
+
+
FLOAT16 +
+Must be defined if the TestFloat programs are to support the +16-bit half-precision floating-point format. +
FLOAT64 +
+Must be defined if the TestFloat programs are to support the +64-bit double-precision floating-point format. +
EXTFLOAT80 +
+Must be defined if the TestFloat programs are to support the +80-bit double-extended-precision floating-point format. +
FLOAT128 +
+Must be defined if the TestFloat programs are to support the +128-bit quadruple-precision floating-point format. +
FLOAT_ROUND_ODD +
+Must be defined if the TestFloat programs are to support rounding to odd +(jamming). +To be useful, this option also requires that the Berkeley SoftFloat library was +compiled with macro SOFTFLOAT_ROUND_ODD defined. +
+

+Following the usual custom for C, for all the macros except +INLINE and THREAD_LOCAL, the content of a +macro’s definition is irrelevant; +what matters is a macro’s effect on #ifdef directives. +

+ +

+It is recommended that any definition of macros LITTLEENDIAN, +INLINE, and THREAD_LOCAL be made in a build +target’s platform.h header file, because these macros are +expected to be determined inflexibly by the target machine and compiler. +The other five macros select build options, and hence might be better located +in the target’s Makefile (or its equivalent). +

+ + +

6.4. Specializing the `testfloat` Program

+ +

+The supplied sources for the all-in-one testfloat program cause +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 +double if the sources are compiled with one of these macros +defined: +

+
+
LONG_DOUBLE_IS_EXTFLOAT80 +
+Indicates that type long double is +80-bit double-extended-precision floating-point. +
LONG_DOUBLE_IS_FLOAT128 +
+Indicates that type long double is +128-bit quadruple-precision floating-point. +
+

+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. +For other rounding modes, additional macro can be defined: +

+
+
SUBJFLOAT_ROUND_NEAR_MAXMAG +
+Indicates that the subject floating-point supports rounding mode +near_maxMag (nearest/away). +
SUBJFLOAT_ROUND_ODD +
+Indicates that the subject floating-point supports rounding mode +odd (jamming). +
+

+ +

+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. +Two source files define the functions that testfloat uses to +invoke floating-point operations for testing: +

+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 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, where <target> names the particular +target. +

+ +

+Header file subjfloat_config.h defines a macro of the form +SUBJ_* for each subject function supported. +For example, if function subj_f32_add exists to perform +32-bit floating-point addition, then +subjfloat_config.h should have a definition for macro +SUBJ_F32_ADD. +The actual function subj_f32_add is expected to be defined in +subjfloat.c, along with all other subject functions. +A common header file, subjfloat.h, (not target-specific) provides +prototype declarations for all possible subject functions that +testfloat may be compiled to test, whether actually existing or +not. +(There is no penalty for the header to declare prototypes of nonexistent +functions that are never called.) +For a specific build of testfloat, the -list option +will list all subject functions that the testfloat program is able +to invoke and thus test. +

+ +

+In the source code as supplied, macros LONG_DOUBLE_IS_EXTFLOAT80 +and LONG_DOUBLE_IS_FLOAT128 affect only the target-specific source +files in source/subj-C, so these macros can be +ignored for any other subject floating-point that does not depend on them. +On the other hand, macros SUBJFLOAT_ROUND_NEAR_MAXMAG and +SUBJFLOAT_ROUND_ODD always determine whether the +testfloat program attempts to test rounding modes +near_maxMag and odd, regardless of the subject +floating-point. +

+ + +

6.5. Improving the Random Number Functions

+ +

+If you are serious about using TestFloat for testing floating-point, you should +consider replacing the random number functions in random.c. +The supplied random number functions are built on top of the standard C +rand function. +Because function rand is rather poor on some systems, the +functions in random.c assume very little about the quality of +rand. +As a result, rand is called more frequently than it might need to +be, shortening the time before random number sequences repeat, and possibly +wasting time as well. +If rand is better on a given target platform, or if another, +better random number generator is available (such as rand48 on +UNIX-derived systems), TestFloat can be improved by overriding the given +random.c with a target-specific one. +

+ +

+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 +random.c. +

+ + +

7. 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://www.jhauser.us/arithmetic/TestFloat.html. +

+ + + + diff --git a/src/libs/softfloat-3e/testfloat/doc/testfloat.html b/src/libs/softfloat-3e/testfloat/doc/testfloat.html new file mode 100644 index 00000000..f9404e04 --- /dev/null +++ b/src/libs/softfloat-3e/testfloat/doc/testfloat.html @@ -0,0 +1,286 @@ + + + + +testfloat + + + + +

Berkeley TestFloat Release 3e: `testfloat`

+ +

+John R. Hauser
+2018 January 20
+

+ + +

Overview

+ +

+The testfloat program tests an implementation of floating-point +arithmetic for conformity to the IEEE Standard for Binary Floating-Point +Arithmetic. +testfloat is part of the Berkeley TestFloat package, a small +collection of programs for performing such tests. +For general information about TestFloat, see file +TestFloat-general.html. +

+ +

+The testfloat program is an all-in-one tool for testing +floating-point arithmetic. +It generates test operand values, invokes a floating-point operation with the +generated operands, and examines the corresponding computed results, reporting +unexpected results as likely errors. +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 +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 +instructions or a new set of subroutines), a new testfloat must be +compiled containing the code needed to invoke the new floating-point. +

+ +

+The default build of testfloat assumes that C types +float and double are 32-bit and +64-bit binary floating-point types conforming to the IEEE +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. +

+ +

+The testfloat program will ordinarily test an operation for all +five rounding modes defined by the IEEE Floating-Point Standard, one after the +other, plus possibly a sixth mode, round to odd (depending on the +options selected when testfloat was compiled). +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. +Testing can be limited to a single rounding mode and/or rounding precision with +appropriate command-line options. +

+ +

+For more about the operation of testfloat and how to interpret its +output, refer to +TestFloat-general.html. +

+ + +

Command Syntax

+ +

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

+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 function set. +The available options and function sets are documented below. +The -list option can be used to obtain a list of all testable +operations for a given build of testfloat. +If testfloat is executed without any arguments, a summary of usage +is written. +

+ + +

Options

+ +

+The testfloat 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 operations to be +written, after which the program exits. +An operation is testable by testfloat if the program knows some +way to invoke the operation. +

+ +

`-seed <num>`

+ +

+The -seed option sets the seed for the pseudo-random number +generator used for generating test cases. +The argument to -seed is a nonnegative integer. +Executing the same compiled testfloat program with the same +arguments (including the same pseudo-random number seed) should always perform +the same sequence of tests, whereas changing the pseudo-random number seed +should result in a different sequence of tests. +The default seed number is 1. +

+ +

`-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 and thus 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 operation, +rounding mode, etc. +The argument to -errors must be a nonnegative decimal integer. +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 +operation 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 +execution. +If not specified, the rounding mode defaults to nearest/even. +For 80-bit double-extended-precision operations, the rounding +precision defaults to full double-extended 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 reference implementation of floating-point +(Berkeley SoftFloat) generates the proper NaN results for the system being +tested. +

+ +

`-checkInvInts`

+ +

+The -checkInvInts option causes testfloat to verify +the bitwise correctness of integer results of invalid operations. +In order for this option to be sensible, testfloat must have been +compiled so that its internal reference implementation of floating-point +(Berkeley SoftFloat) generates the proper integer results for the system being +tested. +

+ +

`-checkAll`

+ +

+Enables both -checkNaNs and -checkInvInts. +

+ +

`-precision32, -precision64, -precision80`

+ +

+For 80-bit double-extended-precision operations affected by +rounding precision control, the -precision32 option restricts +testing to only the cases in which the rounding precision is +32 bits, equivalent to 32-bit single-precision. +The other rounding precision choices are not tested. +Likewise, -precision64 fixes the rounding precision to +64 bits, equivalent to 64-bit double-precision, and +-precision80 fixes the rounding precision to the full +80 bits of the double-extended-precision format. +All these options are ignored for operations not affected by rounding precision +control. +

+ +

+The precision-control options may not be supported at all if no +double-extended-precision operations are testable. +

+ +

`-rnear_even, -rnear_maxMag, -rminMag, -rmin, -rmax, -rodd`

+ +

+The -rnear_even option restricts testing to only the cases in +which the rounding mode is nearest/even. +The other rounding mode choices are not tested. +Likewise, -rnear_maxMag forces rounding to nearest/maximum +magnitude (nearest-away), -rminMag forces rounding to minimum +magnitude (toward zero), -rmin forces rounding to minimum (down, +toward negative infinity), -rmax forces rounding to maximum (up, +toward positive infinity), and -rodd, if supported, forces +rounding to odd. +These options are ignored for operations that are exact and thus do not round, +or that have the rounding mode included in the function name (such as +f32_to_i32_r_near_maxMag). +

+ +

`-tininessbefore, -tininessafter`

+ +

+The -tininessbefore option indicates that the floating-point +implementation being tested detects tininess on underflow before rounding. +The -tininessafter option indicates that tininess is detected +after rounding. +The testfloat program 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 +(but not all) operations. +

+ + +

Function Sets

+ +

+Just as testfloat can test an operation for all five or six +rounding modes in sequence, multiple operations can be tested with a single +execution of testfloat. +Two sets are recognized: -all1 and -all2. +The set -all1 is 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
+

+ + + + diff --git a/src/libs/softfloat-3e/testfloat/doc/testfloat_gen.html b/src/libs/softfloat-3e/testfloat/doc/testfloat_gen.html new file mode 100644 index 00000000..5190567c --- /dev/null +++ b/src/libs/softfloat-3e/testfloat/doc/testfloat_gen.html @@ -0,0 +1,367 @@ + + + + +testfloat_gen + + + + +

Berkeley TestFloat Release 3e: `testfloat_gen`

+ +

+John R. Hauser
+2018 January 20
+

+ + +

Overview

+ +

+The testfloat_gen program generates test cases for testing that an +implementation of floating-point arithmetic conforms to the IEEE Standard for +Binary Floating-Point Arithmetic. +testfloat_gen is part of the Berkeley TestFloat package, a small +collection of programs for performing such tests. +For general information about TestFloat, see file +TestFloat-general.html. +

+ +

+A single execution of testfloat_gen generates test cases for only +a single floating-point operation and associated options. +The testfloat_gen program must be repeatedly executed to generate +test cases for each operation to be tested. +

+ +

+The testfloat_gen program writes the test cases it generates to +standard output. +This output can either be captured in a file through redirection, or be piped +to another program that exercises a floating-point operation using the test +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 using +inordinate file space. +The format of testfloat_gen’s output is raw hexadecimal +text, described in the section below titled Output Format. +

+ + +

Command Syntax

+ +

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

+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> specifying the type and number of outputs or a +<function> naming a floating-point operation. +If testfloat_gen is executed without any arguments, a summary of +usage is written. +

+ +

+A <type> can be one of the following: +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ui32 unsigned 32-bit integers
ui64 unsigned 64-bit integers
i32 signed 32-bit integers
i64 signed 64-bit integers
f16 [<num>] one or more 16-bit half-precision floating-point values
f32 [<num>] one or more 32-bit single-precision floating-point values
f64 [<num>] one or more 64-bit double-precision floating-point values
extF80 [<num>] one or more 80-bit double-extended-precision floating-point +values
f128 [<num>] one or more 128-bit quadruple-precision floating-point +values
+

+Optional <num> is one of 1, 2, or 3. +If a <type> is given without +<num> (such as ui32 or +f64), testfloat_gen outputs a list of values of the +specified type, one value per line, appropriate for testing a floating-point +operation with exactly one operand of the given type. +If a floating-point type and number are given (such as +f32 2 or +extF80 1), testfloat_gen +outputs the specified number of values per line, appropriate for testing a +floating-point operation with that number of operands. +Although the exact operation being tested is not specified, the test cases +output by testfloat_gen cover all standard floating-point +operations, to the degree explained in +TestFloat-general.html. +

+ +

+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 (Berkeley SoftFloat). +The available operation names are listed in +TestFloat-general.html. +In all cases, floating-point operations have two results: +first, a value, which may be floating-point, integer, or Boolean, and, second, +the floating-point exception flags raised by the operation. +If the output from a tested floating-point operation does not match the +expected output specified by testfloat_gen, this may or may not +indicate an error in the floating-point operation. +For further explanation, see +TestFloat-general.html, +especially the section titled Variations Allowed by the IEEE Floating-Point +Standard. +

+ + +

Options

+ +

+The testfloat_gen 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. +

+ +

`-prefix <text>`

+ +

+The -prefix option causes testfloat_gen to write the +supplied text argument verbatim as the first line of output before any test +cases. +This can be used, for example, to indicate to a downstream program what kind of +test to perform for the test cases that follow. +

+ +

`-seed <num>`

+ +

+The -seed option sets the seed for the pseudo-random number +generator used for generating test cases. +The argument to -seed is a nonnegative integer. +Executing the same testfloat_gen program with the same arguments +(including the same pseudo-random number seed) should always generate the same +sequence of test cases, whereas changing the pseudo-random number seed should +result in a different sequence of test cases. +The default seed number is 1. +

+ +

`-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 causes many more test cases to be generated, with better +coverage, than level 1. +

+ +

`-n <num>`

+ +

+Option -n specifies the number of test cases to generate. +For each <type> or +<function> and each testing level (set by +-level), there is a minimum value that testfloat_gen +will accept for <num>. +If no -n option is given, the number of test cases generated by +testfloat_gen equals the minimum value acceptable for the +-n argument. +Option -n cannot be used to reduce this number, but can increase +it, without changing the testing level. +

+ +

`-forever`

+ +

+The -forever option causes test cases to be generated +indefinitely, without limit (until the program is terminated by some external +cause). +The testing level is set to 2 by this option. +

+ +

`-precision32, -precision64, -precision80`

+ +

+When a <function> is specified that is an +80-bit double-extended-precision operation affected by rounding +precision control, the -precision32 option sets the rounding +precision to 32 bits, equivalent to 32-bit +single-precision. +Likewise, -precision64 sets the rounding precision to +64 bits, equivalent to 64-bit double-precision, and +-precision80 sets the rounding precision to the full +80 bits of the double-extended-precision format. +All these options are ignored for operations not affected by rounding precision +control. +When rounding precision is applicable but not specified, the default is the +full 80 bits, same as -precision80. +

+ +

`-rnear_even, -rnear_maxMag, -rminMag, -rmin, -rmax, -rodd`

+ +

+When a <function> is specified that requires +rounding, the -rnear_even option sets the rounding mode to +nearest/even; +-rnear_maxMag sets rounding to nearest/maximum magnitude +(nearest-away); +-rminMag sets rounding to minimum magnitude (toward zero); +-rmin sets rounding to minimum (down, toward negative infinity); +-rmax sets rounding to maximum (up, toward positive infinity); +and -rodd, if supported, sets rounding to odd. +These options are ignored for operations that are exact and thus do not round. +When rounding mode is relevant but not specified, the default is to round to +nearest/even, same as -rnear_even. +

+ +

`-tininessbefore, -tininessafter`

+ +

+When a <function> is specified that requires +rounding, the -tininessbefore option indicates that tininess on +underflow will be detected before rounding, while -tininessafter +indicates that tininess on underflow will be detected after rounding. +These options are ignored for operations that are exact and thus do not round. +When the method of tininess detection matters but is not specified, the default +is to detect tininess on underflow after rounding, same as +-tininessafter. +

+ +

`-notexact, -exact`

+ +

+When a <function> is specified that rounds to an +integer (either conversion to an integer type or a roundToInt +operation), the -notexact option indicates that the inexact +exception flag is never raised, while -exact indicates that the +inexact exception flag is to be raised if the result is inexact. +For other operations, these options are ignored. +If neither option is specified, the default is not to raise the inexact +exception flag when rounding to an integer, same as -notexact. +

+ + +

Output Format

+ +

+For each test case generated, testfloat_gen writes a single line +of text to standard output. +When the testfloat_gen command is given a +<type> argument, each test case consists of either +one 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
+

+might look like this: +

+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 +most-significant end of the number. +Thus, for the first number on the first line above, the leading hexadecimal +digits 3F9 are the sign and encoded exponent of the +64-bit floating-point value, and the remaining digits are the +encoded significand. +

+ +

+When testfloat_gen is given a <function> +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
+

+could include these lines: +

+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: +

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

+ + + + diff --git a/src/libs/softfloat-3e/testfloat/doc/testfloat_ver.html b/src/libs/softfloat-3e/testfloat/doc/testfloat_ver.html new file mode 100644 index 00000000..0790896b --- /dev/null +++ b/src/libs/softfloat-3e/testfloat/doc/testfloat_ver.html @@ -0,0 +1,270 @@ + + + + +testfloat_ver + + + + +

Berkeley TestFloat Release 3e: `testfloat_ver`

+ +

+John R. Hauser
+2018 January 20
+

+ + +

Overview

+ +

+The testfloat_ver program accepts test-case results obtained from +exercising an implementation of floating-point arithmetic and verifies that +those results conform to the IEEE Standard for Binary Floating-Point +Arithmetic. +testfloat_ver is part of the Berkeley TestFloat package, a small +collection of programs for performing such tests. +For general information about TestFloat, see file +TestFloat-general.html. +

+ +

+A single execution of testfloat_ver verifies results for only a +single floating-point operation and associated options. +The testfloat_ver program must be repeatedly executed to verify +results for each operation to be tested. +

+ +

+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, +described in the section below titled Input Format. +

+ +

+For each test case given to it, testfloat_ver examines the +computed results and reports any unexpected results as likely errors. + +For more about the operation of testfloat_ver and how to interpret +its output, refer to +TestFloat-general.html. +

+ + +

Command Syntax

+ +

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

+testfloat_ver [<option>...] <function>
+

+Square brackets ([ ]) denote optional arguments, +<option> is a supported option, and +<function> is the name of a testable operation. +The available options are documented below. +The testable operation names are listed in +TestFloat-general.html. +If testfloat_ver is executed without any arguments, a summary of +usage is written. +

+ + +

Options

+ +

+The testfloat_ver 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. +

+ +

`-errors <num>`

+ +

+The -errors option instructs testfloat_ver to report +no more than the specified number of errors. +The argument to -errors must be a nonnegative decimal integer. +Once the specified number of error reports has been generated, the program +exits. +The default is -errors 20. +

+ +

+Against intuition, -errors 0 causes +testfloat_ver to continue for any number of errors. +

+ +

`-checkNaNs`

+ +

+The -checkNaNs option causes testfloat_ver to verify +the bitwise correctness of NaN results. +In order for this option to be sensible, testfloat_ver must have +been compiled so that its internal reference implementation of floating-point +(Berkeley SoftFloat) generates the proper NaN results for the system being +tested. +

+ +

`-checkInvInts`

+ +

+The -checkInvInts option causes testfloat_ver to +verify the bitwise correctness of integer results of invalid operations. +In order for this option to be sensible, testfloat_ver must have +been compiled so that its internal reference implementation of floating-point +(Berkeley SoftFloat) generates the proper integer results for the system being +tested. +

+ +

`-checkAll`

+ +

+Enables both -checkNaNs and -checkInvInts. +

+ +

`-precision32, -precision64, -precision80`

+ +

+When <function> is an 80-bit +double-extended-precision operation affected by rounding precision control, the +-precision32 option indicates that the rounding precision should +be 32 bits, equivalent to 32-bit single-precision. +Likewise, -precision64 indicates that the rounding precision +should be 64 bits, equivalent to 64-bit +double-precision, and -precision80 indicates that the rounding +precision should be the full 80 bits of the +double-extended-precision format. +All these options are ignored for operations not affected by rounding precision +control. +When rounding precision is applicable but not specified, the default assumption +is the full 80 bits, same as -precision80. +

+ +

`-rnear_even, -rnear_maxMag, -rminMag, -rmin, -rmax, -rodd`

+ +

+When <function> is an operation that requires +rounding, the -rnear_even option indicates that rounding should be +to nearest/even, -rnear_maxMag indicates rounding to +nearest/maximum magnitude (nearest-away), -rminMag indicates +rounding to minimum magnitude (toward zero), -rmin indicates +rounding to minimum (down, toward negative infinity), -rmax +indicates rounding to maximum (up, toward positive infinity), and +-rodd, if supported, indicates rounding to odd. +These options are ignored for operations that are exact and thus do not round. +When rounding mode is relevant but not specified, the default assumption is +rounding to nearest/even, same as -rnear_even. +

+ +

`-tininessbefore, -tininessafter`

+ +

+When <function> is an operation that requires +rounding, the -tininessbefore option indicates that tininess on +underflow should be detected before rounding, while -tininessafter +indicates that tininess on underflow should be detected after rounding. +These options are ignored for operations that are exact and thus do not round. +When the method of tininess detection matters but is not specified, the default +assumption is that tininess should be detected after rounding, same as +-tininessafter. +

+ +

`-notexact, -exact`

+ +

+When <function> is an operation that rounds to an +integer (either conversion to an integer type or a roundToInt +operation), the -notexact option indicates that the inexact +exception flag should never be raised, while -exact indicates that +the inexact exception flag should be raised when the result is inexact. +For other operations, these options are ignored. +If neither option is specified, the default assumption is that the +inexact exception flag should not be raised when rounding to an integer, +same as -notexact. +

+ + +

Input Format

+ +

+For a given <function> argument, the input format +expected by testfloat_ver is the same as the output generated by +program +testfloat_gen for +the same argument. +

+ +

+Input to testfloat_ver is expected to be text, with each line +containing the data for one test case. +The number of input lines thus equals the number of test cases. +A single test case is organized as follows: first are the operands for the +operation, next is the result value obtained, and last is a number indicating +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
+

+valid input could include these lines: +

+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 +the last hexadecimal number gives the exception flags that were raised by the +operation. +

+ +

+Note that, for floating-point values, the sign and exponent are at the +most-significant end of the number. +Thus, for the first number on the first line above, the leading hexadecimal +digits 3F9 are the sign and encoded exponent of the +64-bit floating-point value, and the remaining digits are the +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
+

+ + + + diff --git a/src/libs/softfloat-3e/testfloat/doc/testsoftfloat.html b/src/libs/softfloat-3e/testfloat/doc/testsoftfloat.html new file mode 100644 index 00000000..09e488b1 --- /dev/null +++ b/src/libs/softfloat-3e/testfloat/doc/testsoftfloat.html @@ -0,0 +1,236 @@ + + + + +testsoftfloat + + + + +

Berkeley TestFloat Release 3e: `testsoftfloat`

+ +

+John R. Hauser
+2018 January 20
+

+ + +

Overview

+ +

+The testsoftfloat program tests that a build of the Berkeley +SoftFloat library conforms to the IEEE Standard for Binary Floating-Point +Arithmetic as expected. +Program testsoftfloat is part of the Berkeley TestFloat package, a +small collection of programs for performing such tests. +For general information about TestFloat, as well as for basics about the +operation of testsoftfloat and how to interpret its output, see +file +TestFloat-general.html. +

+ +

+Note that, even if there are no bugs in the source code for SoftFloat (not +guaranteed), a build of SoftFloat might still fail due to an issue with the +build process, such as an incompatible compiler option or a compiler bug. +

+ +

+The testsoftfloat program will ordinarily test a function for all +five rounding modes defined by the IEEE Floating-Point Standard, one after the +other, plus possibly a sixth mode, round to odd (depending on the +options selected when testsoftfloat was compiled). +If an operation is not supposed to require rounding, it will by default be +tested only with the rounding mode set to near_even +(nearest/even). +In the same way, if an operation is affected by the way in which underflow +tininess is detected, testsoftfloat tests the function with +tininess detected both before rounding and after rounding. +For 80-bit double-extended-precision operations affected by +rounding precision control, testsoftfloat also tests the function +for all three rounding precision modes, one after the other. +Testing can be limited to a single rounding mode, a single tininess mode, +and/or a single rounding precision with appropriate command-line options. +

+ + +

Command Syntax

+ +

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

+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 function set. +The available options and function sets are documented below. +If testsoftfloat is executed without any arguments, a summary of +usage is written. +

+ + +

Options

+ +

+The 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. +

+ +

`-seed <num>`

+ +

+The -seed option sets the seed for the pseudo-random number +generator used for generating test cases. +The argument to -seed is a nonnegative integer. +Executing the same testsoftfloat program with the same arguments +(including the same pseudo-random number seed) should always perform the same +sequence of tests, whereas changing the pseudo-random number seed should result +in a different sequence of tests. +The default seed number is 1. +

+ +

`-level <num>`

+ +

`-errors <num>`

+ +

+The -errors option instructs testsoftfloat 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 integer. +Once the specified number of error reports has been generated, +testsoftfloat ends the current test and begins the next one, if +any. +The default is -errors 20. +

+ +

+Against intuition, -errors 0 causes +testsoftfloat 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 function to be repeatedly +tested. +Only one rounding mode and/or rounding precision can be tested in a single +execution. +If not specified, the rounding mode defaults to nearest/even. +For 80-bit double-extended-precision functions, the rounding +precision defaults to full double-extended precision. +The testing level is set to 2 by this option. +

+ +

`-precision32, -precision64, -precision80`

+ +

+For 80-bit double-extended-precision funcions affected by +rounding precision control, the -precision32 option restricts +testing to only the cases in which the rounding precision is +32 bits, equivalent to 32-bit single-precision. +The other rounding precision choices are not tested. +Likewise, -precision64 fixes the rounding precision to +64 bits, equivalent to 64-bit double-precision; +and -precision80 fixes the rounding precision to the full +80 bits of the double-extended-precision format. +All these options are ignored for operations not affected by rounding precision +control. +

+ +

`-rnear_even, -rnear_maxMag, -rminMag, -rmin, -rmax, -rodd`

+ +

`-tininessbefore, -tininessafter`

+ +

+The -tininessbefore option restricts testing to only the cases in +which tininess on underflow is detected before rounding. +Likewise, -tininessafter restricts testing to only the cases in +which tininess on underflow is detected after rounding. +

+ +

`-notexact, -exact`

+ +

+For functions that round to an integer (conversions to integer types and the +roundToInt functions), the -notexact option restricts +testing to only the cases for which the exact operand +(specifying whether the inexact exception flag may be raised) is +false. +Likewise, the -exact option restricts testing to only the cases +for which the exact operand is true. +

+ + +

Function Sets

+ +

+Just as testsoftfloat can test a function for all five or six +rounding modes in sequence, multiple functions can be tested with a single +execution of testsoftfloat. +Two sets are recognized: -all1 and -all2. +The set -all1 is 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
+

+ +

+For the purpose of deciding the number of operands of an operation, any +roundingMode and exact arguments are +ignored. +(Such arguments specify the rounding mode and whether the inexact +exception flag may be raised, respectively.) +Thus, functions that convert to integer type and the roundToInt +functions are included in the set of one-operand operations tested by +-all1. +

+ + + + diff --git a/src/libs/softfloat-3e/testfloat/doc/timesoftfloat.html b/src/libs/softfloat-3e/testfloat/doc/timesoftfloat.html new file mode 100644 index 00000000..8808fe61 --- /dev/null +++ b/src/libs/softfloat-3e/testfloat/doc/timesoftfloat.html @@ -0,0 +1,196 @@ + + + + +timesoftfloat + + + + +

Berkeley TestFloat Release 3e: `timesoftfloat`

+ +

+John R. Hauser
+2018 January 20
+

+ + +

Overview

+ +

+The timesoftfloat program provides a simple way to evaluate the +speed of the floating-point operations of the Berkeley SoftFloat library. +Program timesoftfloat is included with the Berkeley TestFloat +package, a small collection of programs for testing that an implementation of +floating-point conforms to the IEEE Standard for Binary Floating-Point +Arithmetic. +Although timesoftfloat does not test floating-point correctness +like the other TestFloat programs, nevertheless timesoftfloat is a +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 +separately for each of the five rounding modes defined by the IEEE +Floating-Point Standard, one after the other, plus possibly a sixth mode, +round to odd (depending on the options selected when +timesoftfloat was compiled). +If an operation is not supposed to require rounding, it will by default be +timed only with the rounding mode set to near_even (nearest/even). +In the same way, if an operation is affected by the way in which underflow +tininess is detected, timesoftfloat times the function with +tininess detected both before rounding and after rounding. +For 80-bit double-extended-precision operations affected by +rounding precision control, timesoftfloat also times the function +for each of the three rounding precision modes, one after the other. +Evaluation of a function can be limited to a single rounding mode, a single +tininess mode, and/or a single rounding precision with appropriate command-line +options. +

+ +

+For each function and mode evaluated, timesoftfloat reports the +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. +Your actual experience with SoftFloat may differ from the speeds reported by +timesoftfloat for all these reasons. +

+ +

+Note that the remainder operations for larger formats (f64_rem, +extF80_rem, and f128_rem) can be markedly slower than +other operations, particularly for double-extended-precision +(extF80_rem) and quadruple precision (f128_rem). +This is inherent to the remainder operation itself and is not a failing of the +SoftFloat implementation. +

+ + +

Command Syntax

+ +

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

+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 function set. +The available options and function sets are documented below. +If timesoftfloat is executed without any arguments, a summary of +usage is written. +

+ + +

Options

+ +

+The timesoftfloat 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. +

+ +

`-precision32, -precision64, -precision80`

+ +

+For 80-bit double-extended-precision funcions affected by +rounding precision control, the -precision32 option restricts +timing of an operation to only the cases in which the rounding precision is +32 bits, equivalent to 32-bit single-precision. +Other rounding precision choices are not timed. +Likewise, -precision64 fixes the rounding precision to +64 bits, equivalent to 64-bit double-precision; +and -precision80 fixes the rounding precision to the full +80 bits of the double-extended-precision format. +All these options are ignored for operations not affected by rounding precision +control. +

+ +

`-rnear_even, -rnear_maxMag, -rminMag, -rmin, -rmax, -rodd`

+ +

+The -rnear_even option restricts timing of an operation to only +the cases in which the rounding mode is nearest/even. +Other rounding mode choices are not timed. +Likewise, -rnear_maxMag forces rounding to nearest/maximum +magnitude (nearest-away), -rminMag forces rounding to minimum +magnitude (toward zero), -rmin forces rounding to minimum (down, +toward negative infinity), -rmax forces rounding to maximum (up, +toward positive infinity), and -rodd, if supported, forces +rounding to odd. +These options are ignored for operations that are exact and thus do not round. +

+ +

`-tininessbefore, -tininessafter`

+ +

+The -tininessbefore option restricts timing of an operation to +only the cases in which tininess on underflow is detected before rounding. +Likewise, -tininessafter restricts measurement to only the cases +in which tininess on underflow is detected after rounding. +

+ +

`-notexact, -exact`

+ +

+For functions that round to an integer (conversions to integer types and the +roundToInt functions), the -notexact option restricts +timing of an operation to only the cases for which the +exact operand (specifying whether the inexact +exception flag may be raised) is false. +Likewise, the -exact option restricts measurement to only the +cases for which the exact operand is true. +

+ + +

Function Sets

+ +

+Just as timesoftfloat can time a function for all five or six +rounding modes in sequence, multiple functions can be timed with a single +execution of timesoftfloat. +Three sets are recognized: +-all1, -all2, and -all. +The set -all1 is all one-operand operations, -all2 is +all two-operand operations, and -all is obviously all operations. +A function set is used in place of a function name in the +timesoftfloat command line, such as +

+timesoftfloat [<option>...] -all1
+

+ +

+ + + + -- cgit v1.2.3

Par Lab:		+Microsoft (Award #024263), Intel (Award #024894), and U.C. Discovery +(Award #DIG07-10227), with additional support from Par Lab affiliates Nokia, +NVIDIA, Oracle, and Samsung. +
ASPIRE Lab:		+DARPA PERFECT program (Award #HR0011-12-2-0016), with additional support from +ASPIRE industrial sponsor Intel and ASPIRE affiliates Google, Nokia, NVIDIA, +Oracle, and Samsung. +

+`testfloat_gen` +	+Generates test cases for a specific floating-point operation. +
+`testfloat_ver` +	+Verifies whether the results from executing a floating-point operation are as +expected. +
+`testfloat` +	+An all-in-one program that generates test cases, executes floating-point +operations, and verifies whether the results match expectations. +
+`testsoftfloat` +	+Like `testfloat`, but for testing SoftFloat. +
+`timesoftfloat` +	+A program for measuring the speed of SoftFloat (included in the TestFloat +package for convenience). +

`+00.000`	+0
`+0F.000`	1
`+10.000`	2
`+1E.3FF`	maximum finite value
`+1F.000`	+infinity

`-00.000`	−0
`-0F.000`	−1
`-10.000`	−2
`-1E.3FF`	minimum finite value (largest magnitude, but negative)
`-1F.000`	−infinity

`+00.xxx`	positive subnormal numbers
`+1F.xxx`	positive NaNs
`-00.xxx`	negative subnormal numbers
`-1F.xxx`	negative NaNs

32-bit single	64-bit double	128-bit quadruple

`+00.000000`	`+000.0000000000000`	`+0000.0000000000000000000000000000`	+0
`+7F.000000`	`+3FF.0000000000000`	`+3FFF.0000000000000000000000000000`	1
`+80.000000`	`+400.0000000000000`	`+4000.0000000000000000000000000000`	2
`+FE.7FFFFF`	`+7FE.FFFFFFFFFFFFF`	`+7FFE.FFFFFFFFFFFFFFFFFFFFFFFFFFFF`	maximum finite value
`+FF.000000`	`+7FF.0000000000000`	`+7FFF.0000000000000000000000000000`	+infinity

`-00.000000`	`-000.0000000000000`	`-0000.0000000000000000000000000000`	−0
`-7F.000000`	`-3FF.0000000000000`	`-3FFF.0000000000000000000000000000`	−1
`-80.000000`	`-400.0000000000000`	`-4000.0000000000000000000000000000`	−2
`-FE.7FFFFF`	`-7FE.FFFFFFFFFFFFF`	`-7FFE.FFFFFFFFFFFFFFFFFFFFFFFFFFFF`	minimum finite value
`-FF.000000`	`-7FF.0000000000000`	`-7FFF.0000000000000000000000000000`	−infinity

`+00.xxxxxx`	`+000.xxxxxxxxxxxxx`	`+0000.xxxxxxxxxxxxxxxxxxxxxxxxxxxx`	positive subnormals
`+FF.xxxxxx`	`+7FF.xxxxxxxxxxxxx`	`+7FFF.xxxxxxxxxxxxxxxxxxxxxxxxxxxx`	positive NaNs
`-00.xxxxxx`	`-000.xxxxxxxxxxxxx`	`-0000.xxxxxxxxxxxxxxxxxxxxxxxxxxxx`	negative subnormals
`-FF.xxxxxx`	`-7FF.xxxxxxxxxxxxx`	`-7FFF.xxxxxxxxxxxxxxxxxxxxxxxxxxxx`	negative NaNs

`+0000.0000000000000000`	+0
`+3FFF.8000000000000000`	1
`+4000.8000000000000000`	2
`+7FFE.FFFFFFFFFFFFFFFF`	maximum finite value
`+7FFF.8000000000000000`	+infinity

`-0000.0000000000000000`	−0
`-3FFF.8000000000000000`	−1
`-4000.8000000000000000`	−2
`-7FFE.FFFFFFFFFFFFFFFF`	minimum finite value
`-7FFF.8000000000000000`	−infinity

`v`	invalid exception
`i`	infinite exception (“divide by zero”)
`o`	overflow exception
`u`	underflow exception
`x`	inexact exception

`ui32`	unsigned 32-bit integers
`ui64`	unsigned 64-bit integers
`i32`	signed 32-bit integers
`i64`	signed 64-bit integers
`f16 [<num>]`	one or more 16-bit half-precision floating-point values
`f32 [<num>]`	one or more 32-bit single-precision floating-point values
`f64 [<num>]`	one or more 64-bit double-precision floating-point values
`extF80 [<num>]`	one or more 80-bit double-extended-precision floating-point +values
`f128 [<num>]`	one or more 128-bit quadruple-precision floating-point +values

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

Berkeley TestFloat Release 3e: General Documentation

Contents

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

History of Berkeley TestFloat, to Release 3e

Release 3e (2018 January)

Release 3d (2017 August)

Release 3c (2017 February)

Release 3b (2016 July)

Release 3a (2015 October)

Release 3 (2015 February)

Release 2c (2015 January)

Release 2a (1998 December)

Release 2 (1997 June)

Release 1a (1996 July)

Release 1 (1996 July)

Berkeley TestFloat Release 3e: Source Documentation

Contents

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

Berkeley TestFloat Release 3e: testfloat

Overview

Command Syntax

Options

-help

-list

-seed <num>

-level <num>

-errors <num>

-errorstop

-forever

-checkNaNs

-checkInvInts

-checkAll

-precision32, -precision64, -precision80

-rnear_even, -rnear_maxMag, -rminMag, -rmin, -rmax, -rodd

-tininessbefore, -tininessafter

Function Sets

Berkeley TestFloat Release 3e: testfloat_gen

Overview

Command Syntax

Options

-help

-prefix <text>

-seed <num>

-level <num>

-n <num>

-forever

-precision32, -precision64, -precision80

-rnear_even, -rnear_maxMag, -rminMag, -rmin, -rmax, -rodd

-tininessbefore, -tininessafter

-notexact, -exact

Output Format

Berkeley TestFloat Release 3e: testfloat_ver

6.1. Standard Headers `<stdbool.h>` and `<stdint.h>`

6.2. Standard Header `<fenv.h>`

6.4. Specializing the `testfloat` Program

Berkeley TestFloat Release 3e: `testfloat`

`-help`

`-list`

`-seed <num>`

`-level <num>`

`-errors <num>`

`-errorstop`

`-forever`

`-checkNaNs`

`-checkInvInts`

`-checkAll`

`-precision32, -precision64, -precision80`

`-rnear_even, -rnear_maxMag, -rminMag, -rmin, -rmax, -rodd`

`-tininessbefore, -tininessafter`

Berkeley TestFloat Release 3e: `testfloat_gen`

`-help`

`-prefix <text>`

`-seed <num>`

`-level <num>`

`-n <num>`

`-forever`

`-precision32, -precision64, -precision80`

`-rnear_even, -rnear_maxMag, -rminMag, -rmin, -rmax, -rodd`

`-tininessbefore, -tininessafter`

`-notexact, -exact`

Berkeley TestFloat Release 3e: `testfloat_ver`

`-help`

`-errors <num>`

`-checkNaNs`

`-checkInvInts`

`-checkAll`

`-precision32, -precision64, -precision80`

`-rnear_even, -rnear_maxMag, -rminMag, -rmin, -rmax, -rodd`

`-tininessbefore, -tininessafter`

`-notexact, -exact`

Berkeley TestFloat Release 3e: `testsoftfloat`

`-help`

`-seed <num>`

`-level <num>`

`-errors <num>`

`-errorstop`

`-forever`

`-precision32, -precision64, -precision80`

`-rnear_even, -rnear_maxMag, -rminMag, -rmin, -rmax, -rodd`

`-tininessbefore, -tininessafter`

`-notexact, -exact`

Berkeley TestFloat Release 3e: `timesoftfloat`

`-help`

`-precision32, -precision64, -precision80`

`-rnear_even, -rnear_maxMag, -rminMag, -rmin, -rmax, -rodd`

`-tininessbefore, -tininessafter`

`-notexact, -exact`