Closed A0lson closed 1 year ago
Hi,
The reason for this limitations is this safety comment.
e.g., there are some ancient x86 architectures which do not support a cpuid instruction and so the program using this library would crash. The cpuid_count
function in the library was made safe by requiring the SSE feature. In this case, we know the target cpu is recent enough that cpuid exists and therefore won't crash the program.
But you're right that this doesn't per-se have anything to do with SSE, it's more of a hack that will exclude some architectures because we lack proper "is cpuid available" detection at compile-time. To be precise: Any chip produced after 1993 has cpuid, but SSE was introduced in 1999. So (Intel) chips created between '93 and '99 technically have a cpuid instruction but can't use this library.
For bare-metal use without SSE features: You should be able to compile the library and use CpuId with a custom reader function, that just passes a cpuid function to it. e.g., you can pass in your own, safe wrapper around __cpuid_count.
If not, let me know as this should be fixed.
@A0lson does my reply answer your question? Did you figure out how to pass a custom cpuid reader to the CpuId struct?
Thanks for answering this, your reply makes sense.
I was attempting to use this crate on an x86 target (intended for bare-metal code w/o XMM/SSE register usage).
However, it seems this crate depends on the Rust target having
sse
support. However, just because a processor hardware implements SSE instructions, it seems like the CpuId functionality in this crate should still be available even if the code is being compiled without SSE instruction usage.Or is there something I'm missing?