On Tue, 19 May 2026 at 22:52, Richard Henderson
<[email protected]> wrote:
>
> On 5/19/26 06:41, Peter Maydell wrote:
> > Also, I realized that this squashing mechanic means we can't do
> > the handling of invalid input formats the way we do at the moment.
> > The float_raise() operations done by fp8_invalid_input() will
> > get squashed for multiplies. I think the fp8_invalid_output() part
> > is still OK because we only use it in the FP8 convert operations.
> >
> > We could perhaps have fp8_mul_start() explicitly check for fmt1
> > or fmt2 being fp8_invalid_input -- it has access to the real
> > fp_status so can raise Invalid and InvalidSNaN there.
>
> Here's the thing:
>
> FP8Unpack doesn't raise an exception itself, just sets fptype = FPType_SNaN.
>
> For FP8ConvertFP, we then explicitly raise invalid and return default nan.
>
> For FP8DotAddFP, we notice nans within a loop, setting any_nan; after the
> loop, if any_nan
> is set, we return default nan but do not raise invalid.
>
> So I guess we don't need to do anything special during fp8_mul_start.
Yes, you're right. I read the FPMR.F8D text about raising
Invalid and assumed it applied also to F8S1 and F8S2, but it
doesn't -- invalid format for source merely means "it's an SNaN",
and doesn't explicitly raise Invalid at all.
Also, it looks like "treat as SNaN" and "return 0xff, raise Invalid" are
both merely "implementation is permitted to" choices (that the
pseudocode takes) added to the usual set of CONSTRAINED
UNPREDICTABLE appending options for setting fields to reserved
values. So we don't need to be super picky about what we do.
> One thing I could do that might be slightly clearer is
>
> static FloatParts64 fp8_invalid_input(uint8_t x, float_status *s)
> {
> /*
> * Invalid input format is treated as snan, then one of the uses
> * will convert to default nan and raise invalid.
> */
> return (FloatParts64){ .cls = float_class_snan };
> }
>
> What do you think?
That's probably clearer. I guess.
Maybe have the comment:
/*
* Invalid input format: we could take one of the usual set of
* CONSTRAINED UNPREDICTABLE options for use of a reserved value,
* but choose to take the additional option provided by the
* FPMR register specification, of treating the input as if
* it were an SNaN.
*/
and similarly for output but
"...of setting the result to 0xff and signaling Invalid Operation".
?
thanks
-- PMM
