mirror of
https://github.com/rust-lang/rust.git
synced 2025-10-02 18:27:37 +00:00
14fc81b85f
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.