diff options
| author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-07 16:49:04 +0000 |
|---|---|---|
| committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-07 16:49:04 +0000 |
| commit | 16f504a9dca3fe3b70568f67b7d41241ae485288 (patch) | |
| tree | c60f36ada0496ba928b7161059ba5ab1ab224f9d /src/libs/softfloat-3e/testfloat/doc/testfloat_ver.html | |
| parent | Initial commit. (diff) | |
| download | virtualbox-16f504a9dca3fe3b70568f67b7d41241ae485288.tar.xz virtualbox-16f504a9dca3fe3b70568f67b7d41241ae485288.zip | |
Adding upstream version 7.0.6-dfsg.upstream/7.0.6-dfsgupstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'src/libs/softfloat-3e/testfloat/doc/testfloat_ver.html')
| -rw-r--r-- | src/libs/softfloat-3e/testfloat/doc/testfloat_ver.html | 270 |
1 files changed, 270 insertions, 0 deletions
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 @@ + +<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> + |