Tracking Issue for inline assembly (asm!)

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

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.

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.

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.

fix bugs involving move closures exposed by latest nightly, asm --> l…

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.

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.

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.).

@amluto

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.

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.

Auto merge of rust-lang#91728 - Amanieu:stable_asm, r=joshtriplett

Merge #127

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?

I created separate tracking issues for each sub-feature:

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

Rollup merge of rust-lang#93337 - Amanieu:asm_tracking, r=tmiasko

Merge RoaringBitmap#127

@nagisa

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 ?

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.

Navigation Menu

Repository navigation

Tracking Issue for inline assembly (`asm!`) #72016

Stabilization

Steps

Implementation history

245 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking Issue for inline assembly (asm!) #72016

Description

Stabilization

Steps

Implementation history

Activity

joshtriplett commented on May 25, 2020

BartMassey commented on May 25, 2020

joshtriplett commented on May 26, 2020

petrochenkov commented on Jun 8, 2020

programmerjake commented on Jun 9, 2020

newpavlov commented on Jun 9, 2020

joshtriplett commented on Jun 9, 2020

amluto commented on Jun 9, 2020

245 remaining items

bstrie commented on Jan 25, 2022

Amanieu commented on Jan 26, 2022

mert-kurttutan commented on Nov 1, 2023

nagisa commented on Nov 1, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Tracking Issue for inline assembly (`asm!`) #72016