Following the vendor syntax may be useful if you only ever program in assembly for only a single target ISA.

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.

> 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.

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.

Zortech had a complete inline assembler in the 80's. It's now in the D compiler!

> 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
  }

I love the Watcom C inline assembler. I use it frequently in my retro projects!

Oh man, #pragma aux.

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.

> 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.

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.

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.

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.

> 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). In x86, a mulps wants a 128-bit vector register; a crc32 in one of its forms wants a 32-bit destination and an 8-bit memory source; div reads and writes rdx and rax whether ask to it do or not.

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).

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.

Lisp machines come to mind, like the Symbolics 3600.