[steveklabnik]

Inline assembly landed in Rust 0.6, April 2013, so if you haven't checked it out since then, there's a _lot_ of new/different stuff :)

We've been discussing stabilizing these kinds of low-level features: no_std is first up. We're not 100% sure inline asm is worth it, as you can always link directly to something that's just written in assembly, but we'll see.

[daeken]

I guess my mental estimate of last having looked "about 6 months ago" was off by a little bit. I think this weekend might be dedicated to writing a Rust kernel. Thanks for your hard work!

[steveklabnik]

No problem. Like I said, we're very interested in making this use-case better, so please file any odd things that crop up. Oh, and there's #rust-osdev on mozilla's IRC where friendly people idle.

[mattst88]

I suspect that the overwhelming majority of cases that warrant inline assembly would not benefit if it was instead a function call out to something you've linked in. That is, most inline assembly is a small snippet of optimized code that necessarily exists in the function you're optimizing.

[steveklabnik]

Yeah, as always, when we're considering stabilizing or removing something, we talk to who is using the feature and in what way, and these kinds of issues surface.

[pjmlp]

That is why naked and inline exist for.

[daeken]

Inline from C libraries won't -- as far as I'm aware -- inline into a Rust function. Inline is a compile-time hint, not a link-time behavior. In theory this could be changed in LLVM, but it seems really unlikely to me. The function exposed from C (with the inline asm) can be naked, though, assuming you are hygienic.

[pjmlp]

Yeah, but that is a consequence of not having a Rust aware linker and relying on one that basically uses C semantics.

Languages that use their own linkers tend to have better opportunities for code optimization during linking.