Can you give an example of such instructions? I'm unaware of such a thing. I've written some, but not much, Thumb assembly and I never padded with nops to increase alignment.
Only if you don't have dynamic register allocation. And it's somewhat less trivial when you consider relocations and multiple sections.
Even for simple cases on LLVM, you still need to
- Convert Rust's register constraints in LLVM register constraints.
- Somehow communicate, from LLVM to Rust, which registers were allocated.
1 Like
I'm somewhat surprised by the claims that a system's programming language requires inline asm support, when neither C nor C++ support inline asm in the standard. Currently, rust doesn't have a standard and whatever is stabilized is effectively standardized due to the stability RFC. If inline asm were proposed as part of a new extension mechanism that is optional, that would at least be a direct comparison with C/C++. The most accurate phrasing of what people want when they make this claim seems to be that systems programming languages support implementation specific extensions and rust seemingly doesn't, at least not on stable and that's what they want. Cause the argument that a systems programming language requires inline asm effectively has no support, given the current standards.
3 Likes
I both strongly agree and strongly disagree. 
In this case, the biggest relevant difference is that Rust has a very strong policy of keeping stable and unstable features clearly separate so that nothing ever becomes "de facto stable." In contrast, C++ had multiple competing implementations for years before there even was a standard, so for a long time "de facto standard" was the only kind of standard there was. In practice, a Rust nightly-only feature feels like a much lower status than a "de facto standard" C++ feature; it's probably reasonable to say the former can break at any time but the latter really can't (if only because a major C++ compiler dropping something like inline asm would be utterly suicidal).
But as usual, we can make our comparisons apples-to-apples simply by being a lot more specific:
- Do the most heavily used, battle-tested, well-maintained implementation(s) of the language with a strong support system and backwards compatibility guarantees provide inline assembly? For C++, yes. For Rust, no.
- Does the formal specification of the abstract machine that defines the language provide an inline assembly feature, optional or otherwise? For C++, no. For Rust, no (and not just because Rust has no formal spec).
When people say things like "inline asm is a foundational feature of a systems language", I assume they're after something closer to the first bullet point. In particular, I think the kind of claim they're really getting at is that:
Rust should be an ideal language for implementing operating systems, device drivers, and other kinds of software that cannot be written without inline assembly. But because stable Rust lacks inline assembly those entire application domains are closed off to it. That is a serious problem, and addressing it should be one of our highest priorities.
And this claim still seems plausible to me, even after reading the >100 posts in this thread. Of course, I am putting words in other peoples' mouths right now, which is always a bit risky, but hopefully this helps break down the communication impasse I'm sensing here.
15 Likes
This is incorrect. ISO C++ specifies an asm(...); statement, with implementation-defined semantics for the tokens inside. The ISO committee hasn't specified the assembly itself, but it is recognized as an important feature of the language. Inline assembly isn't required, per se, but parsers are required to acknowledge it. See C++17S10.4.
My personal metric is, "the only .S file I should need to write is the code that my bootloader jumps to, which immediately calls into a Rust function." The stability guarantees you quote are, I think, a corollary of that.
4 Likes
That depends on how you define "dropping". Visual C++ still supports inline assembly for 32-bit x86 but they omitted it when they added support for targeting 64-bit x86 and ARM.
3 Likes
Sure, I don't think inline machine code blobs should ever try to support dynamic register allocation. Relocations would be a possible extension but might require some changes to LLVM if you couldn't deconstruct them back into matching asm.
Even if you require static (given by the programmer) register allocation within the inline asm, you need to ensure inputs to the asm are placed in the right registers (where the inline asm expects them) and outputs are read from the right registers (where the inline asm places them). This is a possibly quite significant and invasive change to the register allocator if it wasn't designed to support that from the start. LLVM can do that, of course, but my point is that removing "dynamic" register allocation doesn't make the register allocator integration issue go away.
1 Like
OK, given that there are now 129 posts (now 130 with this post), and a lot of good points brought up, would it be worth starting a working group on this topic? If nothing else, the group could maintain a summary of the problems, issues, and proposed solutions, which will help ensure that we don't lose track of anything here.
4 Likes
Maybe a bit of a left field suggestion, but the only inline assembly I could imagine stabilizing is assembly instructions for web assembly. Whether that would be useful to people is another question, but I thought I'd throw it out there. To me it seems more long term than using LLVM instructions.
(And remember web assembly is a MVP, so there will be more instructions over time supported)
@comex, @mcy, @Tom-Phinney, @JeanMertz, would any/all of you have time to take the lead on a new working group regarding stabilizing asm!()? I can get the WG set up via the process at https://rust-lang.github.io/compiler-team/procedures/form-new-working-group/, but I don't have the time or expertise to lead such a group, so someone else needs to lead it.
If anyone else has time/bandwidth to lead such a group, please feel free to jump in! Those four happened to like my post about starting a working group, which is why I'm trying to pull them in,
1 Like
cc @Amanieu, who previously expressed interest in driving that.
I'd be interested in participating as well.
1 Like
I'd probably be interested in participating as a "I write a lot of inline assembly in C" person; my current day-job is probably relevant (I do embedded). Unfortunately, I don't have the bandwidth to commit to anything more than that right now. =(
Sure, I'd be happy to lead an inline assembly working group. I actually have most of an RFC prepared, so we have something to start with.
@nikomatsakis What is the process for creating a new lang WG?
10 Likes
Let's have you attend the language team meeting on December 5th, and we can officially delegate the group at that point.
4 Likes
I will help such a group if I can.
I'm fine with Rust taking exactly this approach with inline asm. That would allow cranelift to not support it and allow rustc/llvm to support it on x86_64, among others.
I just posted a new pre-RFC draft here: [Pre-RFC #2]: Inline assembly
Feedback and suggestions are very welcome.
9 Likes
@Amanieu it sounds like you're planning on setting up the WG, correct? I just want to make sure that just one of us is bugging @nikomatsakis about this, instead of both of us. 
2 Likes