| |
| <HTML> |
| |
| <HEAD> |
| <TITLE>Berkeley TestFloat General Documentation</TITLE> |
| </HEAD> |
| |
| <BODY> |
| |
| <H1>Berkeley TestFloat Release 3e: General Documentation</H1> |
| |
| <P> |
| John R. Hauser<BR> |
| 2018 January 20<BR> |
| </P> |
| |
| |
| <H2>Contents</H2> |
| |
| <BLOCKQUOTE> |
| <TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0> |
| <COL WIDTH=25> |
| <COL WIDTH=*> |
| <TR><TD COLSPAN=2>1. Introduction</TD></TR> |
| <TR><TD COLSPAN=2>2. Limitations</TD></TR> |
| <TR><TD COLSPAN=2>3. Acknowledgments and License</TD></TR> |
| <TR><TD COLSPAN=2>4. What TestFloat Does</TD></TR> |
| <TR><TD COLSPAN=2>5. Executing TestFloat</TD></TR> |
| <TR><TD COLSPAN=2>6. Operations Tested by TestFloat</TD></TR> |
| <TR><TD></TD><TD>6.1. Conversion Operations</TD></TR> |
| <TR><TD></TD><TD>6.2. Basic Arithmetic Operations</TD></TR> |
| <TR><TD></TD><TD>6.3. Fused Multiply-Add Operations</TD></TR> |
| <TR><TD></TD><TD>6.4. Remainder Operations</TD></TR> |
| <TR><TD></TD><TD>6.5. Round-to-Integer Operations</TD></TR> |
| <TR><TD></TD><TD>6.6. Comparison Operations</TD></TR> |
| <TR><TD COLSPAN=2>7. Interpreting TestFloat Output</TD></TR> |
| <TR> |
| <TD COLSPAN=2>8. Variations Allowed by the IEEE Floating-Point Standard</TD> |
| </TR> |
| <TR><TD></TD><TD>8.1. Underflow</TD></TR> |
| <TR><TD></TD><TD>8.2. NaNs</TD></TR> |
| <TR><TD></TD><TD>8.3. Conversions to Integer</TD></TR> |
| <TR><TD COLSPAN=2>9. Contact Information</TD></TR> |
| </TABLE> |
| </BLOCKQUOTE> |
| |
| |
| <H2>1. Introduction</H2> |
| |
| <P> |
| 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: |
| <NOBR>16-bit</NOBR> half-precision, <NOBR>32-bit</NOBR> single-precision, |
| <NOBR>64-bit</NOBR> double-precision, <NOBR>80-bit</NOBR> |
| double-extended-precision, and/or <NOBR>128-bit</NOBR> quadruple-precision. |
| TestFloat cannot test decimal floating-point. |
| </P> |
| |
| <P> |
| Included in the TestFloat package are the <CODE>testsoftfloat</CODE> and |
| <CODE>timesoftfloat</CODE> 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, |
| <A HREF="http://www.jhauser.us/arithmetic/SoftFloat.html"><NOBR><CODE>http://www.jhauser.us/arithmetic/SoftFloat.html</CODE></NOBR></A>. |
| The <CODE>testsoftfloat</CODE> and <CODE>timesoftfloat</CODE> programs are |
| expected to be of interest only to people compiling the SoftFloat sources. |
| </P> |
| |
| <P> |
| 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. |
| </P> |
| |
| <P> |
| The current version of TestFloat is <NOBR>Release 3e</NOBR>. |
| This version differs from earlier releases 3b through 3d in only minor ways. |
| Compared to the original <NOBR>Release 3</NOBR>: |
| <UL> |
| <LI> |
| <NOBR>Release 3b</NOBR> added the ability to test the <NOBR>16-bit</NOBR> |
| half-precision format. |
| <LI> |
| <NOBR>Release 3c</NOBR> added the ability to test a rarely used rounding mode, |
| <I>round to odd</I>, also known as <I>jamming</I>. |
| <LI> |
| <NOBR>Release 3d</NOBR> modified the code for testing C arithmetic to |
| potentially include testing newer library functions <CODE>sqrtf</CODE>, |
| <CODE>sqrtl</CODE>, <CODE>fmaf</CODE>, <CODE>fma</CODE>, and <CODE>fmal</CODE>. |
| </UL> |
| This release adds a few more small improvements, including modifying the |
| expected behavior of rounding mode <CODE>odd</CODE> and fixing a minor bug in |
| the all-in-one <CODE>testfloat</CODE> program. |
| </P> |
| |
| <P> |
| Compared to Release 2c and earlier, the set of TestFloat programs, as well as |
| the programs’ arguments and behavior, changed some with |
| <NOBR>Release 3</NOBR>. |
| For more about the evolution of TestFloat releases, see |
| <A HREF="TestFloat-history.html"><NOBR><CODE>TestFloat-history.html</CODE></NOBR></A>. |
| </P> |
| |
| |
| <H2>2. Limitations</H2> |
| |
| <P> |
| TestFloat output is not always easily interpreted. |
| Detailed knowledge of the IEEE Floating-Point Standard and its vagaries is |
| needed to use TestFloat responsibly. |
| </P> |
| |
| <P> |
| 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, |
| <A HREF="http://www.jhauser.us/arithmetic/TestFloat.html"><NOBR><CODE>http://www.jhauser.us/arithmetic/TestFloat.html</CODE></NOBR></A>. |
| </P> |
| |
| |
| <H2>3. Acknowledgments and License</H2> |
| |
| <P> |
| The TestFloat package was written by me, <NOBR>John R.</NOBR> Hauser. |
| <NOBR>Release 3</NOBR> of TestFloat was a completely new implementation |
| supplanting earlier releases. |
| The project to create <NOBR>Release 3</NOBR> (now <NOBR>through 3e</NOBR>) 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: |
| <BLOCKQUOTE> |
| <TABLE> |
| <COL> |
| <COL WIDTH=10> |
| <COL> |
| <TR> |
| <TD VALIGN=TOP><NOBR>Par Lab:</NOBR></TD> |
| <TD></TD> |
| <TD> |
| 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. |
| </TD> |
| </TR> |
| <TR> |
| <TD VALIGN=TOP><NOBR>ASPIRE Lab:</NOBR></TD> |
| <TD></TD> |
| <TD> |
| 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. |
| </TD> |
| </TR> |
| </TABLE> |
| </BLOCKQUOTE> |
| </P> |
| |
| <P> |
| The following applies to the whole of TestFloat <NOBR>Release 3e</NOBR> as well |
| as to each source file individually. |
| </P> |
| |
| <P> |
| Copyright 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018 The Regents of the |
| University of California. |
| All rights reserved. |
| </P> |
| |
| <P> |
| Redistribution and use in source and binary forms, with or without |
| modification, are permitted provided that the following conditions are met: |
| <OL> |
| |
| <LI> |
| <P> |
| Redistributions of source code must retain the above copyright notice, this |
| list of conditions, and the following disclaimer. |
| </P> |
| |
| <LI> |
| <P> |
| 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. |
| </P> |
| |
| <LI> |
| <P> |
| 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. |
| </P> |
| |
| </OL> |
| </P> |
| |
| <P> |
| 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. |
| </P> |
| |
| |
| <H2>4. What TestFloat Does</H2> |
| |
| <P> |
| 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. |
| </P> |
| |
| <P> |
| 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, |
| <A HREF="http://www.jhauser.us/arithmetic/TestFloat.html"><NOBR><CODE>http://www.jhauser.us/arithmetic/TestFloat.html</CODE></NOBR></A>. |
| </P> |
| |
| <P> |
| NOTE!<BR> |
| 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. |
| </P> |
| |
| <P> |
| For each operation, TestFloat can test all five rounding modes defined by the |
| IEEE Floating-Point Standard, plus possibly a sixth mode, <I>round to odd</I> |
| (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 <I>inexact</I> flag. |
| TestFloat does not attempt to verify that the floating-point exception flags |
| are actually implemented as sticky flags. |
| </P> |
| |
| <P> |
| For the <NOBR>80-bit</NOBR> 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 <NOBR>32 bits</NOBR>, equivalent to |
| single-precision, to <NOBR>64 bits</NOBR>, equivalent to double-precision, or |
| to the full <NOBR>80 bits</NOBR> 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. |
| </P> |
| |
| <P> |
| 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 <NOBR>section 8</NOBR> below, <I>Variations Allowed by the IEEE |
| Floating-Point Standard</I>, plus the <CODE>-checkNaNs</CODE> and |
| <CODE>-checkInvInts</CODE> options documented for programs |
| <CODE>testfloat_ver</CODE> and <CODE>testfloat</CODE>. |
| </P> |
| |
| <P> |
| 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 |
| <A HREF="http://www.jhauser.us/arithmetic/SoftFloat.html"><NOBR><CODE>http://www.jhauser.us/arithmetic/SoftFloat.html</CODE></NOBR></A>. |
| </P> |
| |
| <P> |
| For testing SoftFloat itself, the TestFloat package includes a |
| <CODE>testsoftfloat</CODE> program that compares SoftFloat’s |
| floating-point against <EM>another</EM> 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. |
| </P> |
| |
| |
| <H2>5. Executing TestFloat</H2> |
| |
| <P> |
| The TestFloat package consists of five programs, all intended to be executed |
| from a command-line interpreter: |
| <BLOCKQUOTE> |
| <TABLE> |
| <TR> |
| <TD> |
| <A HREF="testfloat_gen.html"><CODE>testfloat_gen</CODE></A><CODE> </CODE> |
| </TD> |
| <TD> |
| Generates test cases for a specific floating-point operation. |
| </TD> |
| </TR> |
| <TR> |
| <TD> |
| <A HREF="testfloat_ver.html"><CODE>testfloat_ver</CODE></A> |
| </TD> |
| <TD> |
| Verifies whether the results from executing a floating-point operation are as |
| expected. |
| </TD> |
| </TR> |
| <TR> |
| <TD> |
| <A HREF="testfloat.html"><CODE>testfloat</CODE></A> |
| </TD> |
| <TD> |
| An all-in-one program that generates test cases, executes floating-point |
| operations, and verifies whether the results match expectations. |
| </TD> |
| </TR> |
| <TR> |
| <TD> |
| <A HREF="testsoftfloat.html"><CODE>testsoftfloat</CODE></A><CODE> </CODE> |
| </TD> |
| <TD> |
| Like <CODE>testfloat</CODE>, but for testing SoftFloat. |
| </TD> |
| </TR> |
| <TR> |
| <TD> |
| <A HREF="timesoftfloat.html"><CODE>timesoftfloat</CODE></A><CODE> </CODE> |
| </TD> |
| <TD> |
| A program for measuring the speed of SoftFloat (included in the TestFloat |
| package for convenience). |
| </TD> |
| </TR> |
| </TABLE> |
| </BLOCKQUOTE> |
| Each program has its own page of documentation that can be opened through the |
| links in the table above. |
| </P> |
| |
| <P> |
| To test a floating-point implementation other than SoftFloat, one of three |
| different methods can be used. |
| The first method pipes output from <CODE>testfloat_gen</CODE> to a program |
| that: |
| <NOBR>(a) reads</NOBR> the incoming test cases, <NOBR>(b) invokes</NOBR> the |
| floating-point operation being tested, and <NOBR>(c) writes</NOBR> the |
| operation results to output. |
| These results can then be piped to <CODE>testfloat_ver</CODE> to be checked for |
| correctness. |
| Assuming a vertical bar (<CODE>|</CODE>) indicates a pipe between programs, the |
| complete process could be written as a single command like so: |
| <BLOCKQUOTE> |
| <PRE> |
| testfloat_gen ... <<I>type</I>> | <<I>program-that-invokes-op</I>> | testfloat_ver ... <<I>function</I>> |
| </PRE> |
| </BLOCKQUOTE> |
| 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 |
| <CODE>-prefix</CODE> option of <CODE>testfloat_gen</CODE> can communicate |
| parameters through the pipe. |
| </P> |
| |
| <P> |
| A second method for running TestFloat is similar but has |
| <CODE>testfloat_gen</CODE> supply not only the test inputs but also the |
| expected results for each case. |
| With this additional information, the job done by <CODE>testfloat_ver</CODE> |
| can be folded into the invoking program to give the following command: |
| <BLOCKQUOTE> |
| <PRE> |
| testfloat_gen ... <<I>function</I>> | <<I>program-that-invokes-op-and-compares-results</I>> |
| </PRE> |
| </BLOCKQUOTE> |
| 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 |
| <CODE>testfloat_ver</CODE> check and report suspected errors (first method) or |
| to include this step in the invoking program (second method). |
| </P> |
| |
| <P> |
| The third way to use TestFloat is the all-in-one <CODE>testfloat</CODE> |
| 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, <CODE>testfloat</CODE> must be compiled to |
| contain the method for invoking the floating-point operations to test. |
| Each build of <CODE>testfloat</CODE> is therefore capable of testing |
| <EM>only</EM> the floating-point implementation it was built to invoke. |
| To test a new implementation of floating-point, a new <CODE>testfloat</CODE> |
| must be created, linked to that specific implementation. |
| By comparison, the <CODE>testfloat_gen</CODE> and <CODE>testfloat_ver</CODE> |
| 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 <CODE>testfloat_gen</CODE>. |
| </P> |
| |
| <P> |
| Program <CODE>testsoftfloat</CODE> is another all-in-one program specifically |
| for testing SoftFloat. |
| </P> |
| |
| <P> |
| Programs <CODE>testfloat_ver</CODE>, <CODE>testfloat</CODE>, and |
| <CODE>testsoftfloat</CODE> 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. |
| </P> |
| |
| |
| <H2>6. Operations Tested by TestFloat</H2> |
| |
| <P> |
| TestFloat can test all operations required by the original 1985 IEEE |
| Floating-Point Standard except for conversions to and from decimal. |
| These operations are: |
| <UL> |
| <LI> |
| conversions among the supported floating-point formats, and also between |
| integers (<NOBR>32-bit</NOBR> and <NOBR>64-bit</NOBR>, signed and unsigned) and |
| any of the floating-point formats; |
| <LI> |
| for each floating-point format, the usual addition, subtraction, |
| multiplication, division, and square root operations; |
| <LI> |
| for each format, the floating-point remainder operation defined by the IEEE |
| Standard; |
| <LI> |
| for each format, a “round to integer” operation that rounds to the |
| nearest integer value in the same format; and |
| <LI> |
| comparisons between two values in the same floating-point format. |
| </UL> |
| In addition, TestFloat can also test |
| <UL> |
| <LI> |
| for each floating-point format except <NOBR>80-bit</NOBR> |
| double-extended-precision, the fused multiply-add operation defined by the 2008 |
| IEEE Standard. |
| </UL> |
| </P> |
| |
| <P> |
| More information about all these operations is given below. |
| In the operation names used by TestFloat, <NOBR>16-bit</NOBR> half-precision is |
| called <CODE>f16</CODE>, <NOBR>32-bit</NOBR> single-precision is |
| <CODE>f32</CODE>, <NOBR>64-bit</NOBR> double-precision is <CODE>f64</CODE>, |
| <NOBR>80-bit</NOBR> double-extended-precision is <CODE>extF80</CODE>, and |
| <NOBR>128-bit</NOBR> quadruple-precision is <CODE>f128</CODE>. |
| TestFloat generally uses the same names for operations as Berkeley SoftFloat, |
| except that TestFloat’s names never include the <CODE>M</CODE> that |
| SoftFloat uses to indicate that values are passed through pointers. |
| </P> |
| |
| <H3>6.1. Conversion Operations</H3> |
| |
| <P> |
| All conversions among the floating-point formats and all conversions between a |
| floating-point format and <NOBR>32-bit</NOBR> and <NOBR>64-bit</NOBR> integers |
| can be tested. |
| The conversion operations are: |
| <BLOCKQUOTE> |
| <PRE> |
| 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 |
| </PRE> |
| </BLOCKQUOTE> |
| Abbreviations <CODE>ui32</CODE> and <CODE>ui64</CODE> indicate |
| <NOBR>32-bit</NOBR> and <NOBR>64-bit</NOBR> unsigned integer types, while |
| <CODE>i32</CODE> and <CODE>i64</CODE> 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 <NOBR>32-bit</NOBR> integers to <NOBR>64-bit</NOBR> |
| double-precision or to any larger floating-point format are also exact, as are |
| conversions from <NOBR>64-bit</NOBR> integers to <NOBR>80-bit</NOBR> |
| double-extended-precision and <NOBR>128-bit</NOBR> quadruple-precision. |
| </P> |
| |
| <P> |
| For the all-in-one <CODE>testfloat</CODE> program, this list of conversion |
| operations requires amendment. |
| For <CODE>testfloat</CODE> only, conversions to an integer type have names that |
| explicitly specify the rounding mode and treatment of inexactness. |
| Thus, instead of |
| <BLOCKQUOTE> |
| <PRE> |
| <<I>float</I>>_to_<<I>int</I>> |
| </PRE> |
| </BLOCKQUOTE> |
| as listed above, operations converting to integer type have names of these |
| forms: |
| <BLOCKQUOTE> |
| <PRE> |
| <<I>float</I>>_to_<<I>int</I>>_r_<<I>round</I>> |
| <<I>float</I>>_to_<<I>int</I>>_rx_<<I>round</I>> |
| </PRE> |
| </BLOCKQUOTE> |
| The <CODE><<I>round</I>></CODE> component is one of |
| ‘<CODE>near_even</CODE>’, ‘<CODE>near_maxMag</CODE>’, |
| ‘<CODE>minMag</CODE>’, ‘<CODE>min</CODE>’, or |
| ‘<CODE>max</CODE>’, choosing the rounding mode. |
| Any other indication of rounding mode is ignored. |
| The operations with ‘<CODE>_r_</CODE>’ in their names never raise |
| the <I>inexact</I> exception, while those with ‘<CODE>_rx_</CODE>’ |
| raise the <I>inexact</I> exception whenever the result is not exact. |
| </P> |
| |
| <P> |
| TestFloat assumes that conversions from floating-point to an integer type |
| should raise the <I>invalid</I> exception if the input cannot be rounded to an |
| integer representable in the result format. |
| In such a circumstance: |
| <UL> |
| |
| <LI> |
| <P> |
| 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. |
| </P> |
| |
| <LI> |
| <P> |
| 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. |
| </P> |
| |
| </UL> |
| Conversions to integer types are expected never to raise the <I>overflow</I> |
| exception. |
| </P> |
| |
| <H3>6.2. Basic Arithmetic Operations</H3> |
| |
| <P> |
| The following standard arithmetic operations can be tested: |
| <BLOCKQUOTE> |
| <PRE> |
| 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 |
| </PRE> |
| </BLOCKQUOTE> |
| The double-extended-precision (<CODE>extF80</CODE>) operations can be rounded |
| to reduced precision under rounding precision control. |
| </P> |
| |
| <H3>6.3. Fused Multiply-Add Operations</H3> |
| |
| <P> |
| For all floating-point formats except <NOBR>80-bit</NOBR> |
| 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: |
| <BLOCKQUOTE> |
| <PRE> |
| f16_mulAdd |
| f32_mulAdd |
| f64_mulAdd |
| f128_mulAdd |
| </PRE> |
| </BLOCKQUOTE> |
| </P> |
| |
| <P> |
| If one of the multiplication operands is infinite and the other is zero, |
| TestFloat expects the fused multiply-add operation to raise the <I>invalid</I> |
| exception even if the third operand is a quiet NaN. |
| </P> |
| |
| <H3>6.4. Remainder Operations</H3> |
| |
| <P> |
| For each format, TestFloat can test the IEEE Standard’s remainder |
| operation. |
| These operations are: |
| <BLOCKQUOTE> |
| <PRE> |
| f16_rem |
| f32_rem |
| f64_rem |
| extF80_rem |
| f128_rem |
| </PRE> |
| </BLOCKQUOTE> |
| The remainder operations are always exact and so require no rounding. |
| </P> |
| |
| <H3>6.5. Round-to-Integer Operations</H3> |
| |
| <P> |
| For each format, TestFloat can test the IEEE Standard’s round-to-integer |
| operation. |
| For most TestFloat programs, these operations are: |
| <BLOCKQUOTE> |
| <PRE> |
| f16_roundToInt |
| f32_roundToInt |
| f64_roundToInt |
| extF80_roundToInt |
| f128_roundToInt |
| </PRE> |
| </BLOCKQUOTE> |
| </P> |
| |
| <P> |
| Just as for conversions to integer types (<NOBR>section 6.1</NOBR> above), the |
| all-in-one <CODE>testfloat</CODE> program is again an exception. |
| For <CODE>testfloat</CODE> only, the round-to-integer operations have names of |
| these forms: |
| <BLOCKQUOTE> |
| <PRE> |
| <<I>float</I>>_roundToInt_r_<<I>round</I>> |
| <<I>float</I>>_roundToInt_x |
| </PRE> |
| </BLOCKQUOTE> |
| For the ‘<CODE>_r_</CODE>’ versions, the <I>inexact</I> exception |
| is never raised, and the <CODE><<I>round</I>></CODE> component specifies |
| the rounding mode as one of ‘<CODE>near_even</CODE>’, |
| ‘<CODE>near_maxMag</CODE>’, ‘<CODE>minMag</CODE>’, |
| ‘<CODE>min</CODE>’, or ‘<CODE>max</CODE>’. |
| The usual indication of rounding mode is ignored. |
| In contrast, the ‘<CODE>_x</CODE>’ versions accept the usual |
| indication of rounding mode and raise the <I>inexact</I> exception whenever the |
| result is not exact. |
| This irregular system follows the IEEE Standard’s particular |
| specification for the round-to-integer operations. |
| </P> |
| |
| <H3>6.6. Comparison Operations</H3> |
| |
| <P> |
| The following floating-point comparison operations can be tested: |
| <BLOCKQUOTE> |
| <PRE> |
| 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 |
| </PRE> |
| </BLOCKQUOTE> |
| The abbreviation <CODE>eq</CODE> stands for “equal” (=), |
| <CODE>le</CODE> stands for “less than or equal” (≤), and |
| <CODE>lt</CODE> stands for “less than” (<). |
| </P> |
| |
| <P> |
| The IEEE Standard specifies that, by default, the less-than-or-equal and |
| less-than comparisons raise the <I>invalid</I> exception if either input is any |
| kind of NaN. |
| The equality comparisons, on the other hand, are defined by default to raise |
| the <I>invalid</I> exception only for signaling NaNs, not for quiet NaNs. |
| For completeness, the following additional operations can be tested if |
| supported: |
| <BLOCKQUOTE> |
| <PRE> |
| 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 |
| </PRE> |
| </BLOCKQUOTE> |
| The <CODE>signaling</CODE> equality comparisons are identical to the standard |
| operations except that the <I>invalid</I> exception should be raised for any |
| NaN input. |
| Similarly, the <CODE>quiet</CODE> comparison operations should be identical to |
| their counterparts except that the <I>invalid</I> exception is not raised for |
| quiet NaNs. |
| </P> |
| |
| <P> |
| Obviously, no comparison operations ever require rounding. |
| Any rounding mode is ignored. |
| </P> |
| |
| |
| <H2>7. Interpreting TestFloat Output</H2> |
| |
| <P> |
| 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: |
| <UL> |
| <LI> |
| 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. |
| <LI> |
| 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. |
| <LI> |
| The TestFloat program may not work properly, reporting differences that do not |
| exist. |
| <LI> |
| Lastly, the floating-point being tested could actually be faulty. |
| </UL> |
| 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 <NOBR>section 8</NOBR>, <I>Variations Allowed by the IEEE |
| Floating-Point Standard</I>. |
| </P> |
| |
| <P> |
| 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. |
| </P> |
| |
| <P> |
| Each error reported is of the form: |
| <BLOCKQUOTE> |
| <PRE> |
| <<I>inputs</I>> => <<I>observed-output</I>> expected: <<I>expected-output</I>> |
| </PRE> |
| </BLOCKQUOTE> |
| The <CODE><<I>inputs</I>></CODE> 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. |
| </P> |
| |
| <P> |
| For example, two typical error lines could be |
| <BLOCKQUOTE> |
| <PRE> |
| -00.7FFF00 -7F.000100 => +01.000000 ...ux expected: +01.000000 ....x |
| +81.000004 +00.1FFFFF => +01.000000 ...ux expected: +01.000000 ....x |
| </PRE> |
| </BLOCKQUOTE> |
| In the first line, the inputs are <CODE>-00.7FFF00</CODE> and |
| <CODE>-7F.000100</CODE>, and the observed result is <CODE>+01.000000</CODE> |
| with flags <CODE>...ux</CODE>. |
| The trusted emulation result is the same but with different flags, |
| <CODE>....x</CODE>. |
| Items such as <CODE>-00.7FFF00</CODE> composed of a sign character |
| <NOBR>(<CODE>+</CODE>/<CODE>-</CODE>)</NOBR>, hexadecimal digits, and a single |
| period represent floating-point values (here <NOBR>32-bit</NOBR> |
| single-precision). |
| The two instances above were reported as errors because the exception flag |
| results differ. |
| </P> |
| |
| <P> |
| Aside from the exception flags, there are ten data types that may be |
| represented. |
| Five are floating-point types: <NOBR>16-bit</NOBR> half-precision, |
| <NOBR>32-bit</NOBR> single-precision, <NOBR>64-bit</NOBR> double-precision, |
| <NOBR>80-bit</NOBR> double-extended-precision, and <NOBR>128-bit</NOBR> |
| quadruple-precision. |
| The remaining five types are <NOBR>32-bit</NOBR> and <NOBR>64-bit</NOBR> |
| unsigned integers, <NOBR>32-bit</NOBR> and <NOBR>64-bit</NOBR> |
| two’s-complement signed integers, and Boolean values (the results of |
| comparison operations). |
| Boolean values are represented as a single character, either a <CODE>0</CODE> |
| (false) or a <CODE>1</CODE> (true). |
| A <NOBR>32-bit</NOBR> integer is represented as 8 hexadecimal digits. |
| Thus, for a signed <NOBR>32-bit</NOBR> integer, <CODE>FFFFFFFF</CODE> is |
| −1, and <CODE>7FFFFFFF</CODE> is the largest positive value. |
| <NOBR>64-bit</NOBR> integers are the same except with 16 hexadecimal digits. |
| </P> |
| |
| <P> |
| Floating-point values are written decomposed into their sign, encoded exponent, |
| and encoded significand. |
| First is the sign character <NOBR>(<CODE>+</CODE> or <CODE>-</CODE>),</NOBR> |
| followed by the encoded exponent in hexadecimal, then a period |
| (<CODE>.</CODE>), and lastly the encoded significand in hexadecimal. |
| </P> |
| |
| <P> |
| For <NOBR>16-bit</NOBR> half-precision, notable values include: |
| <BLOCKQUOTE> |
| <TABLE CELLSPACING=0 CELLPADDING=0> |
| <TR><TD><CODE>+00.000 </CODE></TD><TD>+0</TD></TR> |
| <TR><TD><CODE>+0F.000</CODE></TD><TD> 1</TD></TR> |
| <TR><TD><CODE>+10.000</CODE></TD><TD> 2</TD></TR> |
| <TR><TD><CODE>+1E.3FF</CODE></TD><TD>maximum finite value</TD></TR> |
| <TR><TD><CODE>+1F.000</CODE></TD><TD>+infinity</TD></TR> |
| <TR><TD> </TD></TR> |
| <TR><TD><CODE>-00.000</CODE></TD><TD>−0</TD></TR> |
| <TR><TD><CODE>-0F.000</CODE></TD><TD>−1</TD></TR> |
| <TR><TD><CODE>-10.000</CODE></TD><TD>−2</TD></TR> |
| <TR> |
| <TD><CODE>-1E.3FF</CODE></TD> |
| <TD>minimum finite value (largest magnitude, but negative)</TD> |
| </TR> |
| <TR><TD><CODE>-1F.000</CODE></TD><TD>−infinity</TD></TR> |
| </TABLE> |
| </BLOCKQUOTE> |
| Certain categories are easily distinguished (assuming the <CODE>x</CODE>s are |
| not all 0): |
| <BLOCKQUOTE> |
| <TABLE CELLSPACING=0 CELLPADDING=0> |
| <TR> |
| <TD><CODE>+00.xxx </CODE></TD> |
| <TD>positive subnormal numbers</TD> |
| </TR> |
| <TR><TD><CODE>+1F.xxx</CODE></TD><TD>positive NaNs</TD></TR> |
| <TR><TD><CODE>-00.xxx</CODE></TD><TD>negative subnormal numbers</TD></TR> |
| <TR><TD><CODE>-1F.xxx</CODE></TD><TD>negative NaNs</TD></TR> |
| </TABLE> |
| </BLOCKQUOTE> |
| </P> |
| |
| <P> |
| Likewise for other formats: |
| <BLOCKQUOTE> |
| <TABLE CELLSPACING=0 CELLPADDING=0> |
| <TR><TD>32-bit single</TD><TD>64-bit double</TD><TD>128-bit quadruple</TD></TR> |
| <TR><TD> </TD></TR> |
| <TR> |
| <TD><CODE>+00.000000 </CODE></TD> |
| <TD><CODE>+000.0000000000000 </CODE></TD> |
| <TD><CODE>+0000.0000000000000000000000000000 </CODE></TD> |
| <TD>+0</TD> |
| </TR> |
| <TR> |
| <TD><CODE>+7F.000000</CODE></TD> |
| <TD><CODE>+3FF.0000000000000</CODE></TD> |
| <TD><CODE>+3FFF.0000000000000000000000000000</CODE></TD> |
| <TD> 1</TD> |
| </TR> |
| <TR> |
| <TD><CODE>+80.000000</CODE></TD> |
| <TD><CODE>+400.0000000000000</CODE></TD> |
| <TD><CODE>+4000.0000000000000000000000000000</CODE></TD> |
| <TD> 2</TD> |
| </TR> |
| <TR> |
| <TD><CODE>+FE.7FFFFF</CODE></TD> |
| <TD><CODE>+7FE.FFFFFFFFFFFFF</CODE></TD> |
| <TD><CODE>+7FFE.FFFFFFFFFFFFFFFFFFFFFFFFFFFF</CODE></TD> |
| <TD>maximum finite value</TD> |
| </TR> |
| <TR> |
| <TD><CODE>+FF.000000</CODE></TD> |
| <TD><CODE>+7FF.0000000000000</CODE></TD> |
| <TD><CODE>+7FFF.0000000000000000000000000000</CODE></TD> |
| <TD>+infinity</TD> |
| </TR> |
| <TR><TD> </TD></TR> |
| <TR> |
| <TD><CODE>-00.000000 </CODE></TD> |
| <TD><CODE>-000.0000000000000 </CODE></TD> |
| <TD><CODE>-0000.0000000000000000000000000000 </CODE></TD> |
| <TD>−0</TD> |
| </TR> |
| <TR> |
| <TD><CODE>-7F.000000</CODE></TD> |
| <TD><CODE>-3FF.0000000000000</CODE></TD> |
| <TD><CODE>-3FFF.0000000000000000000000000000</CODE></TD> |
| <TD>−1</TD> |
| </TR> |
| <TR> |
| <TD><CODE>-80.000000</CODE></TD> |
| <TD><CODE>-400.0000000000000</CODE></TD> |
| <TD><CODE>-4000.0000000000000000000000000000</CODE></TD> |
| <TD>−2</TD> |
| </TR> |
| <TR> |
| <TD><CODE>-FE.7FFFFF</CODE></TD> |
| <TD><CODE>-7FE.FFFFFFFFFFFFF</CODE></TD> |
| <TD><CODE>-7FFE.FFFFFFFFFFFFFFFFFFFFFFFFFFFF</CODE></TD> |
| <TD>minimum finite value</TD> |
| </TR> |
| <TR> |
| <TD><CODE>-FF.000000</CODE></TD> |
| <TD><CODE>-7FF.0000000000000</CODE></TD> |
| <TD><CODE>-7FFF.0000000000000000000000000000</CODE></TD> |
| <TD>−infinity</TD> |
| </TR> |
| <TR><TD> </TD></TR> |
| <TR> |
| <TD><CODE>+00.xxxxxx</CODE></TD> |
| <TD><CODE>+000.xxxxxxxxxxxxx</CODE></TD> |
| <TD><CODE>+0000.xxxxxxxxxxxxxxxxxxxxxxxxxxxx</CODE></TD> |
| <TD>positive subnormals</TD> |
| </TR> |
| <TR> |
| <TD><CODE>+FF.xxxxxx</CODE></TD> |
| <TD><CODE>+7FF.xxxxxxxxxxxxx</CODE></TD> |
| <TD><CODE>+7FFF.xxxxxxxxxxxxxxxxxxxxxxxxxxxx</CODE></TD> |
| <TD>positive NaNs</TD> |
| </TR> |
| <TR> |
| <TD><CODE>-00.xxxxxx</CODE></TD> |
| <TD><CODE>-000.xxxxxxxxxxxxx</CODE></TD> |
| <TD><CODE>-0000.xxxxxxxxxxxxxxxxxxxxxxxxxxxx</CODE></TD> |
| <TD>negative subnormals</TD> |
| </TR> |
| <TR> |
| <TD><CODE>-FF.xxxxxx</CODE></TD> |
| <TD><CODE>-7FF.xxxxxxxxxxxxx</CODE></TD> |
| <TD><CODE>-7FFF.xxxxxxxxxxxxxxxxxxxxxxxxxxxx</CODE></TD> |
| <TD>negative NaNs</TD> |
| </TR> |
| </TABLE> |
| </BLOCKQUOTE> |
| </P> |
| |
| <P> |
| The <NOBR>80-bit</NOBR> 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 <NOBR>80-bit</NOBR> |
| 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 <NOBR>80-bit</NOBR> |
| double-extended-precision as follows (note the leading <CODE>8</CODE> digit in |
| the significands): |
| <BLOCKQUOTE> |
| <TABLE CELLSPACING=0 CELLPADDING=0> |
| <TR> |
| <TD><CODE>+0000.0000000000000000 </CODE></TD> |
| <TD>+0</TD> |
| </TR> |
| <TR><TD><CODE>+3FFF.8000000000000000</CODE></TD><TD> 1</TD></TR> |
| <TR><TD><CODE>+4000.8000000000000000</CODE></TD><TD> 2</TD></TR> |
| <TR> |
| <TD><CODE>+7FFE.FFFFFFFFFFFFFFFF</CODE></TD> |
| <TD>maximum finite value</TD> |
| </TR> |
| <TR><TD><CODE>+7FFF.8000000000000000</CODE></TD><TD>+infinity</TD></TR> |
| <TR><TD> </TD></TR> |
| <TR><TD><CODE>-0000.0000000000000000</CODE></TD><TD>−0</TD></TR> |
| <TR><TD><CODE>-3FFF.8000000000000000</CODE></TD><TD>−1</TD></TR> |
| <TR><TD><CODE>-4000.8000000000000000</CODE></TD><TD>−2</TD></TR> |
| <TR> |
| <TD><CODE>-7FFE.FFFFFFFFFFFFFFFF</CODE></TD> |
| <TD>minimum finite value</TD> |
| </TR> |
| <TR><TD><CODE>-7FFF.8000000000000000</CODE></TD><TD>−infinity</TD></TR> |
| </TABLE> |
| </BLOCKQUOTE> |
| </P> |
| |
| <P> |
| Lastly, exception flag values are represented by five characters, one character |
| per flag. |
| Each flag is written as either a letter or a period (<CODE>.</CODE>) 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: |
| <BLOCKQUOTE> |
| <TABLE CELLSPACING=0 CELLPADDING=0> |
| <TR> |
| <TD><CODE>v </CODE></TD> |
| <TD><I>invalid</I> exception</TD> |
| </TR> |
| <TR> |
| <TD><CODE>i</CODE></TD> |
| <TD><I>infinite</I> exception (“divide by zero”)</TD> |
| </TR> |
| <TR><TD><CODE>o</CODE></TD><TD><I>overflow</I> exception</TD></TR> |
| <TR><TD><CODE>u</CODE></TD><TD><I>underflow</I> exception</TD></TR> |
| <TR><TD><CODE>x</CODE></TD><TD><I>inexact</I> exception</TD></TR> |
| </TABLE> |
| </BLOCKQUOTE> |
| For example, the notation <CODE>...ux</CODE> indicates that the |
| <I>underflow</I> and <I>inexact</I> exception flags were set and that the other |
| three flags (<I>invalid</I>, <I>infinite</I>, and <I>overflow</I>) were not |
| set. |
| The exception flags are always written following the value returned as the |
| result of the operation. |
| </P> |
| |
| |
| <H2>8. Variations Allowed by the IEEE Floating-Point Standard</H2> |
| |
| <P> |
| 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. |
| </P> |
| |
| <H3>8.1. Underflow</H3> |
| |
| <P> |
| The standard specifies that the <I>underflow</I> exception flag is to be raised |
| when two conditions are met simultaneously: |
| <NOBR>(1) <I>tininess</I></NOBR> and <NOBR>(2) <I>loss of accuracy</I></NOBR>. |
| </P> |
| |
| <P> |
| 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 <CODE>-tininessbefore</CODE> and |
| <CODE>-tininessafter</CODE> 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. |
| </P> |
| |
| <P> |
| 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 <I>inexact result</I> or as a |
| <I>denormalization loss</I>; |
| 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. |
| </P> |
| |
| <H3>8.2. NaNs</H3> |
| |
| <P> |
| 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 |
| <EM>which</EM> NaN to return in each situation. |
| </P> |
| |
| <P> |
| 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 <CODE>-checkNaNs</CODE> option of |
| programs <CODE>testfloat_ver</CODE> and <CODE>testfloat</CODE>. |
| 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. |
| </P> |
| |
| <H3>8.3. Conversions to Integer</H3> |
| |
| <P> |
| 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 <I>invalid</I> exception can be raised |
| or an unspecified alternative mechanism may be used to signal such cases. |
| </P> |
| |
| <P> |
| TestFloat assumes that conversions to integer will raise the <I>invalid</I> |
| 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 |
| <NOBR>section 6.1</NOBR>, <I>Conversion Operations</I>. |
| If option <CODE>-checkInvInts</CODE> is selected with programs |
| <CODE>testfloat_ver</CODE> and <CODE>testfloat</CODE>, 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. |
| </P> |
| |
| |
| <H2>9. Contact Information</H2> |
| |
| <P> |
| 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 |
| <A HREF="http://www.jhauser.us/arithmetic/TestFloat.html"><NOBR><CODE>http://www.jhauser.us/arithmetic/TestFloat.html</CODE></NOBR></A>. |
| </P> |
| |
| |
| </BODY> |
| |
