RISC-V: Tidying of features / extensions #1752
Merged
+87
−79
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
All RISC-V Features are reordered for better maintainability.
The author has a plan to add many RISC-V ratified extensions (mainly
discoverable from Linux) and this is a part of preparation.
Sections are divided as follows:
* Base ISAs
* "I"-related
* Extensions formerly a part of the base "I" extension
but divided later (now all of them are ratified).
* Other user-mode extensions "Zi*".
* "M"-related (currently "M" only)
* "A"-related
"A", "Za*" and "Ztso" which is named differently but absolutely
related to memory operations.
* Base FP extensions
* Base FP extensions using integer registers
* "C"-related (currently "C" only)
* "B"-related (except cryptography-related "Zbk*")
* Scalar cryptography extensions (including "Zbk*")
* Base Vector extensions (currently "V" only)
* Ratified privileged extensions
* Non-extensions and non-ratified extensions which is *not*
going to be ratified, at least in the draft form
The last section needs some explanation.
"S" is not an extension (although some buggy implementations such as QEMU
up to 7.0 emitted this character as well as "U" as an extension) and the
DeviceTree parser in the Linux kernel explicitly workarounds this issue.
There's no plan for ratification of the single-letter "J" extension
(there's a room for redefinition like the "B" extension but unlikely).
Instead, pointer masking extensions including "Supm" is one of the results
of the task group discussing J extension*s*.
There's also an instruction in the "Zfa" extension which accelerates
FP-to-int conversion matching JavaScript semantics.
"P" is being actively discussed (and will result in a single-letter "P"
extension and various "Zp*" extensions) but it seems there needs some time
until ratification.
And there's one Rust-specific issue: Rust implements Packed-SIMD intrinsics
based on an early draft of the "P" extension and they are *very unlikely*
kept as-is. For instance, `add16` does not follow standard RISC-V
instruction naming (ADD16 is the name from the Andes' proposal) and
going to be renamed.
Before moving "P" to above, we have to clearly understand what the final
"P" extension will be and resolve existing intrinsics.
As the version 20240411 of the RISC-V ISA Manual changed wording to
describe many of the standard extensions, this commit largely follows this
scheme in general. In many cases, words "Standard Extension" are replaced
with "Extension" following the latest ratified ISA Manual.
Some RISC-V extensions had tentative summary but it also fixes that
(e.g. "Zihintpause").
Following extensions are described in parity with corresponding extensions
using floating-point registers:
* "Zfinx" Extension for Single-Precision Floating-Point in Integer Registers
* "Zdinx" Extension for Double-Precision Floating-Point in Integer Registers
* "Zhinx" Extension for Half-Precision Floating-Point in Integer Registers
* "Zhinxmin" Extension for Minimal Half-Precision Floating-Point in Integer Registers
Following extensions are named against the ISA Manual naming but
considered inconsistency inside the ISA manual:
* "Zfhmin" Extension for Minimal Half-Precision Floating-Point
ISA Manual: "Zfhmin" Standard Extension for Minimal Half-Precision Floating-Point
* "V" Extension for Vector Operations
ISA Manual: "V" Standard Extension for Vector Operations
Following extension is removed from the latest ratified ISA Manual but
named like others:
* "Zam" Extension for Misaligned Atomics
"Zb*" extensions are described like "Extension for ..." using partial
summary per extension (including cryptography-related "Zbk*" extensions).
"Zk*" extensions are described like "Cryptography Extension for ..." using
partial summary per extension (e.g. 'Zkne - NIST Suite: AES Encryption' in
the ISA Manual to '"Zkne" Cryptography Extension for NIST Suite: AES
Encryption') except following extensions:
* "Zkr" Entropy Source Extension
Following the general rule will make the description redundant.
* "Zk" Cryptography Extension for Standard scalar cryptography
The last word "extension" is removed as seemed redundant.
Link:
<https://lf-riscv.atlassian.net/wiki/spaces/HOME/pages/16154769/RISC-V+Technical+Specifications>
(ISA Specifications, Version 20240411; published in May 2024)
Although the "B" extension is redefined and ratified, keeping this in the
documentation as-is have two issues:
* "B" extension is not added to `riscv.rs` yet (to be added later).
* "B" extension is ratified as a combination of "Zba", "Zbb" and "Zbs"
extensions and "Zbc" is *not* a part of "B" itself (despite that
it is listed under "B"), which makes the documentation misleading.
This commit tentatively removes the reference to the "B" extension and
replaced with "Bit Manipulation Extensions" without an extension name.
a4lg
force-pushed
the
riscv-tidy-features
branch
from
54106d3 to
dcf4f02
Compare
|
LGTM since this has no functional change. I look forward to the future work on improving the RISC-V features. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I have a plan to add many ratified RISC-V extensions (mainly discoverable from Linux through the newer interface) and this is a part of preparation.
Generally, this PR is based on the latest ratified ISA Specification Manuals (version 20240411).
In this PR, I avoided:
is_riscv_feature_detected(although small change is made)because it is going to be a part of later changes with actual feature addition
and extracted portions I consider many of you will agree.
There's some backgrounds behind some changes and I described them in the commit message.