Odin's New Inline Assembly Templates

Odin has introduced a new system for inline assembly templates. These templates are callable entities that are instantiated in place at each call, similar to forced-inline procedures. They behave like intrinsics and are not statement blocks spliced into surrounding procedures. The system aims to provide a universal syntax across instruction set architectures, using a common grammar while still exposing the unique instructions and registers of each ISA.

The syntax is inspired by Plan 9-derived assemblers and the Go assembler, originating from Ken Thompson's toolchain and carried into the Go programming language. Odin's inline assembly uses a context-free grammar, but mnemonics are not shared across ISAs; only the syntax is consistent. The body of the template follows Intel operand order (destination, source), and the backend lowers the assembly per-target.

Physical registers are prefixed with % (e.g., %rax), while parameter and scratch names are bare (e.g., r, acc). Results may be left unbound at the call site, and the compiler ignores unused results implicitly. A parameter type can be one of several options, including integer, float, boolean, pointer, multi-pointer, or #simd[N]T.

An $name parameter is a compile-time immediate that must not be pointer-like and is only known and range-checked at instantiation. The template body includes optional blocks for results, bindings, and other declarations. Instructions are bound to names in the signature, with scratch, width-views, and clobbers declared directly in the block.

Disambiguation of input and output names is handled using pins and ties. Explicit registers are prefixed with % to prevent namespace collisions and take target-specific names. Templates can use explicit registers or scratch parameters, depending on the specific use case. The template may bind input and output operands to a single register (in - out), tie a pin to a specific register, or force a specific physical register using a name.

Scratch registers are allocated once and live in the binding block, not the body, and explicit registers prevent namespace collisions with user-provided parameters and other global constants.