Files
qemu-qemu/include/fpu/softfloat-types.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

456 lines
18 KiB
C
Raw Permalink Normal View History

/*
* 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
#include "hw/core/registerfields.h"
/*
* 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 {
#if HOST_BIG_ENDIAN
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_ }
/*
* Software neural-network floating-point types.
*/
typedef uint16_t bfloat16;
/*
* Open Compute Project (OCP) Microscaling Formats
*/
typedef uint8_t float4_e2m1;
typedef uint8_t float8_e4m3;
typedef uint8_t float8_e5m2;
/*
* Software IEC/IEEE floating-point underflow tininess-detection mode.
*/
#define float_tininess_after_rounding false
#define float_tininess_before_rounding true
/*
*Software IEC/IEEE floating-point rounding mode.
*/
typedef enum __attribute__((__packed__)) {
float_round_nearest_even = 0,
float_round_down = 1,
float_round_up = 2,
float_round_to_zero = 3,
float_round_ties_away = 4,
/* Not an IEEE rounding mode: round to closest odd, overflow to max */
float_round_to_odd = 5,
/* Not an IEEE rounding mode: round to closest odd, overflow to inf */
float_round_to_odd_inf = 6,
/* Not an IEEE rounding mode: round to nearest even, overflow to max */
float_round_nearest_even_max = 7,
} FloatRoundMode;
/*
* Software IEC/IEEE floating-point exception flags.
*/
enum {
float_flag_invalid = 0x0001,
float_flag_divbyzero = 0x0002,
float_flag_overflow = 0x0004,
float_flag_underflow = 0x0008,
float_flag_inexact = 0x0010,
/* We flushed an input denormal to 0 (because of flush_inputs_to_zero) */
float_flag_input_denormal_flushed = 0x0020,
/* We flushed an output denormal to 0 (because of flush_to_zero) */
float_flag_output_denormal_flushed = 0x0040,
float_flag_invalid_isi = 0x0080, /* inf - inf */
float_flag_invalid_imz = 0x0100, /* inf * 0 */
float_flag_invalid_idi = 0x0200, /* inf / inf */
float_flag_invalid_zdz = 0x0400, /* 0 / 0 */
float_flag_invalid_sqrt = 0x0800, /* sqrt(-x) */
float_flag_invalid_cvti = 0x1000, /* non-nan to integer */
float_flag_invalid_snan = 0x2000, /* any operand was snan */
/*
* 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,
};
typedef uint16_t FloatExceptionFlags;
/*
* Rounding precision for floatx80.
*/
typedef enum __attribute__((__packed__)) {
floatx80_precision_x,
floatx80_precision_d,
floatx80_precision_s,
} FloatX80RoundPrec;
/*
* 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.
* 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;
/*
* 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.
*/
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;
fpu: allow flushing of output denormals to be after rounding Currently we handle flushing of output denormals in uncanon_normal always before we deal with rounding. This works for architectures that detect tininess before rounding, but is usually not the right place when the architecture detects tininess after rounding. For example, for x86 the SDM states that the MXCSR FTZ control bit causes outputs to be flushed to zero "when it detects a floating-point underflow condition". This means that we mustn't flush to zero if the input is such that after rounding it is no longer tiny. At least one of our guest architectures does underflow detection after rounding but flushing of denormals before rounding (MIPS MSA); this means we need to have a config knob for this that is separate from our existing tininess_before_rounding setting. Add an ftz_detection flag. For consistency with tininess_before_rounding, we make it default to "detect ftz after rounding"; this means that we need to explicitly set the flag to "detect ftz before rounding" on every existing architecture that sets flush_to_zero, so that this commit has no behaviour change. (This means more code change here but for the long term a less confusing API.) For several architectures the current behaviour is either definitely or possibly wrong; annotate those with TODO comments. These architectures are definitely wrong (and should detect ftz after rounding): * x86 * Alpha For these architectures the spec is unclear: * MIPS (for non-MSA) * RX * SH4 PA-RISC makes ftz detection IMPDEF, but we aren't setting the "tininess before rounding" setting that we ought to. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
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").
*/
#define float_ftz_after_rounding false
#define float_ftz_before_rounding true
fpu: allow flushing of output denormals to be after rounding Currently we handle flushing of output denormals in uncanon_normal always before we deal with rounding. This works for architectures that detect tininess before rounding, but is usually not the right place when the architecture detects tininess after rounding. For example, for x86 the SDM states that the MXCSR FTZ control bit causes outputs to be flushed to zero "when it detects a floating-point underflow condition". This means that we mustn't flush to zero if the input is such that after rounding it is no longer tiny. At least one of our guest architectures does underflow detection after rounding but flushing of denormals before rounding (MIPS MSA); this means we need to have a config knob for this that is separate from our existing tininess_before_rounding setting. Add an ftz_detection flag. For consistency with tininess_before_rounding, we make it default to "detect ftz after rounding"; this means that we need to explicitly set the flag to "detect ftz before rounding" on every existing architecture that sets flush_to_zero, so that this commit has no behaviour change. (This means more code change here but for the long term a less confusing API.) For several architectures the current behaviour is either definitely or possibly wrong; annotate those with TODO comments. These architectures are definitely wrong (and should detect ftz after rounding): * x86 * Alpha For these architectures the spec is unclear: * MIPS (for non-MSA) * RX * SH4 PA-RISC makes ftz detection IMPDEF, but we aren't setting the "tininess before rounding" setting that we ought to. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2025-02-01 16:39:08 +00:00
fpu: Make targets specify floatx80 default Inf at runtime Currently we hardcode at compile time whether the floatx80 default Infinity value has the explicit integer bit set or not (x86 sets it; m68k does not). To be able to compile softfloat once for all targets we'd like to move this setting to runtime. Define a new FloatX80Behaviour enum which is a set of flags that define the target's floatx80 handling. Initially we define just one flag, for whether the default Infinity has the Integer bit set or not, but we will expand this in future commits to cover the other floatx80 target specifics that we currently make compile-time settings. Define a new function floatx80_default_inf() which returns the appropriate default Infinity value of the given sign, and use it in the code that was previously directly using the compile-time constant floatx80_infinity_{low,high} values when packing an infinity into a floatx80. Since floatx80 is highly unlikely to be supported in any new architecture, and the existing code is generally written as "default to like x87, with an ifdef for m68k", we make the default value for the floatx80 behaviour flags be "what x87 does". This means we only need to change the m68k target to specify the behaviour flags. (Other users of floatx80 are the Arm NWFPE emulation, which is obsolete and probably not actually doing the right thing anyway, and the PPC xsrqpxp insn. Making the default be "like x87" avoids our needing to review and test for behaviour changes there.) We will clean up the remaining uses of the floatx80_infinity global constant in subsequent commits. 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-2-peter.maydell@linaro.org Message-id: 20250217125055.160887-2-peter.maydell@linaro.org
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,
/*
* 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.
*/
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,
/*
* 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,
fpu: Make targets specify floatx80 default Inf at runtime Currently we hardcode at compile time whether the floatx80 default Infinity value has the explicit integer bit set or not (x86 sets it; m68k does not). To be able to compile softfloat once for all targets we'd like to move this setting to runtime. Define a new FloatX80Behaviour enum which is a set of flags that define the target's floatx80 handling. Initially we define just one flag, for whether the default Infinity has the Integer bit set or not, but we will expand this in future commits to cover the other floatx80 target specifics that we currently make compile-time settings. Define a new function floatx80_default_inf() which returns the appropriate default Infinity value of the given sign, and use it in the code that was previously directly using the compile-time constant floatx80_infinity_{low,high} values when packing an infinity into a floatx80. Since floatx80 is highly unlikely to be supported in any new architecture, and the existing code is generally written as "default to like x87, with an ifdef for m68k", we make the default value for the floatx80 behaviour flags be "what x87 does". This means we only need to change the m68k target to specify the behaviour flags. (Other users of floatx80 are the Arm NWFPE emulation, which is obsolete and probably not actually doing the right thing anyway, and the PPC xsrqpxp insn. Making the default be "like x87" avoids our needing to review and test for behaviour changes there.) We will clean up the remaining uses of the floatx80_infinity global constant in subsequent commits. 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-2-peter.maydell@linaro.org Message-id: 20250217125055.160887-2-peter.maydell@linaro.org
2025-02-24 11:15:13 +00:00
} FloatX80Behaviour;
/*
* 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 {
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;
/* should denormalised results go to zero and set output_denormal_flushed? */
bool flush_to_zero : 1;
/* should denormalised inputs go to zero and set input_denormal_flushed? */
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;
/*
* Overriding float_snan_rule, is the single NaN representation for
* the OCP E4M3 format an SNaN or QNaN?
*/
bool e4m3_nan_is_snan : 1;
Float2NaNPropRule float_2nan_prop_rule : 3;
Float3NaNPropRule float_3nan_prop_rule : 7;
FloatInfZeroNaNRule float_infzeronan_rule: 3;
FloatX80Behaviour floatx80_behaviour : 5;
/*
* 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.
*/
unsigned default_nan_pattern : 8;
} float_status;
#endif /* SOFTFLOAT_TYPES_H */