I would generally expect an asm! call to be extremely platform specific; would it make sense to restrict the usage of the asm! macro to functions which are platform specific, for example, so that it is made clear that this piece of code is only valid for x86/x86_64 and cannot be compiled to ARM?
The language already has the tools to do that (e.g. conditional compilation
#[cfg(target_arch = "powerpc64")]). The toolchain also detects many errors (e.g. embedding ARM inline assembly into an
x86 binary fails to compile) but these errors are reported late (during LLVM translation, while invoking the assembler, etc.).
The language “run-time” will be able to give you more precise information about which assembly instructions you can actually execute. For example, the
coresimd library already provides run-time feature detection on
core::, so you can use that to detect AVX2 support at run-time and execute some assembly instructions only if the host supports them.
What rustc doesn’t have is a way to verify that some assembly code is going to compile successfully. For example, that you generate
x86 assembly only in a part of the code that is protected by a
#[cfg(any(target_arch = "x86", target_arch = "x86_64"))] macro. What rustc also doesn’t have is a way to verify that some assembly code is safe.
There has been some progress towards eliminating common uses of unsafe with respect to using intrinsics, e.g., see RFC 2122, but extending the approach being pursued there to inline assembly would be a very long shot.
I agree that the issue you raise is a problem. But I don’t think it is a problem worth solving “right now”. Solving it requires a lot of work (rustc uses LLVM for inline assembly, so we would at least need to teach it to use the appropriate assembler to verify inline assembly “early”). Also, in all cases I can think of, if you screw up the code won’t compile. That’s bad, but it’s not horrible, in particular given that the
asm! macro will be
unsafe and that everyone should be assuming that any code that uses the
asm! macro is not portable.
We could always solve this later in a backwards compatible way by adding a checker for inline assembly code. This checker could warn on portability issues (e.g.
asm! macro invocations not protected by a
cfg(target_arch)) and produce errors on broken assembly (if the code was already broken it is not backwards incompatible to error on it).