A deep dive into how inline assembly (and FFI) can be formally integrated into Rust's Abstract Machine semantics using a 'storytelling' approach. The core idea: every inline assembly block must have a corresponding piece of valid Rust code that describes what it does to observable Abstract Machine state. This story code must satisfy all Rust aliasing rules (e.g., Tree Borrows), and the actual assembly must refine it. The post walks through concrete examples—bit manipulation, OS page table manipulation, mirrored memory pages, non-temporal stores, stack painting, and floating-point control registers—showing both the flexibility and limits of this model. The approach explains why some inline asm is UB (e.g., writing through a shared reference), why asm blocks act as partial compiler fences, and why certain hardware features like changing the FP rounding mode mid-program are fundamentally incompatible with Rust's optimizer. The author proposes this as a future official guideline for inline assembly semantics in Rust.
Table of contents
Why can’t inline assembly do whatever it wants?When is inline assembly compatible with optimizations?Inline assembly stories by exampleConclusionSort: