MISA bit definition for half-precision floating-point extension

[chuanhua]

Could we define the MISA bit for half-precision floating-point extension using reserved K/O/R bits in MISA?

This bit is needed to indicate that if half-precision floating-point extension is present, then

1. If RVS is present, then FCVT.S.H and FCVT.H.S instructions will be added to RVS.
2. If RVD is present, then FCVT.H.D and FCVT.D.H instructions will be added to RVD.

[aswaterman]

Perhaps this has changed, but IIRC, the plan was for half-precision support to be coupled to the vector unit. So half-precision is present if (misa.V && misa.F).

[chuanhua]

The above condition of "if (misa.V && misa.F) is not sufficient to indicate half-precision support is present. It is possible that half-precision is not supported, so when SEW is 16, and a floating-point vector instruction will generate an exception.

[aswaterman]

That’s true.

[chuanhua]

I narrow my MISA bit selection for half-precision floating-point extension to K because the number of 16 is related to a hexaKaidecagon.

[aswaterman]

Ha! I was not aware of that term; I have only heard hexadecagon.

I agree allocating a letter like K is a reasonable approach.

[jscheid-ventana]

Is there an assumption about which half-precision format(s)?

…

-Josh

On Wed, Aug 7, 2019 at 2:41 AM Andrew Waterman ***@***.***> wrote: Ha! I was not aware of that term; I have only heard hexadecagon. I agree allocating a letter like K is a reasonable approach. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#414?email_source=notifications&email_token=ALLX6Q677QWS23WBWYKCIALQDKKFTA5CNFSM4IFWSJT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3X2X6Q#issuecomment-519023610>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALLX6Q3T3UKAENYM3KBPPTDQDKKFTANCNFSM4IFWSJTQ> .

[jim-wilson]

I did a little searching, and found that kai means "and" in greek, so hexakaidecagon is six and ten (poly)gon. Still, it looks like a reasonable mnemonic to remember what K stands for.

[aswaterman]

@jscheid-ventana IEEE 754. But given interest in bfloat16, there might be some desire to support that, too, possibly with the same opcodes and an fcsr mode switch.

[eak]

@aswaterman I would like to suggest two bits in the FCSR be added to indicate the format of 16-bit FP. 00 would IEEE, 01 would be bfloat16, and 10 would be some sort of 16-bit posit (since there seems to be some interest in posits, according to Krste). Of course an implementation is free to implement any subset of these if they implement 16-bit FP, trapping if the FCSR contains any unsupported value.

Comments?

[aswaterman]

We had been thinking along the same lines. (Note that for backwards compatibility, the field needs to be WARL, anyway, so the implementation can just refuse to write unsupported values, rather than trapping them.)

[eak]

WARL sounds good. Bits 8-9 perhaps? Or would it be good to reserve bits for 16-bit, 32-bit, 64-bit, and 128-bit at the same time? That might suggest 16-17, 18-19, 20-21, 22-23.

[aswaterman]

I don't think we need to support full associativity of format: it doesn't make much sense to be able to configure the machine such that the 16-bit mode is bfloat, the 32-bit mode is posit, and the 64-bit mode is IEEE, for instance.

In any case, all of the fcsr bits are reserved for standard use, so we don't need to pre-allocate them. Along the same lines, we don't actually need to reserve space for the posit format until we specify such an extension.

[pdonahue-ventana]

There was a recent proposal to add a bit to fcsr to indicate support for half-precision FP. An argument was made that this was undesirable partially due to headaches for classical virtualization.

Is it any more desirable to expose WARL bits to U mode in fcsr without the ability to trap the fcsr read access (other than the big hammer of trapping all FP operations)? The term WARL is only in the privileged architecture and there are no WARL bits in the unprivileged ISA.

[aswaterman]

The virtualization argument was specifically about the register behaving differently in different privilege modes, which does not apply here. Any proposal that adds new fields to FCSR really must be WARL, because existing implementations will read those fields as zero.

…

On Tue, Aug 20, 2019 at 9:53 AM Paul Donahue ***@***.***> wrote: There was a recent proposal <https://lists.riscv.org/g/tech-privileged/message/640> to add a bit to fcsr to indicate support for half-precision FP. An argument <https://lists.riscv.org/g/tech-privileged/message/642> was made that this was undesirable partially due to headaches for classical virtualization. Is it any more desirable to expose WARL bits to U mode in fcsr without the ability to trap the fcsr read access (other than the big hammer of trapping all FP operations)? The term WARL is only in the privileged architecture and there are no WARL bits in the unprivileged ISA. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#414?email_source=notifications&email_token=AAH3XQVZLAABOQTI2NOAT6LQFQOO7A5CNFSM4IFWSJT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4W6K2A#issuecomment-523101544>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAH3XQQJSG5FYSA32RSVE4DQFQOO7ANCNFSM4IFWSJTQ> .

[pdonahue-ventana]

I just want to bring to your attention that software cannot emulate an implementation that supports non-IEEE half-precision without trapping all FP instructions of all sizes (even if single and double are natively supported or software doesn't actually use non-IEEE half-precision), solely because there is no mechanism to trap accesses to fcsr without trapping accesses to all FP.

I see that ARMv8 has the same limitation so perhaps nobody cares about this case.

[aswaterman]

Yep. That concern should be weighed when making this decision.

[eak]

This could be viewed as a reason to get it into the ISA as soon as possible, so implementations can add the bit(s) and trap if it is set if they don't implement bfloat16. It is another reason to make it a 2-bit field initially (again so they can trap if a non-zero value is there).

[aswaterman]

Indeed.

…

On Tue, Aug 20, 2019 at 12:06 PM Earl Killian ***@***.***> wrote: This could be viewed as a reason to get it into the ISA as soon as possible, so implementations can add the bit(s) and trap if it is set if they don't implement bfloat16. It is another reason to make it a 2-bit field initially (again so they can trap if a non-zero value is there). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#414?email_source=notifications&email_token=AAH3XQUMMRHWI2M3QNIX7U3QFQ6D5A5CNFSM4IFWSJT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4XLAEQ#issuecomment-523153426>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAH3XQRWH2G3Q5OUAN2DVCDQFQ6D5ANCNFSM4IFWSJTQ> .

[eak]

Do we need to move this to the tech mailing list?

[aswaterman]

It's being discussed in tech-privileged

…

On Tue, Aug 20, 2019 at 1:22 PM Earl Killian ***@***.***> wrote: Do we need to move this to the tech mailing list? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#414?email_source=notifications&email_token=AAH3XQWNXCICCZA3C2L5TF3QFRG7BA5CNFSM4IFWSJT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4XRKGI#issuecomment-523179289>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAH3XQUOSCV5YIN75FR2OY3QFRG7BANCNFSM4IFWSJTQ> .

[nihui]

Hi, what is the status now ?
Is there any way for non-privileged code to discover if the processor supports risc-v zfh extension ?
We need a runtime detector function for dispatching proper optimized code path based on processor capability.
Thanks.

[gfavor]

A new "unified low-level RISC-V discovery method" is in the works. This will support discovery, for all arch extensions, of the support for the extension as well as the support for any options within the extension and supported values for any key parameters within the extension.

Note that this is the "low-level" discovery method that, for example, M-mode software would use to populate info into high-level discovery structures such as Device Tree. The "runtime detector function" obviously is a function of the system environment (e.g Linux, RTOS, bare-metal, ...) and how the toolchain and loader and user discovery are handle all this.

[kersten1]

Any recent status for this one?

[aswaterman]

I think @gfavor’s comment from a few years ago is conclusive.

[nihui]

Hello everyone, if you want to implement detection on an old version of the kernel, the ruapu project is a good reference. It handles sigill and completes the detection of the extended instruction set.

https://github.com/nihui/ruapu