Fix for issue #785: FPU fflags no being asserted correctly

[mikaelsky]

Patched up my fixes to the FPU to the current mainline from my local 1.9.3.0 checkout.

There are still challenges but these fixes makes the following riscof-arch F -> Zfinx tests pass:
rv32i_m_Zfinx_fadd_b1
rv32i_m_Zfinx_fadd_b10
rv32i_m_Zfinx_fadd_b11
rv32i_m_Zfinx_fadd_b12
rv32i_m_Zfinx_fadd_b13
rv32i_m_Zfinx_fadd_b2
rv32i_m_Zfinx_fadd_b3
rv32i_m_Zfinx_fadd_b4
rv32i_m_Zfinx_fadd_b5
rv32i_m_Zfinx_fadd_b7
rv32i_m_Zfinx_fadd_b8
rv32i_m_Zfinx_fclass_b1
rv32i_m_Zfinx_fcvt.s.w_b25
rv32i_m_Zfinx_fcvt.s.w_b26
rv32i_m_Zfinx_fcvt.s.wu_b25
rv32i_m_Zfinx_fcvt.s.wu_b26
rv32i_m_Zfinx_fcvt.w.s_b1
rv32i_m_Zfinx_fcvt.w.s_b22
rv32i_m_Zfinx_fcvt.w.s_b23
rv32i_m_Zfinx_fcvt.w.s_b24
rv32i_m_Zfinx_fcvt.w.s_b27
rv32i_m_Zfinx_fcvt.w.s_b28
rv32i_m_Zfinx_fcvt.w.s_b29
rv32i_m_Zfinx_fcvt.wu.s_b1
rv32i_m_Zfinx_fcvt.wu.s_b22
rv32i_m_Zfinx_fcvt.wu.s_b23
rv32i_m_Zfinx_fcvt.wu.s_b24
rv32i_m_Zfinx_fcvt.wu.s_b27
rv32i_m_Zfinx_fcvt.wu.s_b28
rv32i_m_Zfinx_fcvt.wu.s_b29
rv32i_m_Zfinx_fsub_b1
rv32i_m_Zfinx_fsub_b11
rv32i_m_Zfinx_fsub_b12
rv32i_m_Zfinx_fsub_b13
rv32i_m_Zfinx_fsub_b2
rv32i_m_Zfinx_fsub_b3
rv32i_m_Zfinx_fsub_b4
rv32i_m_Zfinx_fsub_b5
rv32i_m_Zfinx_fsub_b7
rv32i_m_Zfinx_fsub_b8

Some test have.. challenges.. with the F->Zfinx conversion as riscof-arch-test utilize sub-normals and the default Sail model supports sub-normals. All the test pass against a tuned RISCV architectural model where sub-normals are replaced with 0.0 as happens with the core.

[stnolting]

Thank you so much for your patch and the detailed description in #785!

[mikaelsky]

Its been on list to get to these for a Long time, finally get some time to get deep dive into the FPU :)
I do have another patch coming with a lot of different fixes all over the place. For this one I fixed fclass.s to correctly report out subnormals, but there are side effects so have added a generic "FPU_SUBNORMAL_SUPPORT" that defaults to false.
I opted for this path as you already put in a lot of subnormal checks which will need to by bypassed when we flush subnormals. Instead of removing the code I opted to wrap it in an if().

[stnolting]

Again, thank you so much for all your work!!

Instead of removing the code I opted to wrap it in an if().

The question is, do we really want to support subnormal numbers one day? I'm not sure about this. 🤔

[mikaelsky]

Its a good question. In principle the RISCV float spec requires sub-normal support. For now the core FPU extension doesn't fully support subnormals, even though I see some conditional checks here and there that seem correct.

Ideally we could keep as a future action to add support for subnormals (hence the generic) with the caveat that it will increase area. This is basically kicking the can down the road to some future point.

Right now the FPU patches are mostly aimed at getting to correct functionality btw. I'm sure some of them could benefit from some refactoring as well. Especially the exception paths. If we decide to just not support subnormals outside fclass and fsgn style operations then we can always just refactor out the conditional path.

Currently hammering away at the multiplier core exception paths.. there are quite a few :)

[stnolting]

Ideally we could keep as a future action to add support for subnormals (hence the generic) with the caveat that it will increase area. This is basically kicking the can down the road to some future point.

Sounds reasonable. 👍