riscv-opcodes-master and ISA definition process

[L Peter Deutsch]

Please let me know if this question is answered somewhere obvious, or
if I should be asking it somewhere else.

I just downloaded the contents of riscv-opcodes-master, and found them
confusing:

* They include a Zfh extension that I haven't seen mentioned elsewhere,
and whose ratification status I'm unsure of.

* They are missing some Zk* opcodes that are currently at v1.0 public
review.

* They include many opcodes have not reached public review (parts of
Zb*, all of Zp* and Zv*).

* They do not identify sub-extensions, e.g., the various subdivisions
of Zb* and Zk*.

They also don't deal with extensions that remove or redefine
instructions (Z[fdh]inx) or only impose implementation restrictions
(Zkt), but I wouldn't expect that from a simple opcode list.

Is there a single repository that contains all ratified extensions?
Is there a single place that catalogues the status of all extensions
being considered by working groups, ratified or not (yet)? How does
riscv-opcodes-master fit into the overall ISA definition process?

Thanks -

L Peter Deutsch <gh...@major2nd.com> :: Aladdin Enterprises :: Healdsburg, CA

Was your vote really counted? http://www.verifiedvoting.org

[Jim Wilson]

On Sun, Sep 5, 2021 at 11:50 AM L Peter Deutsch <gh...@major2nd.com> wrote:

* They include a Zfh extension that I haven't seen mentioned elsewhere,
and whose ratification status I'm unsure of.

The half-width float extension was on the short list for approval last year, but that didn't happen.  I think it is still on the short list.  I would expect that a lot of cores that implement the V extension will also want to implement zfh to make it easier to port code from other targets and to make V more useful.

There is a spreadsheet that lists the status of all extensions.  You can find it from the Tech wiki home page

    https://wiki.riscv.org/display/TECH/Tech+Home

Scroll down to the specification status link which is

    https://docs.google.com/spreadsheets/d/1qzu6b9kgADGjaa5fd1Qla7b9gCMOaEnGO5bUVu2oPys/edit#gid=84142006

See row 48.

For a while the zfh docs were on the zfh branch of riscv-isa-manual for a while.  They are now on master and documented as a draft.

 

* They are missing some Zk* opcodes that are currently at v1.0 public
review.
* They include many opcodes have not reached public review (parts of
Zb*, all of Zp* and Zv*).

Shrug.  Maybe just the difficulty of keeping everything in sync and up to date.  There are far too many extensions being discussed, which are undergoing far too many changes, that it is very hard to keep track of everything.

* They do not identify sub-extensions, e.g., the various subdivisions
of Zb* and Zk*.

The decision was made that there are no sub extensions.  Only extensions.  So there is no longer a B extension, only zba, zbb, zbc, etc.  And hence there is no longer a K extension, only various zk*.  I don't know where the decision was made or announced.  I and the other compiler people heard about it secondhand and will now have to fix the software tools.

They also don't deal with extensions that remove or redefine
instructions (Z[fdh]inx) or only impose implementation restrictions
(Zkt), but I wouldn't expect that from a simple opcode list.

Yes, I think that is outside the scope of riscv-opcodes.

Is there a single repository that contains all ratified extensions?
Is there a single place that catalogues the status of all extensions
being considered by working groups, ratified or not (yet)?  How does
riscv-opcodes-master fit into the overall ISA definition process?

I pointed at the specification status spreadsheet.  I think riscv-isa-manual is the place to find all ratified extensions.  I think riscv-opcodes primary function is to prevent opcode encoding and mnemonic conflicts, so it doesn't drive anything, it just receives stuff from elsewhere.  One of the documented steps for getting a proposed extension ratified is to submit it for an Opcode and Consistency check, and this can result in encoding and mnemonic changes.  This review happens in the Architecture Review subgroup, which I think used to be called the Opcode Consistency subgroup.

I don't follow riscv-opcodes or the architecture review group, so I might not have gotten everything right.

Jim