The post introduces Odin’s inline assembly design, which replaces the usual stringly GCC-style interface with callable asm templates that look more like ordinary language constructs. The core claim is that assembly is not really untyped. Instructions already constrain operand kinds, register classes, widths, immediate ranges, and hidden effects like flag or register clobbers. Odin turns that into compiler data, so inline asm can be parsed, checked, and diagnosed instead of shoved through as opaque text.
That landed well. People broadly agreed that existing inline asm interfaces are painful, especially GCC’s constraint syntax, and that a compiler that actually understands instruction forms can give much better errors and safer defaults. The strongest positive reaction was to the ergonomics, not the headline. Readers saw the value in making asm callable, readable, and portable across multiple ISAs with one host-language-friendly syntax.
The pushback was sharp on terminology and scope. The headline annoyed a lot of people because most programmers mean something narrower when they say assembly is untyped. Data in registers or memory carries no persistent type tag, and the same bits can be treated as ints, pointers, chars, or floats by the next instruction. What Odin is really typing is the instruction interface and its effects, not the data model of the machine. Several comments said the article would have been stronger if it led with that.
The other big objection was practical: the nicer the syntax gets, the easier it is to hide the weird parts that make inline asm hard. One commenter pointed out a likely bug in the article’s
CPUID example, where
ECX appears to be used as an output pin but not declared or initialized as an input even though some CPUID leaves depend on it. Others said that large or production-grade asm often depends on assembler directives, mode switches, hand-managed register save and restore, or runtime patching tricks that defeat any attempt to infer semantics from instruction tables alone. That limits this design to the small and medium snippets where inline asm is still the right tool. For bigger or stranger cases, people still expect raw assembler passthrough or
intrinsics.
A side thread on syntax showed the real tradeoff. Some insisted vendor syntax is the least surprising because it matches the manuals. Others argued that if you write asm for more than one
ISA, a unified syntax beats memorizing every architecture’s historical quirks. Even critics of Odin’s specific choices accepted that cross-ISA consistency is a legitimate design goal. The bottom line was clear: the compelling part here is not proving a philosophical point about type systems. It is building an inline asm interface that the compiler can reason about, as long as it stays honest about the corner cases where low-level code refuses to fit the model.
gingerbill.org