Public review of Zfa Standard Extension for Additional Floating-Point Instructions

248 views
Skip to first unread message

Krste Asanovic

unread,
May 3, 2023, 2:16:16 PM5/3/23
to RISC-V ISA Dev, tech-a...@lists.riscv.org, Earl Killian
We are delighted to announce the start of the public review period for the following proposed Fast Track extensions to the RISC-V ISA:

Zfa

The review period begins today, May 3, 2023 and ends on June 2, 2023 (inclusive).

This extension is part of the Unprivileged Specification.

These extensions are described in the PDF spec available at:
https://drive.google.com/file/d/1qNISmwkxHMjyTPihcRAgQIAAZfxu6pav/view?usp=share_link

which was generated from the source available in the following GitHub repo:
https://github.com/riscv/riscv-isa-manual

To respond to the public review, please either email comments to the public isa-dev mailing list or add issues and/or pull requests to the RISC-V ISA Manual GitHub repo,  https://github.com/riscv/riscv-isa-manual. We welcome all input and appreciate your time and effort in helping us by reviewing the specification.

During the public review period, corrections, comments, and suggestions, will be gathered for review by the  Unprivileged ISA Committee. Any minor corrections and/or uncontroversial changes will be incorporated into the specification. Any remaining issues or proposed changes will be addressed in the public review summary report. If there are no issues that require incompatible changes to the public review specification, the Unprivileged ISA Committee will recommend the updated specification be approved and ratified by the RISC-V Technical Steering Committee and the RISC-V Board of Directors.

Thanks to all the contributors for all their hard work.

Krste Asanović
Chair,  Unprivileged ISA Committee

Earl Killian
Vice-chair,  Unprivileged ISA Committee

Jeff Scott

unread,
May 3, 2023, 3:26:38 PM5/3/23
to Krste Asanovic, RISC-V ISA Dev, Earl Killian

I don’t see a mention of Zfinx here, but it does say: “The Zfa extension depends on the F extension.”.

 

All of these look applicable to Zfinx as well, except for the move instructions.

 

Tried to post to zfinx mail list, but I guess it is closed now.

 

Jeff

 

From: 'Krste Asanovic' via RISC-V ISA Dev <isa...@groups.riscv.org>
Sent: Wednesday, May 3, 2023 1:16 PM
To: RISC-V ISA Dev <isa...@groups.riscv.org>; tech-a...@lists.riscv.org
Cc: Earl Killian <earl.k...@arilinc.com>
Subject: [EXT] [isa-dev] Public review of Zfa Standard Extension for Additional Floating-Point Instructions

 

Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using the 'Report this email' button

 

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/5A6C3B03-FCD3-4318-8408-252061CB7795%40sifive.com.

Vadim Sukhomlinov

unread,
May 3, 2023, 3:58:29 PM5/3/23
to Jeff Scott, Krste Asanovic, RISC-V ISA Dev, Earl Killian
I'm curious about the justification for FLI constants - why not to have e, pi, 10, 0.1 instead of 0.875, 0.625 and similar ones? 

Vadim

Andrew Waterman

unread,
May 3, 2023, 4:37:52 PM5/3/23
to Vadim Sukhomlinov, Jeff Scott, Krste Asanovic, RISC-V ISA Dev, Earl Killian
The Unprivileged ISA Committee explained the rationale for the choice of constants in this thread: https://github.com/riscv/riscv-isa-manual/issues/1009

Vadim Sukhomlinov

unread,
May 3, 2023, 4:42:05 PM5/3/23
to Andrew Waterman, Jeff Scott, Krste Asanovic, RISC-V ISA Dev, Earl Killian
Andrew, thanks for the reference!

Bruce Hoult

unread,
May 4, 2023, 1:17:21 AM5/4/23
to Krste Asanovic, RISC-V ISA Dev, tech-a...@lists.riscv.org, Earl Killian
All looks sensible, even the FJCVTZS clone (wait until hn notices that...).

Wish I'd noticed this before because there are a couple of cheap instructions it would be very good to add too.  OK, transcendental constants were ruled out (sadly), but also:

- FEXP. Extracts the exponent from a double precision operand register, debiases the exponent, and delivers an integer result in the range [-1077..+1023]

- FFRAC. Normalises (if necessary) an FP value, then sets the exponent to the bias, thus returning a value in [1.0, 2.0).

- FADDEXP. Adds an integer to the exponent of a double precision operand giving a double precision result (possibly newly INF, 0, or denormalised).

Along with FCLASS (which we already, thankfully, have), these instructions are very useful for accelerating the implementation of transcendental functions.

I have experience using these instructions in other ISAs.

Christian Herber

unread,
May 4, 2023, 12:15:00 PM5/4/23
to RISC-V ISA Dev, Jeff Scott, Earl Killian, Krste Asanovic
Not including Zfinx could be a big opportunity missed. Changing some parts of Zfa to depend on Zfinx or F (likewise D/Q) instead of just D/F/Q seems like a low hanging fruit. Including it now rather than in an additional extension later down the road will reduce the overall effort throughout the processes and ecosystem.

Alex Bradbury

unread,
May 4, 2023, 1:06:23 PM5/4/23
to Christian Herber, RISC-V ISA Dev, Jeff Scott, Earl Killian, Krste Asanovic
FWIW there's a related discussion about this in the context of the bfloat16 extensions here <https://github.com/riscv/riscv-bfloat16/pull/31>. Even taking into account software ecosystem cost, I agree specifying things like zfinx support up-front may reduce effort overall as the enablement work and reviews can be done once, rather than returned to some time down the road.

Best,

Alex

BGB

unread,
May 4, 2023, 1:36:55 PM5/4/23
to isa...@groups.riscv.org
On 5/4/2023 12:05 PM, Alex Bradbury wrote:
> FWIW there's a related discussion about this in the context of the
> bfloat16 extensions here
> <https://github.com/riscv/riscv-bfloat16/pull/31
> <https://github.com/riscv/riscv-bfloat16/pull/31>>. Even taking into
> account software ecosystem cost, I agree specifying things like zfinx
> support up-front may reduce effort overall as the enablement work and
> reviews can be done once, rather than returned to some time down the road.
>

In my project, I am mostly using Binary16 (S.E5.F10) rather than
BFloat16 (S.E8.F7), as for many tasks Binary16 has better properties
(albeit less dynamic range). Binary16 effectively being useful for "lots
of random stuff".

One could argue maybe the general case might have been better served
with S.E6.F9, but alas...


I also personally prefer Zfinx/Zdinx over F/D, but alas most of the
existing software ecosystem seems to prefer F/D.


> Best,
>
> Alex
>
> On Thu, 4 May 2023 at 17:15, Christian Herber
> <christia...@oss.nxp.com <mailto:christia...@oss.nxp.com>> wrote:
>
> Not including Zfinx could be a big opportunity missed. Changing some
> parts of Zfa to depend on Zfinx or F (likewise D/Q) instead of just
> D/F/Q seems like a low hanging fruit. Including it now rather than
> in an additional extension later down the road will reduce the
> overall effort throughout the processes and ecosystem.
>
> On Wednesday, May 3, 2023 at 9:26:38 PM UTC+2 Jeff Scott wrote:
>
> I don’t see a mention of Zfinx here, but it does say: “The Zfa
> extension depends on the F extension.”.____
>
> __ __
>
> All of these look applicable to Zfinx as well, except for the
> move instructions.____
>
> __ __
>
> Tried to post to zfinx mail list, but I guess it is closed now.____
>
> __ __
>
> Jeff____
>
> __ __
>
> *From:* 'Krste Asanovic' via RISC-V ISA Dev
> <isa...@groups.riscv.org>
> *Sent:* Wednesday, May 3, 2023 1:16 PM
> *To:* RISC-V ISA Dev <isa...@groups.riscv.org>;
> tech-a...@lists.riscv.org
> *Cc:* Earl Killian <earl.k...@arilinc.com>
> *Subject:* [EXT] [isa-dev] Public review of Zfa Standard
> Extension for Additional Floating-Point Instructions____
>
> __ __
>
>
>
> *Caution:*This is an external email. Please take care when
> clicking links or opening attachments. When in doubt, report the
> message using the 'Report this email' button ____
>
> __ __
>
> We are delighted to announce the start of the public review
> period for the following proposed Fast Track extensions to the
> RISC-V ISA:
>
> Zfa
>
> The review period begins today, May 3, 2023 and ends on June 2,
> 2023 (inclusive).
>
> This extension is part of the Unprivileged Specification.
>
> These extensions are described in the PDF spec available at:____
>
> https://drive.google.com/file/d/1qNISmwkxHMjyTPihcRAgQIAAZfxu6pav/view?usp=share_link <https://drive.google.com/file/d/1qNISmwkxHMjyTPihcRAgQIAAZfxu6pav/view?usp=share_link>
>
> which was generated from the source available in the following
> GitHub repo:____
>
> https://github.com/riscv/riscv-isa-manual
> <https://github.com/riscv/riscv-isa-manual>
>
> To respond to the public review, please either email comments to
> the public isa-dev mailing list or add issues and/or pull
> requests to the RISC-V ISA Manual GitHub repo,
> https://github.com/riscv/riscv-isa-manual
> <https://github.com/riscv/riscv-isa-manual>. We welcome all
> input and appreciate your time and effort in helping us by
> reviewing the specification.
>
> During the public review period, corrections, comments,
> and suggestions, will be gathered for review by the
> Unprivileged ISA Committee. Any minor corrections and/or
> uncontroversial changes will be incorporated into the
> specification. Any remaining issues or proposed changes will be
> addressed in the public review summary report. If there are
> no issues that require incompatible changes to the public
> review specification, the Unprivileged ISA Committee will
> recommend the updated specification be approved and ratified by
> the RISC-V Technical Steering Committee and the RISC-V Board of
> Directors.
>
> Thanks to all the contributors for all their hard work.
>
> Krste Asanović
> Chair,  Unprivileged ISA Committee____
>
> __ __
>
> Earl Killian____
>
> Vice-chair,  Unprivileged ISA Committee____
>
> __ __
>
> --
> You received this message because you are subscribed to the
> Google Groups "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to isa-dev+u...@groups.riscv.org.
> To view this discussion on the web visit
> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/5A6C3B03-FCD3-4318-8408-252061CB7795%40sifive.com <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/5A6C3B03-FCD3-4318-8408-252061CB7795%40sifive.com?utm_medium=email&utm_source=footer>.____
>
> --
> You received this message because you are subscribed to the Google
> Groups "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to isa-dev+u...@groups.riscv.org
> <mailto:isa-dev+u...@groups.riscv.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/afdf7f06-6d53-4923-9fe3-472356eab136n%40groups.riscv.org <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/afdf7f06-6d53-4923-9fe3-472356eab136n%40groups.riscv.org?utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to isa-dev+u...@groups.riscv.org
> <mailto:isa-dev+u...@groups.riscv.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CA%2BwH296ViLBwk1NKBXJbOCYgLjGL%2B4eZWeiScK7j69AAEHoBwA%40mail.gmail.com <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CA%2BwH296ViLBwk1NKBXJbOCYgLjGL%2B4eZWeiScK7j69AAEHoBwA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

Andrew Waterman

unread,
May 4, 2023, 5:26:16 PM5/4/23
to Christian Herber, RISC-V ISA Dev, Jeff Scott, Earl Killian, Krste Asanovic
I don't disagree with the value of a "Zfainx" extension.  However, at this stage in Zfa's life cycle, pursuing Zfainx as part of the same ratification package will add a few months to Zfa's ratification clock: simulators and compilers must be built as a prerequisite, and architecture review and IC/HC review must occur again.  Since Zfa is immediately useful, I don't think slowing it down is the right way to go.

If you want to push for the creation of a Zfainx fast-track, I think you'll find support.  If that gets started promptly, it won't be delayed much beyond what I described above, since the long pole will likely be the software work.

Jeff Scheel

unread,
Jun 26, 2023, 10:23:41 AM6/26/23
to RISC-V ISA Dev
This email is being sent of behalf of Krste Asanović, Earl Killian, and Andrew Waterman.

******

Feedback on the Zfa extension largely fell into two categories: suggestions for future work and questions about design decisions.  The suggestions for future work may make sense as future extensions, but there is immediate value in plugging the gaps addressed by Zfa, and these should not slow down its RISC-V inclusion.  The questions about the design decisions were answered during the public-review period and are summarized below.
 
We recommend that Zfa be ratified in its current form.
 
Christian Herber and others identified that a variant of Zfa that is compatible with Zfinx (as opposed to F) would be desirable.  We do not disagree, but this would be a separate extension, since Zfa requires F. The interested parties could pursue development of a "Zfainx" extension.
 
Christian Herber also raised the point that Zfa's register-pair handling differs from that in RV32_Zdinx.  This is by design.  The latter's handling of register pairs is acceptable for simple implementations but adds complexity to  implementations with register renaming, which are a target of Zfa.
 
Several people named instructions they would have liked to have seen included in Zfa, including e.g. instructions for extracting and manipulating exponents. We expect additional floating-point extensions will be developed over time; these new extensions may include those instructions.
 
Several people raised concerns about the set of constants chosen for the FLI instructions.  The choices stemmed from the goal to minimize the encoding cost and implementation cost of these instructions, and from static analysis of various libraries.  A more detailed explanation can be viewed here:
 
Anders Lindgren mentioned that it is not obvious how the FLEQ/FLTQ instructions are used by C programs.  C99 provides routines that map to these, e.g.: 

Thanks to all for who contributed to the discussion.


Krste Asanović
Chair,  Unprivileged ISA Committee
 
Earl Killian
Vice-chair,  Unprivileged ISA Committee

Andrew Waterman
Zfa Specification Author
Reply all
Reply to author
Forward
0 new messages