Re: [PATCH 06/10] fpu: Move m68k_denormal fmt flag into floatx80_behaviour

[Richard Henderson <richard.henderson@linaro.org>]

On 2/20/25 10:54, Peter Maydell wrote:
> On Thu, 20 Feb 2025 at 18:39, Richard Henderson
> <richard.henderson@linaro.org> wrote:
>>
>> On 2/20/25 09:12, Peter Maydell wrote:
>>> That suggests that we are correctly implementing the x87
>>> required behaviour in QEMU, and so that the TODO comment
>>> I add in this patch isn't right. But then I'm a bit confused
>>> about what the code is actually doing. Why do we need to look
>>> at fmt->m68k_denormal in the input (canonicalize) code (i.e.
>>> to have different behaviour here for x86 and m68k), if
>>> both x86 and m68k accept these pseudodenormals as input?
>>>
>>> Is the difference that for x86 we accept but canonicalize
>>> into the equivalent normal number immediately on input,
>>> whereas for m68k we accept and leave the pseudodenormal
>>> as a pseudodenormal (well, m68k calls these a kind of
>>> normal number) ?
>> The difference is in interpretation: x86 ignores the explicit integer bit of the
>> pseudo-denormal, m68k considers it part of the input value.  This gives m68k one extra bit
>> of range in their denormal, which allows representation of smaller numbers.
> 
> Ah, I see. So I suppose:
> 
> (1) we should call the floatx80_status flag
> "floatx80_pseudo_denormal_valid" since it affects both inputs
> and outputs, and document it in the enum like:
> 
> +    /*
> +     * 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,
> 
> 
> (2) the comment I add in canonicalize should instead read:
> 
> +    /*
> +     * It's target-dependent how to handle the case of exponent 0
> +     * and Integer bit set. Intel calls these "pseudodenormals",
> +     * and treats them as if the integer bit was 0, and never
> +     * produces them on output. This is the default behaviour for QEMU.
> +     * 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,
> +     * but that distinction is not important for us, because
> +     * m68k doesn't care about the input_denormal_used status flag.)
> +     * floatx80_pseudo_denormal_valid selects the m68k behaviour,
> +     * which changes both how we canonicalize such a value and
> +     * how we uncanonicalize results.
> +     */
> 

Looks good.


r~