Tracking Issue for inline assembly (asm!)

[Amanieu]

This is a tracking issue for the RFC 2873 (rust-lang/rfcs#2873).
The feature gate for the issue is #![feature(asm)].

Stabilization

• Blockers: Tracking Issue for inline assembly (asm!) #72016 (comment)
• Blockers: Tracking Issue for inline assembly (asm!) #72016 (comment)
• Stabilization report: Tracking Issue for inline assembly (asm!) #72016 (comment)

Steps

• Implement the RFC (Implement new asm! syntax from RFC 2850 #69171)
• LLVM version check (Implement new asm! syntax from RFC 2850 #69171 (comment), min-LLVM: Can only use x86 asm ATT syntax for LLVM < 10 in new asm! #76738)
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

Implementation history

• Implement new asm! syntax from RFC 2850 #69171 Initial implementation

---

January status update

---

April status update

---

July status update

---

November stabilization report for FCP
November FCP checklist

[joshtriplett]

Note: if you'd like to report an issue in inline assembly, please report it as a separate github issue, and just link to this one. Please don't report issues in inline assembly as comments on this tracking issue.

[BartMassey]

Should the asm! macro be available directly from the prelude as it is now, or should it have to be imported from std::arch::$ARCH::asm? The advantage of the latter is that it would make it explicit that the asm! macro is target-specific, but it would make cross-platform code slightly longer to write.

Definitely want the explicit import. This would also make it a bit clearer what's going on when somebody tries to compile an old-style asm! with a newer compiler, which is going to happen a lot: you'd get an unresolved symbol rather than mysterious syntax errors.

[joshtriplett]

On Mon, May 25, 2020 at 03:56:53PM -0700, Bart Massey wrote: Definitely want the explicit import. This would also make it a bit clearer what's going on when somebody tries to compile an old-style `asm!` with a newer compiler, which is going to happen a lot: you'd get an unresolved symbol rather than mysterious syntax errors.

Rust will actually catch many instances of this. Any use of the old `asm!` syntax that has any operands at all will get caught in the parser (because it uses a ':'), and result in a very clear error telling the user about the syntax transition, and a hint suggesting `llvm_asm!`. (At some point that hint should also start suggesting the use of the new syntax.) The only case that wouldn't be caught in the parser would be if you have an `asm!` that has no inputs, no outputs, no clobbers, and no options, so it just looks like `asm!("...");`. In that case, on x86, it'll give you an assembly syntax error from the backend if you used AT&T syntax. We might, theoretically, be able to do a little better than *that*, as well; looking into that.

[petrochenkov]

Minor compatibility concern: asm! supports some LLVM-isms like C style comments /* comment */ (#73056 (comment)).

Other backends using external assemblers may need to do some pre-processing before passing the asm text to them.

[programmerjake]

Minor compatibility concern: asm! supports some LLVM-isms like C style comments /* comment */ (#73056 (comment)).

GNU Assembler (IIRC defined as the official assembly dialect by the RFC), and by extension GCC, supports C-style comments too, so they are definitely not LLVM-specific.

[newpavlov]

Namespacing the asm! macro

I am also in favor of explicit imports from arch modules. I would suggest going even further and introduce separate macros for each supported target (e.g. asm_x86!, asm_arm!, etc.).

[joshtriplett]

Some feedback from various places in response to the blog post. (I'm skipping general expressions of awesomeness, though there have been many; I'm quoting those that have specific feedback.)

@amluto (Andy Lutomirski, prominent Linux kernel developer who works on a lot of low-level x86) at https://news.ycombinator.com/item?id=23467108 :

Rust folks, thank you so much for making this far, far better than GCC’s asm syntax for C. Also, thank you for using Intel x86 syntax instead of AT&T.
It would be delightful if GCC were to adopt something similar after this stabilizes in Rust.

Several people on HN were a little confused about the backward-compatibility story here; in the future, when we talk about features that have only existed on nightly, we need to be more clear in the future about messaging around our stability policy.

Several people wondered why this used a string constant; it'd be good to explain that in documentation. And this doesn't mean the assembly isn't parsed, it means it isn't parsed by rustc (it's parsed by LLVM in the backend).

We really should have mentioned, in the blog post, that AT&T syntax was supported with options(att_syntax), so that people didn't think they have to translate all their assembly. I've prepared an update to the blog post mentioning that.

Someone mentioned preferring an "explicit clobber" syntax (like clobber("ax")) rather than having to write out("ax") _. I can understand that.

Closely related, I think we should definitely have both "clobber all function-clobbered registers" and "clobber all general-purpose registers" options.

[amluto]

I’ll add one more comment: please document what happens if you try to use not-quite-general-purpose registers as operands (clobber or otherwise). The most important case is the PIC register. GCC does not appreciate inline asm that clobbers the PIC register. IMO it should be allowed, especially for things like CPUID on x86_32.

This also includes thinks like EBP/RBP. If I’m building with frame pointers on or I do something that forces a frame pointer, is RBP available? RSP is another example — presumably it’s not available.

[Amanieu]

Several people wondered why this used a string constant; it'd be good to explain that in documentation. And this doesn't mean the assembly isn't parsed, it means it isn't parsed by rustc (it's parsed by LLVM in the backend).

Actually what I feel a lot of people are really asking is: "Why isn't this just like MSVC's __asm or D's inline assembly where I can just write the asm directly and the compiler will figure out the input/output/clobbers automagically?"

The issue with that approach is that in a lot of cases, we can't actually figure out the constraints just from the assembly code. Common examples are call and syscall instructions which can have an arbitrary ABI.

Finally, if you really want it, you can parse the asm code in a proc macro and derive the necessary input/output/clobber operations from it. In fact, this is what Clang does to support the MS __asm: it parses the ASM in the front-end (with some support from LLVM's MC layer) and rewrites the asm to use standard LLVM constraint codes.

I’ll add one more comment: please document what happens if you try to use not-quite-general-purpose registers as operands (clobber or otherwise). The most important case is the PIC register. GCC does not appreciate inline asm that clobbers the PIC register. IMO it should be allowed, especially for things like CPUID on x86_32.

This is actually quite tricky and I believe it is a bug for the back-end (GCC/LLVM) to silently accept the use of these registers and then generate wrong code (for example by not preserving the PIC base around the asm). This should be fixed in the back-end or at the very least cause a compile-time error.

We currently always disallow the use of the stack pointer and frame pointer as operands for inline asm in the front-end. However the exact set of reserved registers depends not only on the current target but can also be different depending on the properties of the function:

• The frame pointer (EBP) is only reserved if the function needs a frame pointer (e.g. dynamic alloca).
• If the function requires stack realignment then a "base pointer" is also reserved (EBP on x86).

These properties can vary depending on the optimization level and inlining so there is no way we can selectively enforce this in the front-end. A blanket ban on the use of registers that may be reserved is also a non-starter since these registers are commonly used (e.g. for syscall arguments).

[joshtriplett]

One more issue I've observed in several contexts: everyone formats asm! statements differently, and we should 1) come up with guidance on how to do so, and 2) implement that guidance in rustfmt.

Notably, this includes how to format both single-line and multi-line assembly statements.

EDIT: originally, in this comment, I proposed an initial set of requirements. To keep format bikeshedding out of this tracking issue, I've moved that to an issue on the fmt-rfcs repo.

[unageek]

I'm trying to implement an optimization barrier like black_box for a f64 value with asm!.

The following code is working so far. However, it seems that it's relying on an undocumented behavior of the compiler. Is there any legit way to avoid the "argument never used" error?

#[inline]
fn secure(mut x: f64) -> f64 {
    unsafe {
        // Won't compile without `# {0}` due to an "argument never used" error.
        asm!("# {0}", inout(xmm_reg) x, options(nomem, nostack));
    }
    x
}

rustc --version --verbose:

rustc 1.46.0-nightly (feb3536eb 2020-06-09)
binary: rustc
commit-hash: feb3536eba10c2e4585d066629598f03d5ddc7c6
commit-date: 2020-06-09
host: x86_64-unknown-linux-gnu
release: 1.46.0-nightly

Full example code (should be built with --release)

#![feature(asm)]

use core::arch::x86_64::*;

#[inline]
fn secure(mut x: f64) -> f64 {
    unsafe {
        asm!("# {0}", inout(xmm_reg) x, options(nomem, nostack));
    }
    x
}

#[inline]
fn mul(x: f64, y: f64) -> f64 {
    secure(secure(x) * secure(y))
}

fn main() {
    unsafe {
        _MM_SET_ROUNDING_MODE(_MM_ROUND_UP);
    }

    assert_ne!(-mul(-1.1, 10.1), mul(1.1, 10.1));

    unsafe {
        _MM_SET_ROUNDING_MODE(_MM_ROUND_NEAREST);
    }
}

[bjorn3]

_MM_SET_ROUNDING_MODE(_MM_ROUND_UP);

I don't think a blackbox is enough for LLVM to always use the rounding mode you want. I think LLVM is allowed to reset the rounding mode at any point in your code. I think your code is only guaranteed to work fine when you pass the -fp-model=strict LLVM argument, in which case the blackbox is not necessary anyway.

https://reviews.llvm.org/D62731

precise
By default, the compiler uses /fp:precise behavior.
[...]
The compiler generates code intended to run in the default floating-point environment and assumes that the floating-point environment is not accessed or modified at runtime. That is, it assumes that the code does not unmask floating-point exceptions, read or write floating-point status registers, or change rounding modes.
[...]
strict
[...]
Under /fp:strict, the compiler generates code that allows the program to safely unmask floating-point exceptions, read or write floating-point status registers, or change rounding modes.

[Amanieu]

See #72965 and #73056 for the issue with unused arguments.

[unageek]

I don't think a blackbox is enough for LLVM to always use the rounding mode you want. I think LLVM is allowed to reset the rounding mode at any point in your code. I think your code is only guaranteed to work fine when you pass the -fp-model=strict LLVM argument, in which case the blackbox is not necessary anyway.

Thank you for your reply. -fp-model (or any equivalent option) does not seem to be implemented in rustc yet. Is there a tracking issue for that? (Sorry for being off-topic.)

See #72965 and #73056 for the issue with unused arguments.

Thank you for letting me know about them!

[joshtriplett]

Another comment that seems relevant to capture:

For ARM, can we have the "." separators? They are standard for Aarch64 anyway, and they make the 32-bit code far easier to read. Like so:

add.s.ne
ldm.ia.cc

(in both orders, for those cases with two suffixes)

Are these supported by LLVM?

[bjorn3]

Thank you for your reply. -fp-model (or any equivalent option) does not seem to be implemented in rustc yet. Is there a tracking issue for that? (Sorry for being off-topic.)

I thought -fp-model was an LLVM option. I just read the actual diff of patch I linked, and it turn out to be a clang option that causes it to emit LLVM float instructions with certain flags.

[Amanieu]

For ARM, can we have the "." separators? They are standard for Aarch64 anyway, and they make the 32-bit code far easier to read.

Those aren't separators, they are part of the instruction name on AArch64. They do not exist on 32-bit ARM.

[thomcc]

Given the caveats around labels with intel syntax (labels should be numeric, but can't be 0, 1, or a number made up of only those digits), is it worth getting an issue on file to at least improve the error messages? Is there one already?

[Amanieu]

We have a NamedAsmLabels lint which warns about using name labels, we could extend that to also warn about label names that look like binary numbers (only on x86 and with intel syntax).

[bstrie]

I see that there are some new feature flags in nightly for tracking the long tail of asm! stabilization: asm_const, asm_experimental_arch, asm_sym, and asm_unwind. Should we make dedicated tracking issues for these?

[Amanieu]

I created separate tracking issues for each sub-feature:

• Tracking Issue for asm_const #93332
• Tracking Issue for asm_sym #93333
• Tracking Issue for asm_unwind #93334
• Tracking Issue for asm_experimental_arch #93335

This tracking issue can be closed now that asm! is stable.

[mert-kurttutan]

Hi @nagisa ,
I am still experiencing the same issue that @marysaka mentioned (in 1.73 stable and nightly) on x86 hardware, here .
I am trying out a Rust port of some C code. The C code uses inline assembly with memory inputs which has the syntax [x] "m" (x) where x is a variable defined in the current scope, and it is able to use variables from stack memory (instead of registers).
So, it is able to use less number of registers by loading multiple variables (from stack) to the same register in different parts of the code.

In the reference for inline assembly for Rust, only input operand type is that of register operand. Do we have similar method use variable as input from memory rather than register ?

[nagisa]

Next time please open a new issue, or even better, ask on Zulip, rather than commenting on one that has been closed for more than a year at this point.

---

As far as I know, no, memory operands are considered a future possibility by the RFC that implemented inline assembly and would require some design & implementation work.

Your next best bet is to pass in an address to the variable in a register.