[Pre-RFC]: Inline assembly

[mark-i-m]

Perhaps we could just use the variable name as the named argument:

interrupted = out (reg),
interrupt_flag = in (mem),

[Amanieu]

This is actually trickier than it seems since the value attached to a register can an expression (e.g. arg0 as u64) and is not necessarily just an identifier.

[cuviper]

It could take a queue from struct construction, where you can write either Foo { bar: some_expr }, or just Foo { bar } if there’s a bar in scope.

[HadrienG]

At the risk of starting the dreaded bikeshed discussion, I feel like this kind of elision would be easier to introduce in a syntax where the asm binding name comes after the in()/out() specifier, such as the one which @rkruppe hinted at previously:

in(reg) ptr=slice.as_ptr(),
in(reg) len=slice.len(),

In this case, if there is already a “ptr” and a “len” in scope, one would just reword it as:

in(reg) ptr,
in(reg) len,

The main limitation is that this introduces a parsing ambiguity if both expressions (for anonymous arguments) and bindings (for named arguments) are allowed. As far as I can see, such a syntax would only be viable if naming arguments becomes mandatory (which, as @mark-i-m pointed out earlier, can be an unnecessary annoyance for small snippets).

[Amanieu]

I think that this isn’t a huge issue and that we should just try to stick close to the existing format string syntax.

[HadrienG]

I generally agree, was just wondering if there was an easy way to sugar out this kind of repetition. But there does not seem to be one, and this minor issue is not worth going for the hard way

[NoamB]

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?

I have a proposal for this problem:

• Force crates to specify supported architectures in their Cargo.toml (default is ‘all’). The list is passed to the compiler.
• Asm statements are given the architecture as a parameter (or perhaps have an asm_<arch> macro per architecture).
• Asm statements can be placed in 2 locations:
  • An arch_match! procedural macro
  • A function marked with a special per-architecture attribute (#[architecture(<arch>)])
    • These functions can call eachother, like unsafe functions can

arch-match

A macro that opens an architecture specific scope, per architecture. must be exhaustive across all crate-supported architectures.

Example usage:

arch_match! {
    x86 => asm_x86!(...),
    armv7 => asm_armv7(...),
    all => unoptimized_rust_function(),
}

If for some reason, some asm statement is only relevant for a single architecture, one can just match on it and ‘all’, and do nothing in ‘all’:

arch_match! {
    x86 => asm_x86!("important_instruction"),
    all => { },
}

Asm subtyping

I don’t know exactly how this should work, but for example, newer amd64 cpus subtype older amd64 cpus. Everything subtypes ‘all’. Maybe it should be more trait-like? (specify amd64 + sse2 as the architecture)

The ‘all’ architecture

Only rust code can run in this context.

[rpjohnst]

You may be interested in the portability lint RFC, which already handles that sort of problem via the existing #[cfg] attribute.

[matthieum]

I am not sure the arch_match is the best idea, because of the subtyping that you mention.

It’s pretty normal to write a different assembly version for x86 depending on the presence of sse2, sse4, avx, avx512.

Since we already have a way for a function to be specialized per architecture (cfg) and for a function to enable CPU features (feature(enable = "sse4")?), maybe it would be possible to simply decline the macros on a per-architecture basis and then place a assert_cfg!(x86) inside the asm_x86 macro for example.

A crude way would be to declare an empty function only on x86 via cfg, then reference that function in the asm_x86 macro, causing a compile-time failure if the macro is invoked on a non x86 platform.

[sfackler]

The target feature RFC covers those use case: https://github.com/rust-lang/rfcs/blob/master/text/2045-target-feature.md.

[mark-i-m]

Personally, I feel like this would be really complicated to implement well and would involve a lot of arch-specific knowledge in the compiler. The current approach of using a function with #[cfg(...)] seems both more idiomatic and easier to implement.

[gnzlbg]

@Florob

I think it is time to submit this as an eRFC so that we can agree if this is the direction in which we want inline assembly to go without committing to all implementation details (e.g. which exact constraints we want to expose in stable Rust, etc.). It would help if the eRFC would be worded in such a way that conveys that.

Once we have agreed on the general direction (and people working on alternative Rust backends have given feedback), we can start the implementation, and some time later, submit an RFC for an MVP with a subset of all of this that could be useful for stabilization and has been made to work.

Would you be interested in submitting such an eRFC based on this pre-RFC ?

[josh]

I love this proposal, and I’d love to see it as the stable asm! syntax in Rust.

A few additional thoughts:

• Based on this syntax, it seems reasonably straightforward to build a gcc_asm! or similar that translates from GCC assembly syntax, for convenience of porting. Or tools to mechanically translate from one syntax to the other.

• I’d love to see shorthand for a {name} that matches the variable name passed in, to avoid having to write name=in(reg) name. (This assumes that the same name doesn’t get passed multiple times, and of course expressions other than identifiers would need explicit names.)

• For the same reason that this proposal made earlyclobber the default and required an explicit lateout to optimize if you know you won’t clobber early, I find myself really tempted to make volatile the default and add some explicit annotation for non-volatile assembly. On the other hand, the explicit requirement to have either outputs or volatile and making it an error to not have at least one of those would help avoid common issues.

• When naming constraints, please note that names like eax make an unwarranted assumption; for instance, GCC’s a constraint on x86 can turn into al, ax, eax, or rax, depending on the size of what you pass into it. Also note the constraint modifiers that let you (for instance) access the sub-registers of a register; those should probably become {:modifiers} or similar. These translations are both 1) why I find this proposal so awesome and 2) the largest amount of work in this proposal.

• Regarding the idea of having asm! return outputs, while that won’t work in the general case, I like the idea of writing out(reg) return for an output and having the result used as the return value of the asm!. That would significantly shorten common cases that would otherwise have to declare and return a temporary. (It would require handling types carefully, though.)

• If LLVM supports them, please support flag-output constraints as well, turning them into bool outputs (or return as above); this makes it possible to use the result directly in a conditional and have the compiler turn that into the appropriate conditional jump instruction.

Overall, I’d love to see this proposal turn into an RFC, and I’d be happy to help with it as well. I don’t think you need a complete specification of all the constraint translations as part of the RFC, just a representative sample of all the types of constraints and guidelines for adding new ones.

[glandium]

Being in the middle of determining whether more assembly blocks than the two I already found are broken in the Firefox code base, I’d like to note how much of a massive footgun input, output and clobber definitions are, when they could be derived from the assembly itself. This was not possible in the old GCC model where a C file is preprocessed, then compiled into assembly, and then translated by an assembler into machine code, but in the LLVM model, where the LLVM framework contains the assembler, this could be treated differently. It is a bummer that clang doesn’t for GCC style assembly (at least not now; at the very minimum, I wish it had a warning about misplaced inputs/outputs, and missing clobbers), but it actually does for MSVC style assembly, which doesn’t come with inputs, outputs, and clobbers. There’s a chunk of code in clang that parses the assembly, and generates inputs, outputs and clobbers from that.

You might say that people writing assembly should write their inputs, outputs and clobbers correctly, but the fact that I was able to find problems in two different third-party code bases used in Firefox, one of which is 8 years old, and that it went undetected for so long is telling. And it only causes problems when things align in a certain way. That is, those things that I found in Firefox… they just happen to have been fine so far, but enabling LTO made things go in unexpected ways. And where it’s the most interesting is that it didn’t even break consistently on all platforms because things were not aligning the same way on all platforms. So, like, the last one I’m dealing with at the moment only happened in a visible way on mac, although it could very well happen on linux, but didn’t. That’s why I’m doing a more systemic scan, now.

[josh]

I’d love to have rustc scan assembly and attempt to give warnings if the clobbers seem incomplete. I don’t think we can do that in the completely general case (consider code that saves and restores a register), but we could provide best-effort warnings for common cases.

I don’t, however, see how we could handle most cases of inputs or outputs.

[Amanieu]

The consensus on previous threads regarding inline asm has been to expose a low-level API first, on top of which other people can build high-level APIs such as ones that automatically derive constraints from the assembly text.

[glandium]

I don’t, however, see how we could handle most cases of inputs or outputs.

FWIW, the two cases I fixed in Firefox were, in large part, bad input/outputs (to be specific, variables declared as input, but modified by the assembly ; like a count decremented in a loop ; those need to be declared as output instead with a + modifier)

[josh]

Ah, I see. Yeah, those would either need to become clobbers or (earlyclobber) input-outputs.

[glandium]

a low-level API first, on top of which other people can build high-level APIs such as ones that automatically derive constraints from the assembly text.

The downside to this approach is that the high-level stuff needs to have its own assembler parser and database of instructions, which LLVM already has.

[CAD97]

It wouldn’t be breaking to add auto-clobbers later, though, would it? As anything that wouldn’t be already specifying the clobbers would be UB. So not providing them now is a conservative first step that also doesn’t require all of that work yet.