no_std support

[lu-zero]

Would be in-scope making graviola no_std+alloc?

[ctz]

Hi! Yes, for sure.

At the moment this is difficult because I'm using the dynamic CPU feature detection in std -- eg https://doc.rust-lang.org/std/arch/macro.is_aarch64_feature_detected.html -- while avoiding that is easy on x86, I think the story on ARM is less clear.

[lu-zero]

Adding a feature to disable it and assume the target supports everything and/or receive the features from the caller might be sufficient?

Probably later in the development though :)

[ctz]

Adding a feature to disable it and assume the target supports everything and/or receive the features from the caller might be sufficient?

Yes. Even simpler would be to require anyone using that feature specifies the features statically at compile time (using target-cpu=native or whatever). Which is probably more reasonable for a typical no-std user?

[lu-zero]

Having a way to override probably would make their life simpler.
But as it is now the plausible target would be a tiny os for arm and that's it.

In the future a beefy quasi-embedded risc-v that may or may not have RVV enabled might enjoy having a mean to pass the information since it usually comes from the device tree or the bootloader.

(I opened the issue because rustyguard has a WIP patchset that tries to use graviola directly and I got curious)

[stevefan1999-personal]

@ctz check this out https://github.com/calebzulawski/multiversion

There is one cargo feature, std, enabled by default. When enabled, multiversion will use CPU feature detection at runtime to dispatch the appropriate function. Disabling this feature will only allow compile-time function dispatch using #[cfg(target_feature)] and can be used in #[no_std] crates.