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.
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,
cc @Amanieu, who previously expressed interest in driving that.
I'd be interested in participating as well.
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?
Let's have you attend the language team meeting on December 5th, and we can officially delegate the group at that point.
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.
Yes, I'll be setting up the WG.
Good, thank you!
Just to respond to the initial premise, I think that yes, Rust needs stable inline assembly as a matter of principle. If it can't do that, then it can't call itself a systems programming language in my opinion. I regularly use Rust's unstable inline assembly to call APIs with odd calling conventions that Rust will probably never support, among other things.
I think it would be nice for the proposal to at least mention how inline asm might look for wasm. I see no reason it couldn't work (except, well, compiler backend support), so it'd be nice to show it in the future possibilities.
LLVM already supports Wasm inline assembly, so we already get it for free.
I'm trying to find documentation for that support, and in particular for what constraints LLVM supports and what they mean. I'd like to make sure we take this into account in the new inline assembly proposal.
IIRC we already use LLVM inline assembly support for WASM in libcore (e.g. in
According to this comment "m" constraints aren't supported. That's the only documentation I've found but I haven't look very hard.
That's what I found as well, and I didn't find any other documentation either.
Looks like WebAssembly only supports
"r" constraints, and uses them to represent indexes of locals.