2018-01-19 16:36:40 +00:00
|
|
|
/*
|
|
|
|
|
* QEMU float support
|
|
|
|
|
*
|
|
|
|
|
* The code in this source file is derived from release 2a of the SoftFloat
|
|
|
|
|
* IEC/IEEE Floating-point Arithmetic Package. Those parts of the code (and
|
|
|
|
|
* some later contributions) are provided under that license, as detailed below.
|
|
|
|
|
* It has subsequently been modified by contributors to the QEMU Project,
|
|
|
|
|
* so some portions are provided under:
|
|
|
|
|
* the SoftFloat-2a license
|
|
|
|
|
* the BSD license
|
|
|
|
|
* GPL-v2-or-later
|
|
|
|
|
*
|
|
|
|
|
* This header holds definitions for code that might be dealing with
|
|
|
|
|
* softfloat types but not need access to the actual library functions.
|
|
|
|
|
*/
|
|
|
|
|
/*
|
|
|
|
|
===============================================================================
|
|
|
|
|
This C header file is part of the SoftFloat IEC/IEEE Floating-point
|
|
|
|
|
Arithmetic Package, Release 2a.
|
|
|
|
|
|
|
|
|
|
Written by John R. Hauser. This work was made possible in part by the
|
|
|
|
|
International Computer Science Institute, located at Suite 600, 1947 Center
|
|
|
|
|
Street, Berkeley, California 94704. Funding was partially provided by the
|
|
|
|
|
National Science Foundation under grant MIP-9311980. The original version
|
|
|
|
|
of this code was written as part of a project to build a fixed-point vector
|
|
|
|
|
processor in collaboration with the University of California at Berkeley,
|
|
|
|
|
overseen by Profs. Nelson Morgan and John Wawrzynek. More information
|
|
|
|
|
is available through the Web page `http://HTTP.CS.Berkeley.EDU/~jhauser/
|
|
|
|
|
arithmetic/SoftFloat.html'.
|
|
|
|
|
|
|
|
|
|
THIS SOFTWARE IS DISTRIBUTED AS IS, FOR FREE. Although reasonable effort
|
|
|
|
|
has been made to avoid it, THIS SOFTWARE MAY CONTAIN FAULTS THAT WILL AT
|
|
|
|
|
TIMES RESULT IN INCORRECT BEHAVIOR. USE OF THIS SOFTWARE IS RESTRICTED TO
|
|
|
|
|
PERSONS AND ORGANIZATIONS WHO CAN AND WILL TAKE FULL RESPONSIBILITY FOR ANY
|
|
|
|
|
AND ALL LOSSES, COSTS, OR OTHER PROBLEMS ARISING FROM ITS USE.
|
|
|
|
|
|
|
|
|
|
Derivative works are acceptable, even for commercial purposes, so long as
|
|
|
|
|
(1) they include prominent notice that the work is derivative, and (2) they
|
|
|
|
|
include prominent notice akin to these four paragraphs for those parts of
|
|
|
|
|
this code that are retained.
|
|
|
|
|
|
|
|
|
|
===============================================================================
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* BSD licensing:
|
|
|
|
|
* Copyright (c) 2006, Fabrice Bellard
|
|
|
|
|
* All rights reserved.
|
|
|
|
|
*
|
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
|
* modification, are permitted provided that the following conditions are met:
|
|
|
|
|
*
|
|
|
|
|
* 1. Redistributions of source code must retain the above copyright notice,
|
|
|
|
|
* this list of conditions and the following disclaimer.
|
|
|
|
|
*
|
|
|
|
|
* 2. 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.
|
|
|
|
|
*
|
|
|
|
|
* 3. Neither the name of the copyright holder 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 COPYRIGHT HOLDERS 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 COPYRIGHT HOLDER 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.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* Portions of this work are licensed under the terms of the GNU GPL,
|
|
|
|
|
* version 2 or later. See the COPYING file in the top-level directory.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef SOFTFLOAT_TYPES_H
|
|
|
|
|
#define SOFTFLOAT_TYPES_H
|
|
|
|
|
|
2025-11-27 08:38:12 +01:00
|
|
|
#include "hw/core/registerfields.h"
|
2024-12-11 15:30:57 +00:00
|
|
|
|
2018-01-19 16:36:40 +00:00
|
|
|
/*
|
|
|
|
|
* Software IEC/IEEE floating-point types.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
typedef uint16_t float16;
|
|
|
|
|
typedef uint32_t float32;
|
|
|
|
|
typedef uint64_t float64;
|
|
|
|
|
#define float16_val(x) (x)
|
|
|
|
|
#define float32_val(x) (x)
|
|
|
|
|
#define float64_val(x) (x)
|
|
|
|
|
#define make_float16(x) (x)
|
|
|
|
|
#define make_float32(x) (x)
|
|
|
|
|
#define make_float64(x) (x)
|
|
|
|
|
#define const_float16(x) (x)
|
|
|
|
|
#define const_float32(x) (x)
|
|
|
|
|
#define const_float64(x) (x)
|
|
|
|
|
typedef struct {
|
|
|
|
|
uint64_t low;
|
|
|
|
|
uint16_t high;
|
|
|
|
|
} floatx80;
|
|
|
|
|
#define make_floatx80(exp, mant) ((floatx80) { mant, exp })
|
|
|
|
|
#define make_floatx80_init(exp, mant) { .low = mant, .high = exp }
|
|
|
|
|
typedef struct {
|
2022-03-23 19:57:17 +04:00
|
|
|
#if HOST_BIG_ENDIAN
|
2018-01-19 16:36:40 +00:00
|
|
|
uint64_t high, low;
|
|
|
|
|
#else
|
|
|
|
|
uint64_t low, high;
|
|
|
|
|
#endif
|
|
|
|
|
} float128;
|
|
|
|
|
#define make_float128(high_, low_) ((float128) { .high = high_, .low = low_ })
|
|
|
|
|
#define make_float128_init(high_, low_) { .high = high_, .low = low_ }
|
|
|
|
|
|
2020-08-13 15:14:19 +08:00
|
|
|
/*
|
|
|
|
|
* Software neural-network floating-point types.
|
|
|
|
|
*/
|
|
|
|
|
typedef uint16_t bfloat16;
|
|
|
|
|
|
2026-02-05 17:35:56 +10:00
|
|
|
/*
|
|
|
|
|
* Open Compute Project (OCP) Microscaling Formats
|
|
|
|
|
*/
|
2026-02-05 21:10:46 +10:00
|
|
|
typedef uint8_t float4_e2m1;
|
2026-02-05 20:45:25 +10:00
|
|
|
typedef uint8_t float8_e4m3;
|
2026-02-05 17:35:56 +10:00
|
|
|
typedef uint8_t float8_e5m2;
|
|
|
|
|
|
2018-01-19 18:24:22 +00:00
|
|
|
/*
|
|
|
|
|
* Software IEC/IEEE floating-point underflow tininess-detection mode.
|
|
|
|
|
*/
|
|
|
|
|
|
2020-05-04 21:19:39 -07:00
|
|
|
#define float_tininess_after_rounding false
|
|
|
|
|
#define float_tininess_before_rounding true
|
2018-01-19 18:24:22 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
*Software IEC/IEEE floating-point rounding mode.
|
|
|
|
|
*/
|
|
|
|
|
|
2020-05-05 09:01:49 -07:00
|
|
|
typedef enum __attribute__((__packed__)) {
|
2018-01-19 18:24:22 +00:00
|
|
|
float_round_nearest_even = 0,
|
|
|
|
|
float_round_down = 1,
|
|
|
|
|
float_round_up = 2,
|
|
|
|
|
float_round_to_zero = 3,
|
|
|
|
|
float_round_ties_away = 4,
|
2021-05-25 15:58:10 -07:00
|
|
|
/* Not an IEEE rounding mode: round to closest odd, overflow to max */
|
2018-01-19 18:24:22 +00:00
|
|
|
float_round_to_odd = 5,
|
2021-05-25 15:58:10 -07:00
|
|
|
/* Not an IEEE rounding mode: round to closest odd, overflow to inf */
|
|
|
|
|
float_round_to_odd_inf = 6,
|
2024-12-08 08:54:41 -06:00
|
|
|
/* Not an IEEE rounding mode: round to nearest even, overflow to max */
|
|
|
|
|
float_round_nearest_even_max = 7,
|
2020-05-05 09:01:49 -07:00
|
|
|
} FloatRoundMode;
|
2018-01-19 18:24:22 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Software IEC/IEEE floating-point exception flags.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
enum {
|
2021-12-17 17:57:14 +01:00
|
|
|
float_flag_invalid = 0x0001,
|
|
|
|
|
float_flag_divbyzero = 0x0002,
|
|
|
|
|
float_flag_overflow = 0x0004,
|
|
|
|
|
float_flag_underflow = 0x0008,
|
|
|
|
|
float_flag_inexact = 0x0010,
|
2025-01-24 16:27:39 +00:00
|
|
|
/* We flushed an input denormal to 0 (because of flush_inputs_to_zero) */
|
|
|
|
|
float_flag_input_denormal_flushed = 0x0020,
|
2025-01-24 16:27:40 +00:00
|
|
|
/* We flushed an output denormal to 0 (because of flush_to_zero) */
|
|
|
|
|
float_flag_output_denormal_flushed = 0x0040,
|
2021-12-17 17:57:14 +01:00
|
|
|
float_flag_invalid_isi = 0x0080, /* inf - inf */
|
2021-12-17 17:57:14 +01:00
|
|
|
float_flag_invalid_imz = 0x0100, /* inf * 0 */
|
2021-12-17 17:57:14 +01:00
|
|
|
float_flag_invalid_idi = 0x0200, /* inf / inf */
|
|
|
|
|
float_flag_invalid_zdz = 0x0400, /* 0 / 0 */
|
2021-12-17 17:57:14 +01:00
|
|
|
float_flag_invalid_sqrt = 0x0800, /* sqrt(-x) */
|
2021-12-17 17:57:14 +01:00
|
|
|
float_flag_invalid_cvti = 0x1000, /* non-nan to integer */
|
2021-12-17 17:57:14 +01:00
|
|
|
float_flag_invalid_snan = 0x2000, /* any operand was snan */
|
2025-02-01 16:39:07 +00:00
|
|
|
/*
|
|
|
|
|
* An input was denormal and we used it (without flushing it to zero).
|
|
|
|
|
* Not set if we do not actually use the denormal input (e.g.
|
|
|
|
|
* because some other input was a NaN, or because the operation
|
|
|
|
|
* wasn't actually carried out (divide-by-zero; invalid))
|
|
|
|
|
*/
|
|
|
|
|
float_flag_input_denormal_used = 0x4000,
|
2018-01-19 18:24:22 +00:00
|
|
|
};
|
|
|
|
|
|
2026-05-01 13:05:01 +10:00
|
|
|
typedef uint16_t FloatExceptionFlags;
|
|
|
|
|
|
2020-11-21 09:33:36 -08:00
|
|
|
/*
|
|
|
|
|
* Rounding precision for floatx80.
|
|
|
|
|
*/
|
|
|
|
|
typedef enum __attribute__((__packed__)) {
|
|
|
|
|
floatx80_precision_x,
|
|
|
|
|
floatx80_precision_d,
|
|
|
|
|
floatx80_precision_s,
|
|
|
|
|
} FloatX80RoundPrec;
|
2018-01-19 18:24:22 +00:00
|
|
|
|
2026-05-01 14:19:04 +10:00
|
|
|
/*
|
|
|
|
|
* Define how the architecture discriminates signaling NaNs.
|
|
|
|
|
* This done with the most significant bit of the fraction.
|
|
|
|
|
*
|
|
|
|
|
* In IEEE 754-1985 this was implementation defined, but in IEEE 754-2008
|
|
|
|
|
* the msb must be 0. But setting the msb to 1 got baked into HPPA, SH4,
|
|
|
|
|
* and pre-2008 MIPS.
|
|
|
|
|
*
|
|
|
|
|
* Further, some architectures (or modes of architectures) do not detect
|
|
|
|
|
* signaling NaNs at all.
|
|
|
|
|
*/
|
|
|
|
|
typedef enum __attribute__((__packed__)) {
|
|
|
|
|
float_snan_bit_is_zero,
|
|
|
|
|
float_snan_bit_is_one,
|
|
|
|
|
float_snan_never,
|
|
|
|
|
} FloatSNaNRule;
|
|
|
|
|
|
softfloat: Allow 2-operand NaN propagation rule to be set at runtime
IEEE 758 does not define a fixed rule for which NaN to pick as the
result if both operands of a 2-operand operation are NaNs. As a
result different architectures have ended up with different rules for
propagating NaNs.
QEMU currently hardcodes the NaN propagation logic into the binary
because pickNaN() has an ifdef ladder for different targets. We want
to make the propagation rule instead be selectable at runtime,
because:
* this will let us have multiple targets in one QEMU binary
* the Arm FEAT_AFP architectural feature includes letting
the guest select a NaN propagation rule at runtime
* x86 specifies different propagation rules for x87 FPU ops
and for SSE ops, and specifying the rule in the float_status
would let us emulate this, instead of wrongly using the
x87 rules everywhere
In this commit we add an enum for the propagation rule, the field in
float_status, and the corresponding getters and setters. We change
pickNaN to honour this, but because all targets still leave this
field at its default 0 value, the fallback logic will pick the rule
type with the old ifdef ladder.
It's valid not to set a propagation rule if default_nan_mode is
enabled, because in that case there's no need to pick a NaN; all the
callers of pickNaN() catch this case and skip calling it. So we can
already assert that we don't get into the "no rule defined" codepath
for our four targets which always set default_nan_mode: Hexagon,
RiscV, SH4 and Tricore, and for the one target which does not have FP
at all: avr. These targets will not need to be updated to call
set_float_2nan_prop_rule().
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20241025141254.2141506-2-peter.maydell@linaro.org
2024-11-05 10:09:52 +00:00
|
|
|
/*
|
|
|
|
|
* 2-input NaN propagation rule. Individual architectures have
|
|
|
|
|
* different rules for which input NaN is propagated to the output
|
|
|
|
|
* when there is more than one NaN on the input.
|
|
|
|
|
*
|
|
|
|
|
* If default_nan_mode is enabled then it is valid not to set a
|
|
|
|
|
* NaN propagation rule, because the softfloat code guarantees
|
|
|
|
|
* not to try to pick a NaN to propagate in default NaN mode.
|
2024-11-05 10:09:58 +00:00
|
|
|
* When not in default-NaN mode, it is an error for the target
|
|
|
|
|
* not to set the rule in float_status, and we will assert if
|
|
|
|
|
* we need to handle an input NaN and no rule was selected.
|
softfloat: Allow 2-operand NaN propagation rule to be set at runtime
IEEE 758 does not define a fixed rule for which NaN to pick as the
result if both operands of a 2-operand operation are NaNs. As a
result different architectures have ended up with different rules for
propagating NaNs.
QEMU currently hardcodes the NaN propagation logic into the binary
because pickNaN() has an ifdef ladder for different targets. We want
to make the propagation rule instead be selectable at runtime,
because:
* this will let us have multiple targets in one QEMU binary
* the Arm FEAT_AFP architectural feature includes letting
the guest select a NaN propagation rule at runtime
* x86 specifies different propagation rules for x87 FPU ops
and for SSE ops, and specifying the rule in the float_status
would let us emulate this, instead of wrongly using the
x87 rules everywhere
In this commit we add an enum for the propagation rule, the field in
float_status, and the corresponding getters and setters. We change
pickNaN to honour this, but because all targets still leave this
field at its default 0 value, the fallback logic will pick the rule
type with the old ifdef ladder.
It's valid not to set a propagation rule if default_nan_mode is
enabled, because in that case there's no need to pick a NaN; all the
callers of pickNaN() catch this case and skip calling it. So we can
already assert that we don't get into the "no rule defined" codepath
for our four targets which always set default_nan_mode: Hexagon,
RiscV, SH4 and Tricore, and for the one target which does not have FP
at all: avr. These targets will not need to be updated to call
set_float_2nan_prop_rule().
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20241025141254.2141506-2-peter.maydell@linaro.org
2024-11-05 10:09:52 +00:00
|
|
|
*/
|
|
|
|
|
typedef enum __attribute__((__packed__)) {
|
|
|
|
|
/* No propagation rule specified */
|
|
|
|
|
float_2nan_prop_none = 0,
|
|
|
|
|
/* Prefer SNaN over QNaN, then operand A over B */
|
|
|
|
|
float_2nan_prop_s_ab,
|
|
|
|
|
/* Prefer SNaN over QNaN, then operand B over A */
|
|
|
|
|
float_2nan_prop_s_ba,
|
|
|
|
|
/* Prefer A over B regardless of SNaN vs QNaN */
|
|
|
|
|
float_2nan_prop_ab,
|
|
|
|
|
/* Prefer B over A regardless of SNaN vs QNaN */
|
|
|
|
|
float_2nan_prop_ba,
|
|
|
|
|
/*
|
|
|
|
|
* This implements x87 NaN propagation rules:
|
|
|
|
|
* SNaN + QNaN => return the QNaN
|
|
|
|
|
* two SNaNs => return the one with the larger significand, silenced
|
|
|
|
|
* two QNaNs => return the one with the larger significand
|
|
|
|
|
* SNaN and a non-NaN => return the SNaN, silenced
|
|
|
|
|
* QNaN and a non-NaN => return the QNaN
|
|
|
|
|
*
|
|
|
|
|
* If we get down to comparing significands and they are the same,
|
|
|
|
|
* return the NaN with the positive sign bit (if any).
|
|
|
|
|
*/
|
|
|
|
|
float_2nan_prop_x87,
|
|
|
|
|
} Float2NaNPropRule;
|
|
|
|
|
|
2024-12-11 15:30:57 +00:00
|
|
|
/*
|
|
|
|
|
* 3-input NaN propagation rule, for fused multiply-add. Individual
|
|
|
|
|
* architectures have different rules for which input NaN is
|
|
|
|
|
* propagated to the output when there is more than one NaN on the
|
|
|
|
|
* input.
|
|
|
|
|
*
|
|
|
|
|
* If default_nan_mode is enabled then it is valid not to set a NaN
|
|
|
|
|
* propagation rule, because the softfloat code guarantees not to try
|
|
|
|
|
* to pick a NaN to propagate in default NaN mode. When not in
|
|
|
|
|
* default-NaN mode, it is an error for the target not to set the rule
|
|
|
|
|
* in float_status if it uses a muladd, and we will assert if we need
|
|
|
|
|
* to handle an input NaN and no rule was selected.
|
|
|
|
|
*
|
|
|
|
|
* The naming scheme for Float3NaNPropRule values is:
|
|
|
|
|
* float_3nan_prop_s_abc:
|
|
|
|
|
* = "Prefer SNaN over QNaN, then operand A over B over C"
|
|
|
|
|
* float_3nan_prop_abc:
|
|
|
|
|
* = "Prefer A over B over C regardless of SNaN vs QNAN"
|
|
|
|
|
*
|
|
|
|
|
* For QEMU, the multiply-add operation is A * B + C.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We set the Float3NaNPropRule enum values up so we can select the
|
|
|
|
|
* right value in pickNaNMulAdd in a data driven way.
|
|
|
|
|
*/
|
|
|
|
|
FIELD(3NAN, 1ST, 0, 2) /* which operand is most preferred ? */
|
|
|
|
|
FIELD(3NAN, 2ND, 2, 2) /* which operand is next most preferred ? */
|
|
|
|
|
FIELD(3NAN, 3RD, 4, 2) /* which operand is least preferred ? */
|
|
|
|
|
FIELD(3NAN, SNAN, 6, 1) /* do we prefer SNaN over QNaN ? */
|
|
|
|
|
|
|
|
|
|
#define PROPRULE(X, Y, Z) \
|
|
|
|
|
((X << R_3NAN_1ST_SHIFT) | (Y << R_3NAN_2ND_SHIFT) | (Z << R_3NAN_3RD_SHIFT))
|
|
|
|
|
|
|
|
|
|
typedef enum __attribute__((__packed__)) {
|
|
|
|
|
float_3nan_prop_none = 0, /* No propagation rule specified */
|
|
|
|
|
float_3nan_prop_abc = PROPRULE(0, 1, 2),
|
|
|
|
|
float_3nan_prop_acb = PROPRULE(0, 2, 1),
|
|
|
|
|
float_3nan_prop_bac = PROPRULE(1, 0, 2),
|
|
|
|
|
float_3nan_prop_bca = PROPRULE(1, 2, 0),
|
|
|
|
|
float_3nan_prop_cab = PROPRULE(2, 0, 1),
|
|
|
|
|
float_3nan_prop_cba = PROPRULE(2, 1, 0),
|
|
|
|
|
float_3nan_prop_s_abc = float_3nan_prop_abc | R_3NAN_SNAN_MASK,
|
|
|
|
|
float_3nan_prop_s_acb = float_3nan_prop_acb | R_3NAN_SNAN_MASK,
|
|
|
|
|
float_3nan_prop_s_bac = float_3nan_prop_bac | R_3NAN_SNAN_MASK,
|
|
|
|
|
float_3nan_prop_s_bca = float_3nan_prop_bca | R_3NAN_SNAN_MASK,
|
|
|
|
|
float_3nan_prop_s_cab = float_3nan_prop_cab | R_3NAN_SNAN_MASK,
|
|
|
|
|
float_3nan_prop_s_cba = float_3nan_prop_cba | R_3NAN_SNAN_MASK,
|
|
|
|
|
} Float3NaNPropRule;
|
|
|
|
|
|
|
|
|
|
#undef PROPRULE
|
|
|
|
|
|
softfloat: Allow runtime choice of inf * 0 + NaN result
IEEE 758 does not define a fixed rule for what NaN to return in
the case of a fused multiply-add of inf * 0 + NaN. Different
architectures thus do different things:
* some return the default NaN
* some return the input NaN
* Arm returns the default NaN if the input NaN is quiet,
and the input NaN if it is signalling
We want to make this logic be runtime selected rather than
hardcoded into the binary, because:
* this will let us have multiple targets in one QEMU binary
* the Arm FEAT_AFP architectural feature includes letting
the guest select a NaN propagation rule at runtime
In this commit we add an enum for the propagation rule, the field in
float_status, and the corresponding getters and setters. We change
pickNaNMulAdd to honour this, but because all targets still leave
this field at its default 0 value, the fallback logic will pick the
rule type with the old ifdef ladder.
Note that four architectures both use the muladd softfloat functions
and did not have a branch of the ifdef ladder to specify their
behaviour (and so were ending up with the "default" case, probably
wrongly): i386, HPPA, SH4 and Tricore. SH4 and Tricore both set
default_nan_mode, and so will never get into pickNaNMulAdd(). For
HPPA and i386 we retain the same behaviour as the old default-case,
which is to not ever return the default NaN. This might not be
correct but it is not a behaviour change.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20241202131347.498124-4-peter.maydell@linaro.org
2024-12-11 15:30:53 +00:00
|
|
|
/*
|
|
|
|
|
* Rule for result of fused multiply-add 0 * Inf + NaN.
|
|
|
|
|
* This must be a NaN, but implementations differ on whether this
|
|
|
|
|
* is the input NaN or the default NaN.
|
|
|
|
|
*
|
|
|
|
|
* You don't need to set this if default_nan_mode is enabled.
|
|
|
|
|
* When not in default-NaN mode, it is an error for the target
|
|
|
|
|
* not to set the rule in float_status if it uses muladd, and we
|
|
|
|
|
* will assert if we need to handle an input NaN and no rule was
|
|
|
|
|
* selected.
|
|
|
|
|
*/
|
|
|
|
|
typedef enum __attribute__((__packed__)) {
|
|
|
|
|
/* No propagation rule specified */
|
|
|
|
|
float_infzeronan_none = 0,
|
|
|
|
|
/* Result is never the default NaN (so always the input NaN) */
|
2025-01-16 11:25:35 +00:00
|
|
|
float_infzeronan_dnan_never = 1,
|
softfloat: Allow runtime choice of inf * 0 + NaN result
IEEE 758 does not define a fixed rule for what NaN to return in
the case of a fused multiply-add of inf * 0 + NaN. Different
architectures thus do different things:
* some return the default NaN
* some return the input NaN
* Arm returns the default NaN if the input NaN is quiet,
and the input NaN if it is signalling
We want to make this logic be runtime selected rather than
hardcoded into the binary, because:
* this will let us have multiple targets in one QEMU binary
* the Arm FEAT_AFP architectural feature includes letting
the guest select a NaN propagation rule at runtime
In this commit we add an enum for the propagation rule, the field in
float_status, and the corresponding getters and setters. We change
pickNaNMulAdd to honour this, but because all targets still leave
this field at its default 0 value, the fallback logic will pick the
rule type with the old ifdef ladder.
Note that four architectures both use the muladd softfloat functions
and did not have a branch of the ifdef ladder to specify their
behaviour (and so were ending up with the "default" case, probably
wrongly): i386, HPPA, SH4 and Tricore. SH4 and Tricore both set
default_nan_mode, and so will never get into pickNaNMulAdd(). For
HPPA and i386 we retain the same behaviour as the old default-case,
which is to not ever return the default NaN. This might not be
correct but it is not a behaviour change.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20241202131347.498124-4-peter.maydell@linaro.org
2024-12-11 15:30:53 +00:00
|
|
|
/* Result is always the default NaN */
|
2025-01-16 11:25:35 +00:00
|
|
|
float_infzeronan_dnan_always = 2,
|
softfloat: Allow runtime choice of inf * 0 + NaN result
IEEE 758 does not define a fixed rule for what NaN to return in
the case of a fused multiply-add of inf * 0 + NaN. Different
architectures thus do different things:
* some return the default NaN
* some return the input NaN
* Arm returns the default NaN if the input NaN is quiet,
and the input NaN if it is signalling
We want to make this logic be runtime selected rather than
hardcoded into the binary, because:
* this will let us have multiple targets in one QEMU binary
* the Arm FEAT_AFP architectural feature includes letting
the guest select a NaN propagation rule at runtime
In this commit we add an enum for the propagation rule, the field in
float_status, and the corresponding getters and setters. We change
pickNaNMulAdd to honour this, but because all targets still leave
this field at its default 0 value, the fallback logic will pick the
rule type with the old ifdef ladder.
Note that four architectures both use the muladd softfloat functions
and did not have a branch of the ifdef ladder to specify their
behaviour (and so were ending up with the "default" case, probably
wrongly): i386, HPPA, SH4 and Tricore. SH4 and Tricore both set
default_nan_mode, and so will never get into pickNaNMulAdd(). For
HPPA and i386 we retain the same behaviour as the old default-case,
which is to not ever return the default NaN. This might not be
correct but it is not a behaviour change.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20241202131347.498124-4-peter.maydell@linaro.org
2024-12-11 15:30:53 +00:00
|
|
|
/* Result is the default NaN if the input NaN is quiet */
|
2025-01-16 11:25:35 +00:00
|
|
|
float_infzeronan_dnan_if_qnan = 3,
|
|
|
|
|
/*
|
|
|
|
|
* Don't raise Invalid for 0 * Inf + NaN. Default is to raise.
|
|
|
|
|
* IEEE 754-2008 section 7.2 makes it implementation defined whether
|
|
|
|
|
* 0 * Inf + QNaN raises Invalid or not. Note that 0 * Inf + SNaN will
|
|
|
|
|
* raise the Invalid flag for the SNaN anyway.
|
|
|
|
|
*
|
|
|
|
|
* This is a flag which can be ORed in with any of the above
|
|
|
|
|
* DNaN behaviour options.
|
|
|
|
|
*/
|
2026-05-01 22:18:35 +10:00
|
|
|
float_infzeronan_suppress_invalid = (1 << 2),
|
softfloat: Allow runtime choice of inf * 0 + NaN result
IEEE 758 does not define a fixed rule for what NaN to return in
the case of a fused multiply-add of inf * 0 + NaN. Different
architectures thus do different things:
* some return the default NaN
* some return the input NaN
* Arm returns the default NaN if the input NaN is quiet,
and the input NaN if it is signalling
We want to make this logic be runtime selected rather than
hardcoded into the binary, because:
* this will let us have multiple targets in one QEMU binary
* the Arm FEAT_AFP architectural feature includes letting
the guest select a NaN propagation rule at runtime
In this commit we add an enum for the propagation rule, the field in
float_status, and the corresponding getters and setters. We change
pickNaNMulAdd to honour this, but because all targets still leave
this field at its default 0 value, the fallback logic will pick the
rule type with the old ifdef ladder.
Note that four architectures both use the muladd softfloat functions
and did not have a branch of the ifdef ladder to specify their
behaviour (and so were ending up with the "default" case, probably
wrongly): i386, HPPA, SH4 and Tricore. SH4 and Tricore both set
default_nan_mode, and so will never get into pickNaNMulAdd(). For
HPPA and i386 we retain the same behaviour as the old default-case,
which is to not ever return the default NaN. This might not be
correct but it is not a behaviour change.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20241202131347.498124-4-peter.maydell@linaro.org
2024-12-11 15:30:53 +00:00
|
|
|
} FloatInfZeroNaNRule;
|
|
|
|
|
|
2025-02-01 16:39:08 +00:00
|
|
|
/*
|
|
|
|
|
* When flush_to_zero is set, should we detect denormal results to
|
|
|
|
|
* be flushed before or after rounding? For most architectures this
|
|
|
|
|
* should be set to match the tininess_before_rounding setting,
|
|
|
|
|
* but a few architectures, e.g. MIPS MSA, detect FTZ before
|
|
|
|
|
* rounding but tininess after rounding.
|
|
|
|
|
*
|
|
|
|
|
* This enum is arranged so that the default if the target doesn't
|
|
|
|
|
* configure it matches the default for tininess_before_rounding
|
|
|
|
|
* (i.e. "after rounding").
|
|
|
|
|
*/
|
2026-05-01 20:05:59 +10:00
|
|
|
#define float_ftz_after_rounding false
|
|
|
|
|
#define float_ftz_before_rounding true
|
2025-02-01 16:39:08 +00:00
|
|
|
|
2025-02-24 11:15:13 +00:00
|
|
|
/*
|
|
|
|
|
* floatx80 is primarily used by x86 and m68k, and there are
|
|
|
|
|
* differences in the handling, largely related to the explicit
|
|
|
|
|
* Integer bit which floatx80 has and the other float formats do not.
|
|
|
|
|
* These flag values allow specification of the target's requirements
|
|
|
|
|
* and can be ORed together to set floatx80_behaviour.
|
|
|
|
|
*/
|
|
|
|
|
typedef enum __attribute__((__packed__)) {
|
|
|
|
|
/* In the default Infinity value, is the Integer bit 0 ? */
|
|
|
|
|
floatx80_default_inf_int_bit_is_zero = 1,
|
2025-02-24 11:15:17 +00:00
|
|
|
/*
|
|
|
|
|
* Are Pseudo-infinities (Inf with the Integer bit zero) valid?
|
|
|
|
|
* If so, floatx80_is_infinity() will return true for them.
|
fpu: Make floatx80 invalid encoding settable at runtime
Because floatx80 has an explicit integer bit, this permits some
odd encodings where the integer bit is not set correctly for the
floating point value type. In In Intel terminology the
categories are:
exp == 0, int = 0, mantissa == 0 : zeroes
exp == 0, int = 0, mantissa != 0 : denormals
exp == 0, int = 1 : pseudo-denormals
0 < exp < 0x7fff, int = 0 : unnormals
0 < exp < 0x7fff, int = 1 : normals
exp == 0x7fff, int = 0, mantissa == 0 : pseudo-infinities
exp == 0x7fff, int = 1, mantissa == 0 : infinities
exp == 0x7fff, int = 0, mantissa != 0 : pseudo-NaNs
exp == 0x7fff, int = 1, mantissa == 0 : NaNs
The usual IEEE cases of zero, denormal, normal, inf and NaN are always valid.
x87 permits as input also pseudo-denormals.
m68k permits all those and also pseudo-infinities, pseudo-NaNs and unnormals.
Currently we have an ifdef in floatx80_invalid_encoding() to select
the x86 vs m68k behaviour. Add new floatx80_behaviour flags to
select whether pseudo-NaN and unnormal are valid, and use these
(plus the existing pseudo_inf_valid flag) to decide whether these
encodings are invalid at runtime.
We leave pseudo-denormals as always-valid, since both x86 and m68k
accept them.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250224111524.1101196-8-peter.maydell@linaro.org
Message-id: 20250217125055.160887-6-peter.maydell@linaro.org
2025-02-24 11:15:19 +00:00
|
|
|
* If not, floatx80_invalid_encoding will return false for them,
|
|
|
|
|
* and using them as inputs to a float op will raise Invalid.
|
2025-02-24 11:15:17 +00:00
|
|
|
*/
|
|
|
|
|
floatx80_pseudo_inf_valid = 2,
|
fpu: Make floatx80 invalid encoding settable at runtime
Because floatx80 has an explicit integer bit, this permits some
odd encodings where the integer bit is not set correctly for the
floating point value type. In In Intel terminology the
categories are:
exp == 0, int = 0, mantissa == 0 : zeroes
exp == 0, int = 0, mantissa != 0 : denormals
exp == 0, int = 1 : pseudo-denormals
0 < exp < 0x7fff, int = 0 : unnormals
0 < exp < 0x7fff, int = 1 : normals
exp == 0x7fff, int = 0, mantissa == 0 : pseudo-infinities
exp == 0x7fff, int = 1, mantissa == 0 : infinities
exp == 0x7fff, int = 0, mantissa != 0 : pseudo-NaNs
exp == 0x7fff, int = 1, mantissa == 0 : NaNs
The usual IEEE cases of zero, denormal, normal, inf and NaN are always valid.
x87 permits as input also pseudo-denormals.
m68k permits all those and also pseudo-infinities, pseudo-NaNs and unnormals.
Currently we have an ifdef in floatx80_invalid_encoding() to select
the x86 vs m68k behaviour. Add new floatx80_behaviour flags to
select whether pseudo-NaN and unnormal are valid, and use these
(plus the existing pseudo_inf_valid flag) to decide whether these
encodings are invalid at runtime.
We leave pseudo-denormals as always-valid, since both x86 and m68k
accept them.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250224111524.1101196-8-peter.maydell@linaro.org
Message-id: 20250217125055.160887-6-peter.maydell@linaro.org
2025-02-24 11:15:19 +00:00
|
|
|
/*
|
|
|
|
|
* Are Pseudo-NaNs (NaNs where the Integer bit is zero) valid?
|
|
|
|
|
* If not, floatx80_invalid_encoding() will return false for them,
|
|
|
|
|
* and using them as inputs to a float op will raise Invalid.
|
|
|
|
|
*/
|
|
|
|
|
floatx80_pseudo_nan_valid = 4,
|
|
|
|
|
/*
|
|
|
|
|
* Are Unnormals (0 < exp < 0x7fff, Integer bit zero) valid?
|
|
|
|
|
* If not, floatx80_invalid_encoding() will return false for them,
|
|
|
|
|
* and using them as inputs to a float op will raise Invalid.
|
|
|
|
|
*/
|
|
|
|
|
floatx80_unnormal_valid = 8,
|
2025-02-24 11:15:20 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If the exponent is 0 and the Integer bit is set, Intel call
|
|
|
|
|
* this a "pseudo-denormal"; x86 supports that only on input
|
|
|
|
|
* (treating them as denormals by ignoring the Integer bit).
|
|
|
|
|
* For m68k, the integer bit is considered validly part of the
|
|
|
|
|
* input value when the exponent is 0, and may be 0 or 1,
|
|
|
|
|
* giving extra range. They may also be generated as outputs.
|
|
|
|
|
* (The m68k manual actually calls these values part of the
|
|
|
|
|
* normalized number range, not the denormalized number range.)
|
|
|
|
|
*
|
|
|
|
|
* By default you get the Intel behaviour where the Integer
|
|
|
|
|
* bit is ignored; if this is set then the Integer bit value
|
|
|
|
|
* is honoured, m68k-style.
|
|
|
|
|
*
|
|
|
|
|
* Either way, floatx80_invalid_encoding() will always accept
|
|
|
|
|
* pseudo-denormals.
|
|
|
|
|
*/
|
|
|
|
|
floatx80_pseudo_denormal_valid = 16,
|
2025-02-24 11:15:13 +00:00
|
|
|
} FloatX80Behaviour;
|
|
|
|
|
|
2018-01-19 18:24:22 +00:00
|
|
|
/*
|
|
|
|
|
* Floating Point Status. Individual architectures may maintain
|
|
|
|
|
* several versions of float_status for different functions. The
|
|
|
|
|
* correct status for the operation is then passed by reference to
|
|
|
|
|
* most of the softfloat functions.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
typedef struct float_status {
|
2026-05-01 22:18:35 +10:00
|
|
|
FloatExceptionFlags float_exception_flags : 16;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Floating point status controls.
|
|
|
|
|
* Items that, in general, may be updated by writes to an architectural
|
|
|
|
|
* floating point control register.
|
|
|
|
|
*/
|
|
|
|
|
FloatRoundMode float_rounding_mode : 3;
|
|
|
|
|
FloatX80RoundPrec floatx80_rounding_precision : 2;
|
2025-01-24 16:27:41 +00:00
|
|
|
/* should denormalised results go to zero and set output_denormal_flushed? */
|
2026-05-01 22:18:35 +10:00
|
|
|
bool flush_to_zero : 1;
|
2025-01-24 16:27:39 +00:00
|
|
|
/* should denormalised inputs go to zero and set input_denormal_flushed? */
|
2026-05-01 22:18:35 +10:00
|
|
|
bool flush_inputs_to_zero : 1;
|
|
|
|
|
/* should default nans be produced instead of propagating an input nan? */
|
|
|
|
|
bool default_nan_mode : 1;
|
|
|
|
|
/* should overflowed results subtract re_bias to its exponent? */
|
|
|
|
|
bool rebias_overflow : 1;
|
|
|
|
|
/* should underflowed results add re_bias to its exponent? */
|
|
|
|
|
bool rebias_underflow : 1;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Floating point behaviour controls.
|
|
|
|
|
* Items that, in general, will be set at cpu realization because
|
|
|
|
|
* the behaviour is baked into the specific hardware implementation.
|
|
|
|
|
*/
|
|
|
|
|
bool tininess_before_rounding : 1;
|
|
|
|
|
/* do we detect and flush denormal results before or after rounding? */
|
|
|
|
|
bool ftz_before_rounding : 1;
|
|
|
|
|
FloatSNaNRule float_snan_rule : 2;
|
2026-05-19 08:43:57 -07:00
|
|
|
/*
|
|
|
|
|
* Overriding float_snan_rule, is the single NaN representation for
|
|
|
|
|
* the OCP E4M3 format an SNaN or QNaN?
|
|
|
|
|
*/
|
|
|
|
|
bool e4m3_nan_is_snan : 1;
|
2026-05-01 22:18:35 +10:00
|
|
|
Float2NaNPropRule float_2nan_prop_rule : 3;
|
|
|
|
|
Float3NaNPropRule float_3nan_prop_rule : 7;
|
|
|
|
|
FloatInfZeroNaNRule float_infzeronan_rule: 3;
|
|
|
|
|
FloatX80Behaviour floatx80_behaviour : 5;
|
2024-12-11 15:31:04 +00:00
|
|
|
/*
|
|
|
|
|
* The pattern to use for the default NaN. Here the high bit specifies
|
|
|
|
|
* the default NaN's sign bit, and bits 6..0 specify the high bits of the
|
|
|
|
|
* fractional part. The low bits of the fractional part are copies of bit 0.
|
|
|
|
|
* The exponent of the default NaN is (as for any NaN) always all 1s.
|
|
|
|
|
* Note that a value of 0 here is not a valid NaN. The target must set
|
|
|
|
|
* this to the correct non-zero value, or we will assert when trying to
|
|
|
|
|
* create a default NaN.
|
|
|
|
|
*/
|
2026-05-01 22:18:35 +10:00
|
|
|
unsigned default_nan_pattern : 8;
|
2018-01-19 18:24:22 +00:00
|
|
|
} float_status;
|
|
|
|
|
|
2018-01-19 16:36:40 +00:00
|
|
|
#endif /* SOFTFLOAT_TYPES_H */
|