Number of FP regs for RV32EF and RV32EFD

[asb]

The specification was recently modified to make RV32EF and RV32EFD standard configurations. As things stand, I believe the spec has nothing particular to say about such a configuration, so these systems would have 32 floating point registers.

Is that what people building RV32EF and RV32EFD systems are likely to want? I could see an argument for having 16 FPRs to match the 16 GPRs.

[tovine]

Agreed, I recall that previously an argument for not allowing RV32EF[D] was that a floating-point unit (and its register file) would take up so much area and power that the point of having half the number of integer registers would be kind of moot.
Especially with double precision the 32x64-bit regfile would absolutely dwarf the savings from cutting 16 of the 32-bit integer registers...

But a 16 integer, 16 float register configuration could make more sense in such a scenario as one would still get some savings while retaining float capabilities.

[luismarques]

I think any (standard) floating-point extension having 16-FPRs should have a different name, rather than modifying F/D based on the prefix RV32E.

Even if we agree that for typical small systems it makes more sense to pair 16 GPRs with 16 FPRs, that doesn't rule out some plausible systems where we really might want 16 GPRs + 32 FPRs. E.g. some kind of floating-point acceleration workhorse with a few integer instructions for control. We would need to retain some way of naming that 16+32 combination, and the easier way to do that is to leave F/D to mean 32 FPRs.

[aswaterman]

The spec is currently unambiguous: EF has 15 + 32 registers. I agree that's probably not the right thing for most low-end systems, but it's also not obviously useless, as @luismarques points out.

We are going to propose an extension for low-end (and/or highly-threaded) systems called Zfinx (pronounced "f in x") that makes floating-point computations use the x-registers and removes the floating-point loads, stores, and moves between x-registers. There is a lot to talk about on this point, including its interaction with the precious RVC encoding space, and so we'll write a long email to the list about this idea.

[kasanovic]

As Andrew mentions there is a proposal to have a Zfinx option which needs to be written down and distributed. I'll leave this issue here, but am removing the Base ISA ratification tag, as this would be a different extension than those under discussion for ratification.

[asb]

I've made PR #281 which adds some commentary on this design decision (meant as a suggestion - obviously you might want to rewrite in a way that better matches your own view).

[aswaterman]

Merged #281, so closing.