Update the reference to IEEE 754 to 2019 version

[omasanori]

Currently, the specification refers to IEEE 754-2008 as the floating-point arithmetic standard, though FMIN.* and FMAX.* refer to IEEE 754-201x (sic) and Zfa refers to IEEE 754-2019. IEEE 754-2019 is not in the bibliography list nevertheless. Using IEEE 754-2019 as the single source of IEEE 754-based floating-point arithmetic is desired.

Open questions:

• Does this change increase the version number of extensions?
  • FMIN.* and FMAX.* are already amended in Version 2.2. Does this change affect the behavior of other instructions?
• Do we need to create a TG under FP SIG for this change, or is a PR by random individuals (like me) enough?

[omasanori]

I found that BF16 has independent bibliography section and the both 2008 and 2019 versions are listed there. Also, that chapter uses the phrases IEEE-754 and '754, while the chapter of F extension uses the phrases IEEE 754-2008 standard consistently IEEE 754-2008 standard and IEEE 754-2008 arithmetic standard.

[omasanori]

The vector extension uses the phrase IEEE-754/2008.

[omasanori]

Cleanup that should never alter the specified behavior of instructions was finished. The remaining part is updating references to IEEE 754-2008 to IEEE 754-2019, and I think this part should be led by FP SIG. I sent a message to FP SIG.

[omasanori]

Cleanup that will never alter the specified behavior of instructions was finished. The remaining part is updating references to IEEE 754-2008 to IEEE 754-2019, and I think this part should be led by FP SIG. I sent a message to FP SIG.

Al Martin (Akeana) told me that IEEE 754-2019 should be backward compatible and just a PR without TG nor fast-track will be enough. I will make a PR after all cleanup PRs are merged.

Update: Guy Lemieux objects, and I agree with Guy: a careful review should be done before updating the references, when it actually happens.

[nibrunieAtSi5]

Thank you for starting this effort @omasanori

Can you provide arguments about

Using IEEE 754-2019 as the single source of IEEE 754-based floating-point arithmetic is desired.

Is this for uniformity ?
As Al Martin mentioned, if the standards revisions (2019 and 2008) are backward compatible for everything that matters in the RISC-V specifications, the update is either harmless or not desired. And as you listed, and as Guy Lemieux pointed out, we need to be very careful about this update not having unexpected side effects.

[omasanori]

Thank you for starting this effort @omasanori

Can you provide arguments about

Using IEEE 754-2019 as the single source of IEEE 754-based floating-point arithmetic is desired.

Is this for uniformity ?

Yes.

As Al Martin mentioned, if the standards revisions (2019 and 2008) are backward compatible for everything that matters in the RISC-V specifications, the update is either harmless or not desired. And as you listed, and as Guy Lemieux pointed out, we need to be very careful about this update not having unexpected side effects.

Agreed. Now I feel like closing this issue as not planed is okay to me.

Cleanup changes I have done made it explicit that RISC-V is based on IEEE 754-2008 with exceptions for FMIN, FMAX and Zfa. I think they are good without the update to IEEE 754-2019.

[Icenowy]

Sorry for disturbing a closed issue, but the IEEE754-2019 standard explicitly defines In binary interchange formats, all number and NaN encodings are canonical. . This is against the RISC-V spec, which defines The canonical NaN has a positive sign and all significand bits clear except the MSB, a.k.a. the quiet bit. For single-precision floating-point, this corresponds to the pattern 0x7fc00000. .