X-Git-Url: https://git.ralfj.de/web.git/blobdiff_plain/ef26e321391b25191bcda8313fcb9d51b287f882..d86b8672f9f3c01ca59a5768f056992fcaa74602:/personal/_posts/2026-03-13-inline-asm.md?ds=sidebyside

diff --git a/personal/_posts/2026-03-13-inline-asm.md b/personal/_posts/2026-03-13-inline-asm.md
index 5e9a93b..d66d8f3 100644
--- a/personal/_posts/2026-03-13-inline-asm.md
+++ b/personal/_posts/2026-03-13-inline-asm.md
@@ -1,6 +1,7 @@
 ---
 title: "How to use storytelling to fit inline assembly into Rust"
 categories: rust
+reddit: /rust/comments/1rshm93/how_to_use_storytelling_to_fit_inline_assembly/
 ---
 
 The Rust Abstract Machine is full of [wonderful oddities]({% post_url 2020-12-14-provenance %}) that do not exist on the [actual hardware]({% post_url 2019-07-14-uninit %}).
@@ -280,8 +281,10 @@ In some cases, however, there are no obvious miscompilations.
 And indeed, if we knew exactly which universal properties of Rust programs the compiler relies on, we could allow inline asm code that satisfies all those universal properties, even if it has no story which can be expressed in Rust source code.
 Unfortunately, this approach would require us to commit to the full set of universal properties the compiler may ever use.
 If we discover a new universal property tomorrow, we cannot use it since there might be an inline asm block for which the universal property does not hold.
+
 This is why I am proposing to take the conservative approach:
-only allow inline asm blocks that are obviously compatible with all universal properties of actual Rust code, because their story can be expressed as actual Rust code!
+only allow inline asm blocks that are obviously compatible with all universal properties of actual Rust code, because their story can be expressed as actual Rust code.
+If there is an operation we want to allow that currently has no valid story, we should just [add](https://github.com/rust-lang/rfcs/pull/3700) a [new language operation](https://github.com/rust-lang/rfcs/pull/3605), which corresponds to officially blessing that operation as one the compiler will keep respecting.
 
 [^noopt]: This assumes that we do not want to sacrifice the optimizations in question. Since inline assembly could hide inside any function call, this typically becomes a language-wide tradeoff: either we forbid such inline asm blocks, or we cannot do the optimization even in pure Rust code.
 
@@ -290,6 +293,6 @@ but as the `innocent` example at the top of the post shows, we cannot leave inli
 The storytelling approach is my proposal for filling that gap.
 I plan to eventually suggest it as the official rules for inline assembly.
 But before I do that, I'd like to be more confident that this approach really can handle most real-world scenarios.
-If you have examples of assembly blocks that cannot be explained with storytelling, but that you are convinced are correct and hence should be supported, please let us know, either in the immediate discussion for this blog post or (if you are reading this later) in the [t-opsem Zulip channel](https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem).
+If you have examples of assembly blocks that cannot be explained with storytelling, but that you are convinced are correct and hence should be supported, please let us know, either in the immediate [discussion](https://www.reddit.com/r/rust/comments/1rshm93/how_to_use_storytelling_to_fit_inline_assembly/) for this blog post or (if you are reading this later) in the [t-opsem Zulip channel](https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem).
 
 #### Footnotes