<HTML> <HEAD> <TITLE>testfloat_ver</TITLE> </HEAD> <BODY> <H1>Berkeley TestFloat Release 3e: <CODE>testfloat_ver</CODE></H1> <P> John R. Hauser<BR> 2018 January 20<BR> </P> <H2>Overview</H2> <P> The <CODE>testfloat_ver</CODE> 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. <CODE>testfloat_ver</CODE> is part of the Berkeley TestFloat package, a small collection of programs for performing such tests. For general information about TestFloat, see file <A HREF="TestFloat-general.html"><NOBR><CODE>TestFloat-general.html</CODE></NOBR></A>. </P> <P> A single execution of <CODE>testfloat_ver</CODE> verifies results for only a single floating-point operation and associated options. The <CODE>testfloat_ver</CODE> program must be repeatedly executed to verify results for each operation to be tested. </P> <P> The test cases to be verified are read by <CODE>testfloat_ver</CODE> 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 <CODE>testfloat_ver</CODE>’s input is raw hexadecimal text, described in the section below titled <I>Input Format</I>. </P> <P> For each test case given to it, <CODE>testfloat_ver</CODE> examines the computed results and reports any unexpected results as likely errors. For more about the operation of <CODE>testfloat_ver</CODE> and how to interpret its output, refer to <A HREF="TestFloat-general.html"><NOBR><CODE>TestFloat-general.html</CODE></NOBR></A>. </P> <H2>Command Syntax</H2> <P> The <CODE>testfloat_ver</CODE> program is executed as a command with this syntax: <BLOCKQUOTE> <PRE> testfloat_ver [<<I>option</I>>...] <<I>function</I>> </PRE> </BLOCKQUOTE> Square brackets (<CODE>[ ]</CODE>) denote optional arguments, <CODE><<I>option</I>></CODE> is a supported option, and <CODE><<I>function</I>></CODE> is the name of a testable operation. The available options are documented below. The testable operation names are listed in <A HREF="TestFloat-general.html"><NOBR><CODE>TestFloat-general.html</CODE></NOBR></A>. If <CODE>testfloat_ver</CODE> is executed without any arguments, a summary of usage is written. </P> <H2>Options</H2> <P> The <CODE>testfloat_ver</CODE> program accepts several command options. If mutually contradictory options are given, the last one has priority. </P> <H3><CODE>-help</CODE></H3> <P> The <CODE>-help</CODE> option causes a summary of program usage to be written, after which the program exits. </P> <H3><CODE>-errors <<I>num</I>></CODE></H3> <P> The <CODE>-errors</CODE> option instructs <CODE>testfloat_ver</CODE> to report no more than the specified number of errors. The argument to <CODE>-errors</CODE> must be a nonnegative decimal integer. Once the specified number of error reports has been generated, the program exits. The default is <NOBR><CODE>-errors</CODE> <CODE>20</CODE></NOBR>. </P> <P> Against intuition, <NOBR><CODE>-errors</CODE> <CODE>0</CODE></NOBR> causes <CODE>testfloat_ver</CODE> to continue for any number of errors. </P> <H3><CODE>-checkNaNs</CODE></H3> <P> The <CODE>-checkNaNs</CODE> option causes <CODE>testfloat_ver</CODE> to verify the bitwise correctness of NaN results. In order for this option to be sensible, <CODE>testfloat_ver</CODE> 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. </P> <H3><CODE>-checkInvInts</CODE></H3> <P> The <CODE>-checkInvInts</CODE> option causes <CODE>testfloat_ver</CODE> to verify the bitwise correctness of integer results of invalid operations. In order for this option to be sensible, <CODE>testfloat_ver</CODE> 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. </P> <H3><CODE>-checkAll</CODE></H3> <P> Enables both <CODE>-checkNaNs</CODE> and <CODE>-checkInvInts</CODE>. </P> <H3><CODE>-precision32, -precision64, -precision80</CODE></H3> <P> When <CODE><<I>function</I>></CODE> is an <NOBR>80-bit</NOBR> double-extended-precision operation affected by rounding precision control, the <CODE>-precision32</CODE> option indicates that the rounding precision should be <NOBR>32 bits</NOBR>, equivalent to <NOBR>32-bit</NOBR> single-precision. Likewise, <CODE>-precision64</CODE> indicates that the rounding precision should be <NOBR>64 bits</NOBR>, equivalent to <NOBR>64-bit</NOBR> double-precision, and <CODE>-precision80</CODE> indicates that the rounding precision should be the full <NOBR>80 bits</NOBR> 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 <NOBR>80 bits</NOBR>, same as <CODE>-precision80</CODE>. </P> <H3><CODE>-rnear_even, -rnear_maxMag, -rminMag, -rmin, -rmax, -rodd</CODE></H3> <P> When <CODE><<I>function</I>></CODE> is an operation that requires rounding, the <CODE>-rnear_even</CODE> option indicates that rounding should be to nearest/even, <CODE>-rnear_maxMag</CODE> indicates rounding to nearest/maximum magnitude (nearest-away), <CODE>-rminMag</CODE> indicates rounding to minimum magnitude (toward zero), <CODE>-rmin</CODE> indicates rounding to minimum (down, toward negative infinity), <CODE>-rmax</CODE> indicates rounding to maximum (up, toward positive infinity), and <CODE>-rodd</CODE>, 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 <CODE>-rnear_even</CODE>. </P> <H3><CODE>-tininessbefore, -tininessafter</CODE></H3> <P> When <CODE><<I>function</I>></CODE> is an operation that requires rounding, the <CODE>-tininessbefore</CODE> option indicates that tininess on underflow should be detected before rounding, while <CODE>-tininessafter</CODE> 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 <CODE>-tininessafter</CODE>. </P> <H3><CODE>-notexact, -exact</CODE></H3> <P> When <CODE><<I>function</I>></CODE> is an operation that rounds to an integer (either conversion to an integer type or a <CODE>roundToInt</CODE> operation), the <CODE>-notexact</CODE> option indicates that the <I>inexact</I> exception flag should never be raised, while <CODE>-exact</CODE> indicates that the <I>inexact</I> 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 <I>inexact</I> exception flag should not be raised when rounding to an integer, same as <CODE>-notexact</CODE>. </P> <H2>Input Format</H2> <P> For a given <CODE><<I>function</I>></CODE> argument, the input format expected by <CODE>testfloat_ver</CODE> is the same as the output generated by program <A HREF="testfloat_gen.html"><NOBR><CODE>testfloat_gen</CODE></NOBR></A> for the same argument. </P> <P> Input to <CODE>testfloat_ver</CODE> 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 <BLOCKQUOTE> <PRE> testfloat_ver f64_add </PRE> </BLOCKQUOTE> valid input could include these lines: <BLOCKQUOTE> <PRE> 3F90EB5825D6851E C3E0080080000000 C3E0080080000000 01 41E3C00000000000 C182024F8AE474A8 41E377F6C1D46E2D 01 7FD80FFFFFFFFFFF 7FEFFFFFFFFFFF80 7FF0000000000000 05 3FFFED6A25C534BE 3CA1000000020000 3FFFED6A25C534BF 01 ... </PRE> </BLOCKQUOTE> On each line above, the first two hexadecimal numbers represent the <NOBR>64-bit</NOBR> floating-point operands, the third hexadecimal number is the <NOBR>64-bit</NOBR> floating-point result of the operation (the sum), and the last hexadecimal number gives the exception flags that were raised by the operation. </P> <P> 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 <CODE>3F9</CODE> are the sign and encoded exponent of the <NOBR>64-bit</NOBR> floating-point value, and the remaining digits are the encoded significand. </P> <P> Exception flags are encoded with one bit per flag as follows: <BLOCKQUOTE> <TABLE CELLSPACING=0 CELLPADDING=0> <TR> <TD>bit 0<CODE> </CODE></TD> <TD><I>inexact</I> exception</TD> </TR> <TR><TD>bit 1</TD><TD><I>underflow</I> exception</TD></TR> <TR><TD>bit 2</TD><TD><I>overflow</I> exception</TD></TR> <TR> <TD>bit 3</TD> <TD><I>infinite</I> exception (“divide by zero”)</TD> </TR> <TR><TD>bit 4</TD><TD><I>invalid</I> exception</TD></TR> </TABLE> </BLOCKQUOTE> </P> </BODY>