Everyone Says Assembly Is Untyped–Everyone Is Wrong

8/21/2026 at 2:28:02 AM

I have very mixed opinions about the custom syntax. IMO the correct asm syntax, with very few exceptions, is the one in the manual. This is why Intel syntax is right and AT&T syntax is wrong: the ISA comes from Intel, the docs are from Intel and AMD, and those docs use Intel syntax.

So I was kind of hoping that the custom syntax would at least result in a very, very strong checker, at least as good as Fil-C’s. Maybe with an escape hatch to say something like “I know it looks like I clobbered xyz, but I promise I really didn’t.

Sadly, the CPUID example in the article apparently compiles, but IMO it shouldn’t have: CPUID takes two inputs, in EAX and ECX, and the example forgot to bind ECX as an input. One might argue that CPUID takes even more inputs if you’re on a VM and doing something special, but ECX is really quite unambiguous.

by amluto

8/20/2026 at 7:18:07 PM

An avenuge of research worth being sniped on is Typed Assembly Language

https://en.wikipedia.org/wiki/Typed_assembly_language

https://www.cs.cornell.edu/talc/overview.html

by genxy

8/20/2026 at 10:02:39 PM

TALs are not what I am referring to here. I am arguing that assembly is already typed and does not need extra annotation to be typed.

TALs are also solving an entirely different problem.

by gingerBill

8/20/2026 at 11:14:58 PM

The technique is good, and compilers that interact with assembly should do this, but as you outline, they basically just shove blobs of text around and hope for the best.

I didn't say you were referring to TALs. Yours is a syntax level check, not type checking of the program in the normative sense. It might be more accurate refer to your technique as an "instruction signature", rather than a type.

I would argue that that are complementary and not entirely different.

I thought it would be interesting for folks.

by genxy

8/21/2026 at 12:09:05 AM

But a language being “typed” doesn’t tell us anything useful. Untyped languages are typed too: they’re uni-typed (every expression is an expression).

I think you do your analysis a disservice by focusing on “is assembly language typed?” as the top line question. The more interesting question you examine is what do the type constraints in inline asm offer, and how do they interact with the host language’s type system?

by questionableans

8/21/2026 at 12:18:08 AM

I know that "untyped" means a single-type, but assembly operands have multiple different kinds of types (as I state in the article). What makes it really interesting is what you can know about each instruction and what it does (what operands it excepts, what it clobbers, what side-effects its has, etc).

And from that huge table of type information, this can be used to give good error messages and suggestions to the user because the compiler actually knows all of this. The type constraints here allow for a lot more than information that normal assemblers just don't give.

by gingerBill

8/21/2026 at 12:48:37 AM

Yes, and your second paragraph above is the interesting part that I would want the reader to focus on, starting from the title.

by questionableans

8/21/2026 at 6:40:10 AM

I don't care much about the typed part, I care much more that this is a good take on what an assembler should be, far ahead of the GCC monstrosity, that serves just one purpose well: it screams "don't use me". This feature could make Odin the language of choice for some types of projects, for it seems to remove so much friction.

by childintime

8/20/2026 at 6:54:47 PM

Sorry, somewhat of a tangent but regarding:

> The %0 and %1 are positional references into a list you have to count by hand.

You can name your operands in gcc inline assembly.

https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Output-...

Look for "asmSymbolicName".

On a phone so not checking if it builds, but something like `asm("add %[my_out], %[my_in], #3":[my_out]"=r"(outvar):[my_in]"r"(invar):);`.

by Krssst

8/20/2026 at 10:25:17 PM

The equivalent Odin syntax looks like this:

add_three :: asm(my_in: u64) -> (my_out: u64) { add my_out, my_in, 3 }

out_var = add_three(in_var)

Which is already infinitely more readable and requires no parochial sigils nor the arcane clobbering syntax.

by gingerBill

8/21/2026 at 1:00:48 AM

> But because of its time period, the built-in assembler only ever understood up to 80286 instructions, so the day you wanted a 386 and its 32-bit registers you were sent off to an external assembler anyway.

Or you just prefixed the instructions with "db $66", et voila your instructions were 32bit. I wrote a lot of inline 32bit assembly that way in TP 6.0 and 7.0.

by magicalhippo

8/21/2026 at 8:51:28 AM

True. It takes some time to grasp but gingerbill is right.

by fithisux