Re: [PATCH v3 05/19] fpu/softfloat: Support OCP(Open Compute Project) OFP8 data type

[Max Chou <max.chou@sifive.com>]

On 2026-02-05 14:36, Richard Henderson wrote:
> In particular, I think separating "no_infinity" and "limited_nan" leads to
> confusing checks, such as the one in parts_canonicalize where you test
> "limited_nan" in a context that is really testing for overflow to infinity.
> 
> Further, normal_frac_max is defined oddly, such that you have to test it
> twice, once vs frac_hi and once vs NORMAL_FRAC_MAX_ALL.  Since this is used
> for exactly one format, this is perhaps trying to be overly general.
> 
> I think better might be:
> 
>     typedef enum {
>         /* exp==max, frac==0 ? infinity : nan; this is ieee standard. */
>         float_maxexp_ieee,
>         /* exp==max is a normal number; no infinity or nan representation. */
>         float_maxexp_normal,
>         /* exp==max, frac==max ? nan : normal; no infinity. */
>         float_maxexp_e4m3,
>     } FloatFmtMaxExp;
> 
> We can stage in this behaviour without also including either FP8 format.
> Just changing Arm althp in a separate patch is large enough.
> 
> 
> r~

Hi Richard,

Thank you for the suggestions and v4 for softfloat part.
I agree that the original patch should be separated and the solution you
suggested is better.
I'll seperate the riscv isa part to another v4 patch based on the
softfloat v4.
And will also testing the softfloat v4 you provided and fix some
saturate issues on that.

Thanks a lot,
rnax