Everyone says assembly is untyped—everyone is wrong
gingerbill.org
gingerbill.org
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.
Otherwise, all the vendor syntaxes are different and all of them have many ugly quirks, for various historical reasons.
If you ever have to write assembly for at least 2 ISAs, e.g. x86-64 and Aarch64, then it is much more productive to use a unified, and better syntax, like the one described in TFA.
Nothing makes more likely the appearance of bugs than having to alternate frequently between two or more slightly different syntaxes.
Even with only one target ISA, if you frequently intersperse inline assembly within a high-level language source code, it is better to have harmonized syntaxes, as explained in TFA.
Historically, some ISA's have adopted the «src, dst» convention, whilst others have preferred «dst, src». We should be grateful that no engineer, in a moment of excessive creativity, attempted boustrophedon – a conceptual device solely appropriate to the likes of INTERCAL. Then we have 3 operand RISC instructions.
As with so many technical orthodoxies, the first convention one encounters tends thereafter to acquire the status of natural law.
The consistent application of the same convention is useful nevertheless. It reduces the unnecessary cognitive overload once one starts jumping across multiple hardware architectures.
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.
Here's Rust implementing this same feature:
https://doc.rust-lang.org/src/core/stdarch/crates/core_arch/...
Rust provides this for both x86-64 and the original 32-bit x86 and this is a function, not an Odin-style "template" but hopefully this helps show what you're supposed to do.
[Edited to add the Rust example]
https://github.com/odin-lang/Odin/blob/4247507dd5e31c9fd8716...
But I'm also not entirely sure why the example should not have compiled. It seems to me that the idea here is to be able to define a typed set of something equivalent to a function that inlines some assembly, but nothing about that inherently requires that the number of input or output parameters to the template match the parameters in the underlying assembly calls. There's no reason (in my mind anyway) why this shouldn't be a perfectly valid template:
// Returns the extended feature flags obtained by calling CPUID
// with EAX=7 and ECX=1
cpu_extended_feature_flags :: asm() -> (a, b, c, d: u32) [
a = %eax,
b = %ebx,
c = %ecx,
d = %edx,
] {
mov %eax 0x7
mov %ecx 0x1
cpuid
}The source you presented seems fine - it's explicitly setting the register. The trouble with the cpuid definition in the article is that it just doesn't set ECX at all
It does actually seem as though Odin is intended to notice this problem but maybe is fooled that the register is pinned (because we want its result value) and so the diagnostic doesn't trigger.
Reading this code reminded me that my annual summer leave ends this weekend because it would get so much review feedback if he worked with me. "Commenting out" blocks of code is NOT OK and neither are "if (false)" blocks.
For one, requiring an input parameter when it isn't mandatory would mean that you're spending cycles setting a register with a value that you don't need and is just going to be overwritten anyway. A good number of the CPUID calls never read from ECX, and if you're going to call any of them, then the value in ECX is irrelevant. And sure, it's only an extra instruction or two, but presumably if you're dropping down to inline assembly, you kind of care about every wasted instruction.
Again, this seems to me like it should be a perfectly valid assembly template (based on https://www.felixcloutier.com/x86/cpuid):
// Returns the maximum input value for basic CPUID information
cpu_extended_feature_flags :: asm() -> (a, b, c, d: u32) [
a = %eax,
b = %ebx,
c = %ecx,
d = %edx,
] {
mov %eax 0x0
cpuid
}
So e.g. maybe the CAD software executes a dozen CPUID instructions during startup, and then based on those it uses AVX512 vectorized operations later on some hardware but uses SSE instead on other hardware.
I haven't read Intel's manual for a modern x86-64 CPU, and I certainly haven't read the community notes about this stuff which would tell you if, despite the documentation you need to behave differently, but my assumption would be that everybody clears ECX if they don't want a non-zero subleaf and that this is either known to be necessary or an obvious way to avoid nasty surprises in code that is never perf critical.
But that seems to be saying that the inline assembly template should have the same shape as the underlying assembly calls that are made. If the underlying call might read 3 registers, then the complaint appears to be that the templating system MUST require a template that calls that assembly to also have 3 inputs, even if it won’t use all 3.
My thinking on this is the templating is a syntax for function declarations where the function is assembly code and not more higher level language code. We don’t require that functions have the same number of inputs and outputs that the code called within the function has in order for it to compile, I don’t see why it would be necessary for the assembly templates to work any differently. I get that `cpuid` specifically isn’t likely to run in the hot path of any code, but the underlying principle is the same. If you’re dropping to assembly, you likely have some performance tuning you’re trying to do. A templating system that requires your template inputs to 1:1 map to all the possible inputs of all the assembly calls you use in the template, regardless of wether you need or use them is adding extra instructions and waste for (to me) no obvious benefits.
But we're not suggesting this ridiculous and arbitrary restriction. What we're suggesting, and in fact I think what Bill actually intended in Odin, is something much more useful.
A templating system that requires all possible inputs of all the assembly calls you use in the template are well defined.
What you seem to want is exactly the thing Bill doesn't like about existing functionality. You can cheerfully ADD two registers together and then use the result but without ever determining what's in those registers. What is the result? -shrug- might be anything.
What Odin seems to intend (but this CPUID example seems to suggest is buggy) is that it will check you've actually written code which means something. You do not need to make those registers inputs of your template, you just need to make sure they're well defined. For example you could set them directly in the template, as with your leaf 7 sub-leaf 1 example.
That (modulo bugs) is a big improvement for this particular corner of the 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 (general-purpose, vector, mask), the width of each operand,
the range each immediate may take, and what the instruction clobbers
(flags, memory, particular registers).
...
That is not the absence of a type system: that is a type system; a rather
rich, dependent, per-instruction one.
...
The params are your inputs, as plain names with Odin types. The results are
your outputs, again plain names with types, sharing the same signature
syntax as an Odin procedure.
...
The params and results are optional, like with a normal procedure type, and
the bindings are completely optional if they are not necessary.
Some instructions like ADD[2] (Vol 2A 3-14) are defined to have multiple forms and those forms each take 2 operands. So the type of the instruction would be `ADD T-OP1, T-OP2` for each of the possible combinations of operand types for the ADD forms. And the templating system and compiler would validate that if you pass a given parameter of a given type to one of those operands, that your types match up.
Some like ANDPD (Vol 2A 3-63) have two forms, one that takes 2 operands and one that takes 3. The 2 operand one says that the first operand is a read/write register, where as the 3 operand forms say the first operand is write only. Presumably if you took an input and bound it to the first operand in a 3 operand form, the compiler would at least emit a warning about this if not an error.
But now if we look at the definition of CPUID (Vol 2A 3-203) the only valid form it has is a form with no operands. So if we were defining a type for the type system to compare against, the only possible correct answer (to me) is `cpuid` with no operands. That is the type system should happily allow inline assembly that calls `cpuid` but not inline assembly that calls `cpuid %eax %ecx` because that's not a valid form of the instruction.
Further the definition explicitly says that for some values of EAX, the value in ECX would be ignored entirely, and for invalid values in either field, the output values are all "Reserved". That tells me that as far as a type checker is concerned, any invocation of `cpuid` as long as there are no operands is a valid invocation. A type checker doesn't check the values of the fields being used, and IMO any argument that since it could read ECX, then the type system should enforce you set a value it to it can be equally countered by an argument that since cpuid will explicitly ignore ECX with certain values, it should never require you to set ECX because that might cause you to set it with a value and get an unexpected result because the value you provided to EAX was one of the values that causes it to be ignored. In either case we're asking the type checker to help us prevent a logic bug, not a type bug.
You might say that the "always require both fields to be set" is at least an easy check that could be applied universally, then the question would become how would it intersect with multiple invocations of CPUID? If you invoke:
mov eax, 0x0
mov ecx, 0x0
cpuid
cpuid
Given the stated goals in the article seem to include not requiring the explicit statement of implicit behavior, requiring setting ECX for instruction that will ignore it would seem counter to the goals.
[1]: https://www.intel.com/content/www/us/en/developer/articles/t...
[2]:
As a side note, I'm curious why (based on your comment about ADD), it would be desirable for a type checker to want to prevent you from doing something like this:
really_awful_rng :: asm() -> (r: u64) [
r = %eax,
] {
add %eax, 0x1
}
No. Never do this. If you don't care and just want random numbers use for example RDRAND, if you do care, design a proper PRNG with your preferred characteristics and seed management. YOLO programming is a bad idea always but it's especially bad when applied to assembly.
To underscore what this software is for let me quote you a diagnostic it emits:
{instruction} implicitly reads {register}, but nothing in this template produces a value for it; pin an input parameter to {register}, or write {register} before this instruction
I agree you shouldn't do it, that doesn't make it invalid to do.
> To underscore what this software is for let me quote you a diagnostic it emits
Well, then I stand corrected on the intent. That pretty clearly spells out that the template checker will validate that (at least for non-branching assembly) all implicitly read registers are given an explicit value and error if not. So that should mean the example in the article actually would not compile, since the rexcode definition lists both RAX and RCX as `implicit_rd`.[1] I appreciate you finding that bit of validation code and persisting in helping me learn something new, this isn't an area of coding I spend a lot of time in so it was instructive.
[1]: Does it compile? I don't have any odin dev stuff set up, but I might just try it in the next little bit just to see.
However my reading of the implementation is that:
1. Bill over-sells the value of rexcode. rexcode is Odin code, so the actual "value" derived in Odin's own compiler is just that it scrapes the data out of rexcode. That's not nothing but it's not much.
2. Bill's new template feature doesn't remember that we can pin an output, so it notices that ECX is pinned and concluded it is safe for CPUID to read it. That's a very small bug, and it's even possible I've misunderstood it, but that's my reading.
‡ Odin provides a lot of sorting algorithms. I wanted to measure how fast they are, which I did by comparing against a Rust install on the same toy machine, all of them are much slower than Rust's built-in sorts, but interestingly the provided "slice sort" which is most analogous to Rust's [T]::sort and [T]::sort_unstable is a "Smooth sort" which is relatively obscure and actually is only as slow for pre-sorted input as my Rust sorts are for unsorted input whereas most of what's provided is way slower even for pre-sorted input.
2. That was a bug and it has now been fixed, along with many other analysis bugs.
3. The sorting algorithms are getting an overhauls soon to be a lot faster.
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.
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).
It supports x86, too, and we're working on Arm64.
> uses Intel-style syntax
Yes, because the instruction set references are in Intel syntax. The backwards gcc asm causes me seizures, like trying to write cursive with my left hand. The asm for Arm64 will also follow Arm's instruction specification.
> D's inline asm is also statement-based
That's so the source code can be tokenized and parsed without needing special behavior inside the asm { ... }.
> it still uses %0-style parameters
Not sure what you mean. RAX means register RAX. %RAX is not accepted.
> especially regarding `lock` being treated as a separate instruction
That just makes it easier to parse!
Anyhow, thank you for the kind words! I am proud of it, the only troubles I have is when Intel adds wacky new instructions that just don't fit in the instruction encoding tables.
Well I assumed so because amd64 is a superset of x86. But nice to know you're working on arm64 too.
Regarding Intel-syntax, I think there is a little miscommunication here since I try to explain what I mean in the article. Intel-ordering is a good idea, but using nothing but the Intel-syntax wholesale is not universal enough, and needs modifying, especially for AMD64 and other ISAs. Odin's is Intel-like too, but fully Intel by design.
> That's so the source code can be tokenized and parsed without needing special behavior inside the asm { ... }.
This is why Odin's asm templates have their own universalized syntax. Thus the entire article.
> Not sure what you mean. RAX means register RAX. %RAX is not accepted.
This: https://github.com/dlang/dmd/blob/master/druntime/src/core/i...
It's why I referred to your "trick", which is something I wanted to need in the first place.
> That just makes it easier to parse!
For Odin's asm template syntax, it's not about being easier to parser, it's about having a context free grammar that is the same across ISAs. If I was to allow for prefixes directly in the grammar, either prefixes would have to have their special syntax or you'd need to have a context-sensitive grammar.
A little secret - the D parser does not actually parse the asm syntax. It just snarfs up tokens until it sees the `;`. The semantic phase of the compiler then applies a grammar over it, which is not the D grammar, but the Intel grammar. This enables it to apply custom grammars to each supported instruction set.
I did not want any of that for any reason.
I really like it when he does because it allows me to see what he has done for D, and learn from it.
"why is it a bad thing if you do X thing incessantly". in this specific case it's called shilling. if you've been on hn for longer than a week you'll notice he advertises D as if it's his fulltime job (which it probably is).
I am not paid, nor work secretly (I use my real name), and am not tricking anyone.
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).
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
}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.
On concern I have is how this maps to ARM64 syntax, because ARM64 is massively overloading all mnemonics.
For example:
ld1d z0.h, p0/z, [x1, x2, lsl 3]
ld1d z0.h, p0/z, [x1, z0.h, lsl 3]
ld1d dst, p0/z, [base + idx<<3]
Also, maybe I missed it, but how are you dealing with things like the /z modifier, pre/post-increment load/store and load pair? Or things like TBL/ST4/LD4?
Oh and how are the types going to work for RVV, where the type can't be determined at compile-time in all situations?
My hunch would be the following:
sve_ld1d_scalar :: asm(base: [^]u64, idx: i64, #mask pred: u16) -> (dst: #simd[vscale * 4]f32) [
dst = %z0,
pred = #predicate(indirect=zeroing) %p0,
dsth: u16 = dst,
] {
ld1d dsth, pred, [base + idx<<3]
}
sve_ld1d_gather :: asm(base: [^]u64, #mask pred: u16) -> (dst: #simd[vscale * 4]f32) [
dst = %z0,
pred = #predicate(indirect=zeroing) %p0,
dsth: u16 = dst,
] {
ld1d dsth, pred, [base + dsth<<3]
}
This is not current behaviour yet but it I am considering it when I need to specify this for even AVX-512 and RISC-V behaviour (which has multiple different possibilities).
No, you have tables _of the instructions that the compiler codegen may use_. You have no tables of what someone may use inside inline assembly, because for most architectures it may not even be possible to build such tables in the first place!. That's a reason why usually you rely on the users specifying the side effects manually for these cases.
> Okay? There are no 128-bit integer registers on AMD64, ARM64, nor RISCV-64. So I have no idea what you are on about.
You have no idea why you would need to pass a 128 bit int in two registers if there are no two 128-bit integer registers? Am I missing something here?
Even rdtsc is already returning a 64-bit into two registers (another x86 idiosyncrasy I suppose), rather than "two separate return values", something the examples kind of gloss over.
That's a distinction without a difference.
> ...because for most architectures it may not even be possible to build such tables in the first place!.
Name the architectures and the specific instructions; do not be hypothetical. In certain runtime-dependent cases like AVX-512, the clobbering is runtime-dependent which then can be explicitly stated by the user.
> You have no idea why you would need to pass a 128 bit int in two registers if there are no two 128-bit integer registers?
I completely understand, my point is that you would pass the two 64-bit parts into separate registers. There are no 128-bit integer registers on the platforms we care about, but if they did exist, supporting them would be trivial. So if you want to pass an 128-bit integer, it will have to be done in two registers, which is literally the point. `asm` templates are not necessarily meant to be used bare all the time, but sometimes it is better to wrap them in a procedure with the correct calling convention too (e.g. "c" or even "naked") if you want to utilizes Odin's native 128-bit integer types as part of the parameters.
You realize you're asking for a list of instructions that are not used by codegen but exist in the ISA? Because it is practically infinite.
Even a plain old "in" in x86 may go from clobbering only the target registers to clobbering memory to clobbering about _every_ register (e.g. under vmware). And there's a million like these on any architecture.
Short of generically saying all clobber everything, I really don't know how can you build a table here.
And you are forgetting that the problem does not only extend to the compiler here, but to whoever is writing the assembly, because you may be using some register that may or may not be clobbered on depending on which 'mul' instruction operand size was used by the previous one!
> So if you want to pass an 128-bit integer, it will have to be done in two registers, which is literally the point
Some inline assembly syntax (e.g. Watcom) does support return an int64 as 2 registers. Are you understanding this as me asking to change the instruction to return the value in one register or something? What I'm saying is that it supports mapping its 64 bit native type (which is either two registers or always in memory, I don't care) to an inline assembly snippet that uses/returns an int64 value in two registers.
This is just an example of the reason inline assembly syntax grows unwieldy, and there are more! Just about any 'letter' of gcc's extended ASM is another one. You seem to be trying to implement something like intrinsics here, with a very limited view of what people use inline assembly for, and that's fine, but it simply falls short, and that is why you have a hard time explaining the decisions behind inline asm syntax.
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).
TALs are also solving an entirely different problem.
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.
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?
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.
I suspect the main reason someone might quibble over the “assembly is typed” assertion is that many programmers have a rather narrow view of type systems, heavily skewed by OOP patterns.
And we already track all of the basic side-effects and clobbering that each form of each mnemonic does. That's kind of the entire point of this being possible: it's all "typed".
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.
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.
When one provides the full effect of the operation in the source code, a properly ported compiler backend should be able to spot the pattern and emit the instructions with matching non-C semantics. (Typically, saturated operations are a very low hanging fruit.)
That doesn't always work because the optimization passes targeting local optimum break these patterns while "optimizing" them, so they arrive to the instruction emitter unrecognizable. And these passes, living in the generic "good-for-all" area of the compiler core, cannot be made aware of what a particular target does or doesn't support. So ironically, such instructions appear more when the optimizations are disabled.
Intrinsics emit internal representation forms that optimization passes don't dare to touch.
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.
>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.
It’s an effect in the type system, not a data type or behavior.
If you give an untyped number to B's print function, it'll print the ASCII letter. That doesn't make B typed.
And this is being generous. Types in typed languages aren't just about the data, it's about what you can do with that data. If a function requires a pointer, it needs to know that that arbitrary collection of 1s and 0s is a pointer. Typing is the mechanism to enforce that. All (?) functions on all(?) languages assume, if they don't outright know, something about the type, so are all languages typed? And in that case why is the distinction at all meaningful?
You're talking about objects. I'm talking about integers, chars, pointers.
A 32bit register could be handed to sign extend, it could be used as pointer, used as an interrupt number, printed as a letter. The processor doesn't care. Assemblers typically don't care. Different things you do with that number imply that you are using it as a type, but nothing cares if you use a pointer as a system call number and then print is out as a utf32 character.
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.
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.
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.
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.
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.
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.
I don't have Bill's brand new nightly Odin compiler with "assembly templates" but I don't really see any useful way it could "fix" this. The machine does not care what your values "mean" to you, that's a human idea and that's what types are for.
That's his "aha, they are typed!" gotcha, but it's really not what anyone was talking about. And anyway, even in that case it isn't guaranteed - RISC-V has an optional configuration where float and integer registers are the same.
Most ISAs do.
On x86 and arm scalar and FP registers are separate, it's just that they overlap FP and SIMD registers.
On RISC-V there are three separate register files for scalar, FP and SIMD. Although you can overlap scalar and FP in some minimal embedded configurations.
Most assemblers do not allow the programmer to declare the data types of the variables, so they do not check whether the types of the operands are valid.
Nonetheless, nothing would stop someone to modify an assembler to require the declaration of the data types and to generate assembly errors whenever there is a type mismatch.
The fact that if you give to an instruction that expects a floating-point number an integer operand then the CPU will compute a bogus value, is irrelevant.
The same will happen if you give operands of the wrong type to any function of a program written in a high-level language.
Any decent modern compiler will prevent you to use the wrong types, but if you use some tricks, you can still avoid this and invoke a function with wrong argument types, in which case it will compute some gibberish.
So the parameters of HLL functions or procedures have well defined data types and the same is true for the operands of CPU instructions.
Enforcing the use of the correct types can be done only at compile-time/assembly time, by the compiler or assembler.
This happens because for efficiency reasons the primitive data types do not contain a tag for identifying their type. Only the programmer-defined union types contain a type tag, so that their type can be identified at run-time. In the languages without static type checking, but with dynamic type checking, any value belongs actually to a kind of tagged union type that includes all the types that can be used in that language, so the type of any argument can be determined at run time, but this is what makes such languages slow.
In conclusion, there is no real difference between an assembly language and a HLL with static type checking, except that most people who have written assemblers were lazy and they did not implement type checking.
The first C compilers never checked the types of the function arguments. Today this would no longer be an acceptable for a C compiler. For the same reasons, it should be no longer acceptable for any assembler to not check the data types.
It is likely that the fact that no well-known assembler does an appropriate type checking is due to the necessity of defining a much more ample type system for an assembly language than for most high-level languages, so this would be a lot of work. Because the assembly programmers were used to lax assemblers anyway, implementing such a feature was not considered as a priority.
> 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):);`.
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.
That's why it looks like an escape hatch. It is one!
One can already see how this syntax isn't up to the task by the decision to put x86 prefixes on a separate line. The author tries to justify it but this comes across as trying to excuse a poor design decision.
Also the AI slop tone of this article is awfully grating. I nearly gave up reading it because the LLM editing artefacts were so jarring.
And I do not even seen why a universal syntax for such ISAs is impossible to support either at the syntax level. Hexagon's `.new`/`:sat`/`:<<1` stuff could be easily added into the universal syntax (with a better syntax), even if other ISAs do not support it. Same with SHARC's parallel-operation separators: you just pick a different syntax.
Even now, the full `[base + indexscale + disp]` syntax is not semantically supported for RISCV64 because they do not support `indexscale` in their memory operands.
Yes the prefix syntax is a quirk but if can tell me an alternative syntax that is context-free to solve this problem that is also not too stark nor dense too read, please do! I am open to new ideas, but it seems that even other assemblers like Plan9, Go, and D, all came to similar conclusion with `lock; xadd ...`.
And the article was not LLM written.
SHARC is pretty weird, there's neither LLVM nor the GNU backends for SHARC. If you explained that you want to have something less crazy than ancient C they're going to say you want a Blackfin not SHARC because that's a more plausible target. SHARC's addressable memory comes in 32-bit uh, bytes.
The instructions have bit-width, arity/source/target requirements so technically there are types whereas an abstract virtual machine that only operates on some fixed set of integer registers is mostly untyped (modulo number of registers).
Like say adding an 8-bit type flag to each instruction, and keeping a table of which memory ranges have which type, then only allowing compatible instructions on that memory?
Never understood the gibberish from UNIX compilers that always forced me to look down what all the flags are about.
At least Odin follows a similar approach.
[0] - At least on some Amiga compilers, and D as well.
And where is the AT&T? Did you even look at the syntax or read the article? Is it just the use of `%rex` to prevent namespace collisions with parameters and constants which could hypothetically be named `rex` (and there could be good reasons they are named that too)? There are no other sigils in the grammar. The order of the operands is Intel-like. The memory operand syntax is Intel-like.