You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've submitted an RFC (rust-lang/rfcs#2725) that allows #![no_std] applications to use the target-feature detection macros, and customize the detection run-time. A
For embedded devices, you often know all features available at compile-time, so doing run-time detection is probably moot, unless you want to ship the same binary to different embedded devices, or have an heterogeneous device and want some code to use features of certain cores when available.
Either way, the RFC should cover these use cases, but thought some of you might be interesting in triple-checking that it would work for their use cases as well.
The text was updated successfully, but these errors were encountered:
For anyone looking for an interim/stopgap solution for portable CPU feature detection which is at least no_std on x86/x86-64, the RustCrypto Project's cpufeatures crate provides this:
We also support aarch64, but runtime CPU feature detection on ARM64 requires privileged instructions and thus can only be performed using operating system-provided APIs. We presently support runtime detection of a limited number of CPU features on these platforms (with runtime detection limited to Linux and macOS). If we don't support the feature you're interested in (or you're interested in e.g. 32-bit ARM) please open an issue with a request and we can get it added.
I've submitted an RFC (rust-lang/rfcs#2725) that allows
#![no_std]
applications to use the target-feature detection macros, and customize the detection run-time. AFor embedded devices, you often know all features available at compile-time, so doing run-time detection is probably moot, unless you want to ship the same binary to different embedded devices, or have an heterogeneous device and want some code to use features of certain cores when available.
Either way, the RFC should cover these use cases, but thought some of you might be interesting in triple-checking that it would work for their use cases as well.
The text was updated successfully, but these errors were encountered: