Add zfbfinxmin extension

[Alex Bradbury (asb)]

With Zfinx, Zdinx, Zhinx, and Zhinxmin there's a clear precedent that floating point extensions should have an analogous "inx" version. As defining such a variant is straight-forward, I feel it would be most sensible (and efficient) to define it as part of the bfloat16 definition process rather than leaving a gap within the ISA to be filled at a later date.

This drafts such a definition. As the bfloat16 extensions are defined in new documentation rather than patches to the riscv-isa-manual, I've duplicated some explanatory text from the Zfinx chapater of the manual so that the zfbfinxmin definition makes sense standalone. If merging into the ISA manual, it would of course take a different form.

Fixes #27.

[Nicolas Brunie (nibrunieAtSi5)]

minor typos

[Alex Bradbury (asb)]

Thanks - I've fixed those typos and repushed.

[Nicolas Brunie (nibrunieAtSi5)]

I do not have an opinion on whether this should be integrated as part of this TG effort (I will let that to Kenneth Dockser (@kdockser)), but the definition of the extension looks sound to me.

[Craig Topper (topperc)]

Would FCVT.S.BF16 be equivalent to SLLI rd, rs1, 16?

[Nicolas Brunie (nibrunieAtSi5)]

How does NaN boxing works on Zdinx/Zfinx, does we need to inject 1s into the 32 MSBs in that case ? (which would not be handled by the SLLI if the input was not a proper single precision NaN-boxed float to begin with)

[Craig Topper (topperc)]

There are no FP load instructions with Zfinx so there's no guarantee that an input operand is properly nan-boxed for any FP instruction. So the hardware can't check that on inputs. FP instructions do still produce nan-boxed outputs.

So FCVT.BF16.S would not be exactly equivalent to SLLI for the upper bits. But since nan-boxing is already weakened for Zfinx is that important?

[Andrew Waterman (aswaterman)]

there's a clear precedent

Note that Zfa consciously did not define a Zfinx-compatible variant, instead leaving that to future work if demand ever arose. So we have already broken with keeping these things orthogonal. I'd be OK with punting this one, too, but it's not a strong opinion.

[Alex Bradbury (asb)]

there's a clear precedent

Note that Zfa consciously did not define a Zfinx-compatible variant, instead leaving that to future work if demand ever arose. So we have already broken with keeping these things orthogonal. I'd be OK with punting this one, too, but it's not a strong opinion.

Thanks for the important factual correction there. I'd overlooked zfa due to it not yet being ratified.

I don't think leaving it until later would be the worst thing ever - to my mind it depends a lot on what the overhead of spinning up an effort to revisit it at a later point. If that's fairly heavyweight, my preference in general would be that extensions like this (or to be honest zfa) make the minimal changes to ensure uniform support for z*inx (if that is indeed desirable).

Zfa having left *inx for a later date definitely strengthens the argument for doing the same here.