Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Everyone is not wrong, they just don't mean the straw man that you are taking down. The fact that there are integer, float, vector registers etc. does not invalidate the point that people mean when they say "assembly is untyped".by IshKebab
- Assembly language itself is very strongly typed, because the types of the operands for any instruction are enforced in hardware by the CPU.
However, most assemblers do not help in any way the programmer with this, because they do implicit conversions between any data types, for the values stored in memory or in registers, or used as immediate operands.
This is only caused by a historical tradition. It would not be a problem to implement an assembler that strongly enforces the use of the right data types and which allows only a minimum of non-dangerous implicit data type conversions.
by adrian_b - 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
- The GCC assembly syntax is not a monstrosity, it was a necessity given how GCC represented the intermediate representation of the code. Historical GCC docs actually explain the rationale of the design pretty well.
Moreover, since GCC was one of the very few C compilers that targeted a large number of very diverse ISA's at the time, they wanted to have a uniform way of injecting the assembly code across wildly varying ISA's.
by inkyoto - Good article, but it's so LLM-y, wish it wasn't. Either Bill needs to stop slopping, or he needs to get an editor.by the-smug-one
- > 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 - True, but that still gave you access to only a subset of the 80386 instructions.
For the others, you had to write them entirely in unreadable hexadecimal, adding a data-size prefix was not enough.
By far the most useful were the 32-bit addressing modes. With your method, you could access those by adding just a "db $67" prefix, but then the addressing modes would have been greatly obfuscated by the 80286 notation, so that would not have been much better than writing the entire instruction in hexadecimal.
by adrian_b - I feel like this article means well, but assembly or machine level types are not the same. Sure, the assembler and cpu will execute the instruction with the given type, but the next instruction can use a different instruction with different types and no one will be any the wiser. So one operation’s uint64 is another operation’s int64.
The type data in assembly doesn’t live with the data itself, nor are types for data stored anywhere.
I get the point but I think it just misses the mark.
by caspper69 - >Assembly is usually considered the perfect example of such an “untyped” language.
>However, every instruction has a set of valid forms. Each form dictates the kind of each operand (register, memory, immediate, label), the class of each register...
So if I lea that means the type is pointer. If I add it's an int. If I print it's some kind of char.
So it's about as typed as B. The untyped predecessor to c....
Will any errors get raised is you sign extend an unsigned int?
Yes you can enforce types the processor doesn't care though, and if you want to treat assembly as distinct, I can't think of any assembly language that enforced types.
by benj111 - Generously I assume Bill is thinking of "register classes" as types, so it doesn't care that you're using LEA on an integer, just that you used one of the registers for which LEA is available and not say XMM0
Ultimately the proof is in the pudding. If I screw up some inline assembly in Rust the diagnostics aren't very good because Rust doesn't deeply understand the assembly, whereas obviously for other things they're excellent. If Odin's diagnostics are great because it actually understands these "templates" that's a meaningful benefit to programmers.
by tialaramex - Assembly doesn’t have typed objects, it has typed instructions. It’s like checked exceptions in Java—you have to declare them in the type signature of the method, and the compiler enforces that they are either caught and handled, or also explicitly declared by the caller. The type declaration is all about possible side effects.
It’s an effect in the type system, not a data type or behavior.
by jkhdigital - This article is really about the inline assembly syntax developed for the author's programming language Odin (and definitely nothing about TALs, typed assembly languages). There are a lot of interesting ideas here.
One of my criticisms, however, is simply pointing to how similar mainstream general purpose CPU architectures have become; they are all C machines. This radically simplifies the complexity on the compiler front where, it seems, the author is targeting amd64 and aarch64. Extending the compiler to rv64 will probably be straightforward.
I don't know anything about Odin, or its compiler implementation, but I imagine the language adheres to a view of the machine that matches the C machine model. Imagine a more esoteric language, the compiler would probably need an intermediate language matching the C machine model and in which the inline assembly would have to have survive some idempotent lowering to the intermediate representation before being further lowered to the object code. These details are what I am really curious about and probably the most intellectually stimulating.
The most interesting possibility is if the Odin compiler is itself written wholly in Odin. If this were the case, it would really show the power of the inline assembly syntax. As far as I am aware no optimizing compiler has really pushed this angle whilst targeting multiple instruction architectures. If I recall correctly, even the Plan9 C compiler moved some basic optimization to their genericized assembler, and I've not kept up with it as it's evolved into the current Go compiler.
Very interesting work as I have often though about inline assembly syntax in a high-level language. Keep it up gingerbill.
by sxzygz - > The most interesting possibility is if the Odin compiler is itself written wholly in Odin.
Currently, it is not (C++, mostly C style). As far as I can remember, Bill has previously said that a self-hosted version of the compiler might be a possibility, _after_ the 1.0 release and when the full spec of the language has been written.
- No, modern CPUs are not at all C machines, they are about as far of C machines as one could imagine, because they now implement in hardware hundreds of instructions that were unheard of in a DEC PDP-11.
The C language has only 2 kinds of integer data types, signed and unsigned, of various sizes. Moreover, the implicit conversions between them are erroneously defined and lead to data corruption, unless the programmer is extremely careful.
Modern CPUs, like those implementing the Intel/AMD x86-64 ISA or the Arm Aarch64 ISA, have 8 different kinds of integer data types, all of various sizes. For all these different data types the CPUs have dedicated instructions that implement in hardware various operations with them.
It is impossible to access in the right way from C all these data types. Only in C++ one can define custom data types and implement appropriate operations for them using inline assembly or separate assembly source files.
Those 8 data types are signed integers where overflow causes an exception, signed integers where overflow causes saturation, non-negative integers where overflow causes an exception, non-negative integers where overflow causes saturation, integer residues a.k.a. modular integers, bit strings, binary polynomials and binary polynomial residues (i.e. elements of a Galois field).
Unfortunately, most programming languages have not gone beyond the level of C, so they do not allow the efficient use of modern CPUs otherwise than by using inline assembly or compiler intrinsics.
Thus there is a great mismatch between most high-level programming languages and modern CPUs, the opposite of what the poster above said.
The mainstream CPUs have become very similar between themselves, but very different from the C machine model inherited by most modern programming languages.
by adrian_b - An avenuge of research worth being sniped on is Typed Assembly Languageby genxy
- OT: The 2nd link is the first time I've seen a Microsoft FrontPage website in decades. :)
- 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 - One of the problems with smart inline assembly syntax like this is that it turns out to be less helpful in a lot of practical inline assembly.
If you look at the way, say, the Linux kernel uses inline assembly, it really just wants the inline assembly to pass directly to the assembler. There's a lot of assembler directives in the inline ASM to do stuff like define instructions the assembler doesn't know about yet, or do fancy stuff like build a runtime instruction-patching system. I have inline ASM in one of my projects that bounces around between 16-bit, 32-bit, and 64-bit instructions.
Another issue is that larger blocks of code will use a myriad of approaches to save and restore registers, so you can't actually reliably rely on the instruction semantics to work out which registers are clobbered and which are preserved by a full block of assembly. So this syntax really only works for small bits of assembly, and these days, it's probably better to actually just use real compiler intrinsics for those uses (which is what most of the production compilers do).
by jcranmer - > AT&T bakes the width into the mnemonic (movb, movw, movl, movq [...] Intel’s syntax is to prefix the memory operand with byte, word, dword, or qword, but Odin’s just uses the Odin type system directly.
In GAS you can skip the width suffix from the mnemonic, and in most Intel assemblers you can skip the memory type operators like byte. They happily guess it from the operands. The problem is that on x86 (but also other ISAs, even if to a lower extent) the different operand sizes have a lot of side effects, which is why everyone just makes the operand size explicit, up to the point that apparently the author/LLM believes that it is mandatory to specify them.
This kind of defeats the headline of the article...
Tomorrow you need to pass a 128 bit int into two registers and your fancy syntax then also becomes a messy bunch of hacks. This is why everyone's inline assembly syntax looks like that, because they want to cover the weird cases (gcc's one is almost like an history book). You're normally using inline assembly for when you have some ridiculous corner case, if not, then what you ought to use is more akin to intrinsics...
Also it forgets Watcom C, which does have a complete but messy syntax for inline assembly (which combines nicely with its ability to specify really weird calling conventions).
- Oh man, #pragma aux.by winocm
- > the different operand sizes have a lot of side effects
Which we have massive tables for each form which track those side effects and clobbering information too.
> author/LLM
I am the author, and not an LLM.
> Tomorrow you need to pass a 128 bit int into two registers
Okay? There are no 128-bit integer registers on AMD64, ARM64, nor RISCV-64. So I have no idea what you are on about. And note they are templates, so if you want 128-bit integer support, you can just wrap that template in a procedure and handle the behaviour yourself.
by gingerBill - I love the Watcom C inline assembler. I use it frequently in my retro projects!by bananaboy
- > Tomorrow you need to pass a 128 bit int into two registers and your fancy syntax then also becomes a messy bunch of hacks.
There are no 128-bit integer registers in x64 or arm64 or riscv64. There are operations that represent 128-bit scalar operands/results by storing the top and bottom halves in two 64-bit registers. From what I can gather, it would look something like this in Odin for x64:
my_asm_mul :: asm(a: u64, b: u64) -> (c, d: u64) [ a -> d = %rax, c = %rdx, ] { mul b } my_mul :: proc(a: u64, b: u64) -> u128 { hi, lo := my_asm_mul(a, b) result := (u128(hi) << 64) | u128(lo) return result }by 10000truths - Zortech had a complete inline assembler in the 80's. It's now in the D compiler!by WalterBright
- Here's how D does it for the x86_64:
https://github.com/dlang/dmd/blob/master/druntime/src/core/i...
It's the statement form, uses Intel syntax, and the compiler keeps track of which registers are modified.
by WalterBright - is your fulltime job posting hn comments like "in D...", "this is how D ...", "for D..."?by mathisfun123
- D's approach is great, but it has a few limitations for my use case in Odin. It only supports x86_64/amd64 and uses Intel-style syntax, whereas I needed a solution that universalizes its syntax across multiple ISAs.
D's inline asm is also statement-based rather than a callable template. Though the mixin trick fixes this, it does mean it still uses %0-style parameters making it hard to read and write, something I want to remove completely.
It is great to see that we arrived at similar design compromises, especially regarding `lock` being treated as a separate instruction and thus separated with a `;` (which is automatically inserted by the Odin compiler).
by gingerBill - 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 - The syntax in the manual is embarrassingly outdated. Like, it's actually a disgrace and shameful for our profession that assembly languages and tooling are stuck in the previous century. There is absolutely zero logical reason we should be constrained to such primitiveness.
- > the CPUID example in the article [...] forgot to bind ECX as an input.
I'm not really familiar with this stuff, but the example uses what it calls a "pin" (which in their docs is a type of "binding") on ECX before calling CPUID.
by CBLT