Public review for standard extensions Zfinx, Zdinx, Zhinx, Zhinxmin

[Tariq Kurd]

We are delighted to announce the start of the public review period for the following proposed standard extensions to the RISC-V ISA:

Zfinx - Single-precision floating point in integer registers

Zdinx - Double-precision floating point in integer registers

Zhinx - Half-precision floating point in integer registers

Zhinxmin - Minimal 16-bit half-precision floating point in integer registers

The review period begins today, Tuesday August 3rd, 2021, and ends on Friday September 17, 2021 (inclusive).

These extensions are described in the PDF spec available at:

https://github.com/riscv/riscv-zfinx/blob/main/zfinx-1.0.0-rc.pdf

which was generated from the source available in the following GitHub repo:

https://github.com/riscv/riscv-isa-manual/releases/tag/draft-20210802-678f869

To respond to the public review, please either email comments to the public isa-dev mailing list or add issues to the Zfinx GitHub repo: https://github.com/riscv/riscv-zfinx . 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 Zfinx task group. 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 specifications 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.

Tariq Kurd

Chair, Zfinx Task Group

[Ray Van De Walker]

I reviewed the spec; Looks useful. In an economical high-end embedded CPU (my professional programming environment),

I would prefer it to standard F, D and Q subsets, provided the compiler(s) supported it. Which also looks economical.

 

But, the “future discovery procedure” should be elaborated before release.

 

I don’t want to propose Yet Another Configuration Method.

 

What is the community already using for open-ended Z* feature discovery and configuration?

Might the Z* extensions -recommend- or even -require- these usage(s) for discovery?

(i.e. a minor clarification of the Z* specs.)

 

Best Regards

Ray

--
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/8e6d6fea-8ab3-4471-9614-60615394ff1en%40groups.riscv.org.

[Andrew Waterman]

On Tue, Aug 3, 2021 at 11:40 AM Ray Van De Walker <ray.van...@silergy.com> wrote:

I reviewed the spec; Looks useful. In an economical high-end embedded CPU (my professional programming environment),

I would prefer it to standard F, D and Q subsets, provided the compiler(s) supported it. Which also looks economical.

 

But, the “future discovery procedure” should be elaborated before release.

 

I don’t want to propose Yet Another Configuration Method.

 

What is the community already using for open-ended Z* feature discovery and configuration?

Might the Z* extensions -recommend- or even -require- these usage(s) for discovery?

(i.e. a minor clarification of the Z* specs.)

I'll let someone who is participating in that effort respond in a separate thread (or provide a pointer to another existing thread).

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/BY5PR20MB3202E713A74F43C2125BEDAAF0F09%40BY5PR20MB3202.namprd20.prod.outlook.com.

[Greg Favor]

What is the community already using for open-ended Z* feature discovery and configuration?

Might the Z* extensions -recommend- or even -require- these usage(s) for discovery?

(i.e. a minor clarification of the Z* specs.)

RISC-V is developing a "unified low-level discovery method" that is friendlier and easier to use than all the ad hoc current mechanisms.  This is intended to be used by all architectural extensions for whatever info needs to be discoverable (which for some extensions may simply be whether the extension is supported or not, while others may have a lot of info to be discoverable).

Discovery overall, and how that integrates in with low-level firmware, with OS's and toolchains, and with things like Device Tree and ACPI, is a broad topic.  But the core parts are being developed by the tech-config Task Group with a goal of having the basics spec'ed out by the end of this year.  Roughly in parallel with many new RISC-V extensions getting ratified by the end of this year.  So then next year all this can start coming together in real designs.

Greg

 

[Torbjørn Viem Ness]

Quick question about Zhinxmin (it seems to have appeared after the spec meetings):

The spec reads: "The Zhinxmin extension includes the following instructions from the Zhinx extension: FCVT.S.H and FCVT.H.S."

Is the idea here then to do the actual computations in single precision before/after using these instructions to convert the result/operands to/from half precision, without having to include support for the operations themselves in 16-bit precision?

[Nick Knight]

Hi Torbjørn,

Yes:

This section describes the Zfhmin standard extension, which provides minimal
support for 16-bit half-precision binary floating-point instructions.
The Zfhmin extension is a subset of the Zfh extension, consisting only
of data transfer and conversion instructions.
Like Zfh, the Zfhmin extension depends on the single-precision floating-point
extension, F.
The expectation is that Zfhmin software primarily uses the half-precision
format for storage, performing most computation in higher precision.

https://github.com/riscv/riscv-isa-manual/blob/master/src/zfh.tex#L383-L390

I think your question is really about the Zfh/min extensions. These proposed "in-x" extensions are just variants that avoid the separate floating-point register file.

Best,

Nick

--

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/71850e5b-3f67-4d0b-9a08-b934d4e4c571n%40groups.riscv.org.

[Torbjørn Viem Ness]

Hi,

Thanks Nick, I haven't followed the Zfh developments lately so I missed that one.

Of course there should be a corresponding Z*inx extension for each floating point extension, no issues with that! Was just wondering if this was a new invention here. :)

--

Med vennlig hilsen,

Torbjørn Viem Ness

---

From: Nick Knight <nick....@sifive.com>
Sent: Wednesday, August 4, 2021 10:41:37 PM
To: Torbjørn Viem Ness <tbn...@gmail.com>
Cc: RISC-V ISA Dev <isa...@groups.riscv.org>; Greg Favor <greg....@gmail.com>; ray.vandewalker <ray.van...@silergy.com>
Subject: Re: [isa-dev] Public review for standard extensions Zfinx, Zdinx, Zhinx, Zhinxmin

 

[RISCV Opinion]

Perhaps it is not too late to suggest we recover most of the 3 major opcodes spaces used by the MADD instructions.

Most wonderfully, we can use the zero register in the rs3 field to identify the destructive form of this instruction.

We can of course over time phase out the 4 register formats where rs3 <> 0, but better to do it from the start..

The rs3=0 destructive form is redundant anyway in FinX.

[Tariq and Laura]

Hi Torbjorn,

I think it's too late as the ratification vote is this week. However it's possible to define a newer Zfinx subset in the future which excludes them, just like Zmmul is M without div/rem.

Tariq

You received this message because you are subscribed to a topic in the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/groups.riscv.org/d/topic/isa-dev/-9slOJF_6IQ/unsubscribe.
To unsubscribe from this group and all its topics, 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/c5fa0e17-e153-4e88-97d3-41c135eb6c50n%40groups.riscv.org.

[David Horner]

On 2021-11-15 4:08 a.m., Tariq and Laura wrote:

Hi Torbjorn,

I think it's too late as the ratification vote is this week.

The ratification vote this week has nothing to do with too late.

It is after all a vote, and not a counting of ballots.

If the powers that be believe they can wait to include this recommendation, they can.

Rather it is too late because the "spec" was frozen August 3rd, 2021.

At that point this recommendation became untimely as it involves substantial change.

Granted there was no 45 day review before the spec transferred from stable to frozen.

But the die was probably cast much earlier on, as the "design" review did not challenge the reasonableness of retaining the float overhead.

The design justification was substantially that we could do a plug in replacement and use as much of the current infrastructure as possible.

That did not lead peoples thinking towards systemic improvement. Nor was the TG tasked with that responsibility, that is abdicated/punted to the ARC.

I'm glad we are at least considering an XFinX extension "extension" to recover substantial opcode space.

I am surprised, though, because

  a) when I suggested that we would never have allocated 3 major opcodes for MADD in the FDQH extension if we had implemented FinX first,

  no one then suggested we could fix this as an after-extension.

  b) according to ARC we have an over abundance of opcode space. 

     Why make the effort to recover any if we don't have a desperate immediate need?

     (I have arguments for that, but it appears the thinking is "consider the source" or "block the email address".)

However it's possible to define a newer Zfinx subset in the future which excludes them, just like Zmmul is M without div/rem.

It is, however, substantially different. Recovery of opcode space has key points of opportunity, such as in the transition to a major architectural change, like ZFinX.

If it is not done then it will be deferred until we are desperately in need of 32bit opcode space, all admit our mistake(s) and do the churn at a less opportune and more disruptive time.

Although well meaning, this suggestion is not a solution. At best it is a token concession/offering.

[I would be very happy if y'all prove me wrong].

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAJLjqPbtL9_8QBXECE7AvDiOMcHLN5g9_DognU%3DeGktfX7iLwA%40mail.gmail.com.