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)
std::detect - Rust's standard library run-time CPU feature detection
The private std::detect module implements run-time feature detection in Rust's
standard library. This allows detecting whether the CPU the binary runs on
supports certain features, like SIMD instructions.
Usage
std::detect APIs are available as part of libstd. Prefer using it via the
standard library than through this crate. Unstable features of std::detect are
available on nightly Rust behind various feature-gates.
If you need run-time feature detection in #[no_std] environments, Rust core
library cannot help you. By design, Rust core is platform independent, but
performing run-time feature detection requires a certain level of cooperation
from the platform.
You can then manually include std_detect as a dependency to get similar
run-time feature detection support than the one offered by Rust's standard
library. We intend to make std_detect more flexible and configurable in this
regard to better serve the needs of #[no_std] targets.
Features
-
std_detect_dlsym_getauxval(enabled by default, requireslibc): Enable to uselibc::dlsymto query whethergetauxvalis linked into the binary. When this is not the case, this feature allows other fallback methods to perform run-time feature detection. When this feature is disabled,std_detectassumes thatgetauxvalis linked to the binary. If that is not the case the behavior is undefined.Note: This feature is ignored on
*-linux-gnu*and*-android*targets because we can safely assumegetauxvalis linked to the binary.*-linux-gnu*targets (since Rust 1.64) have glibc requirements higher than glibc 2.16 that addedgetauxval.*-android*targets (since Rust 1.68) have the minimum supported API level higher than Android 4.3 (API level 18) that addedgetauxval.
-
std_detect_file_io(enabled by default, requiresstd): Enable to perform run-time feature detection using file APIs (e.g./proc/cpuinfo, etc.) if other more performant methods fail. This feature requireslibstdas a dependency, preventing the crate from working on applications in whichstdis not available.
Platform support
-
All
x86/x86_64targets are supported on all platforms by querying thecpuidinstruction directly for the features supported by the hardware and the operating system.std_detectassumes that the binary is an user-space application. If you need raw support for queryingcpuid, consider using thecupidcrate. -
Linux/Android:
arm{32, 64},mips{32,64}{,el},powerpc{32,64}{,le},riscv{32,64},loongarch64,s390x:std_detectsupports these on Linux by querying ELF auxiliary vectors (usinggetauxvalwhen available), and if that fails, by querying/proc/cpuinfo.arm64: partial support for doing run-time feature detection by directly queryingmrsis implemented for Linux >= 4.11, but not enabled by default.
-
FreeBSD:
arm32,powerpc64:std_detectsupports these on FreeBSD by querying ELF auxiliary vectors usingsysctl.arm64: run-time feature detection is implemented by directly queryingmrs.
-
OpenBSD:
arm64: run-time feature detection is implemented by queryingsysctl.
-
Windows:
arm64: run-time feature detection is implemented by queryingIsProcessorFeaturePresent.
License
This project is licensed under either of
- Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
at your option.
Contribution
Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in std_detect by you, as defined in the Apache-2.0 license,
shall be dual licensed as above, without any additional terms or conditions.