Hacker News Reader

Comment by Graziano_M | Hacker News Reader

AT&T vs. Intel syntax has caused many arguments in some of my circles. AT&T is an atrocity and if you disagree... you're wrong. :)

View on HN

  op src dest

is the logical order, the rest of the syntax I don’t care about much.

I used to think this was more intuitive, but after using both for a while I came to the conclusion that putting the destination first is much more practical, because my eyes can scan the left column to quickly find where a register was last written to. If the destination is last, it doesn’t appear in a consistent location horizontally.

Be that as it may, the AT&T indirect memory reference `section:disp(base, index,scale)` is an abomination unto God.

At least the Intel one makes actual mathematical sense: `section:[base + index*scale + disp]`

That “logical” order is only because you’re trying to read it like a sentence (“mov/add ebx into eax”) when you should be reading it like a formula or what it actually is - code. And that’s fine, but considering Intel created the chip, it makes sense that they should decide how the assembly syntax should be, not AT&T.

The only reason “AT&T syntax” exists for x86 is because people working at AT&T refused to use Intel as the authoritative reference on the syntax, and, instead, decided to follow the convention of the PDP, Motorola, etc. family and friends. Hence why `as` (and subsequently `gas`) have that as the default.

In mathematics variable = value, variable receives value, ergo op dest src.

That is logic.

...math has no such order. Half the point of algebra is that the two sides of the equation are semantically equivalent and can be swapped at will.

And it has no state. Half the point of computation is maintaining state for the purpose of efficiency. So, computation gets an "assignment" operator where pure math lacks one, pure math being relegated to subscripts of time and indicator functions instead.

Good luck convincing anyone that value = variable makes sense.

My math teachers had no problem with '42 = x' vs 'x = 42' as long as the steps made sense to get there. In fact they'd probably comment that there was no need to go with 'x = 42' if I obviously took a circuitous route simply to end up with x on the left side of the equation, as that would have demonstrated a lack of internalizing some of the base ideas of algebra and it's approach of equation symmetry.

You should distinguish the meaning of = in mathematical and meta-mathematical statements. “42y = yx, therefore 42 = x” is fine; but “let 42 = x” is not.

Some older C coding styles recommend that order because before compilers added warnings, “if (17 = variable)” resulted in a diagnostic, while “if (variable = 17)” would not. Nowadays, I think most programmers prefer putting the fastest-changing expression first.

Yeah that is due to clever C semantics that that should never had allowed for anything other than boolean expressions in conditionals like proper grown languages.

Indeed. Besides, “let there be light” is clearly destination-first, so this matter was already resolved by Genesis 1:3.

Which direction was the Hebrew text written in?

That doesn’t follow. variable = value, ergo dest op src.

That is just an arbitrary notation, nothing to do with logic. In English at least, "add 4 to x" is more natural than "add to x 4".

Ergo op src dest

But English "add 4 to x" tells you nothing about where to store the result. : - )

"Add 4 to x and store result in x" vs "Let x be x + 4"?

Without any other context, you generally assume that the target is an accumulator.

So "add 4 coins to that bucket", generally means at the end of that operation the bucket contains at least four coins plus any coins that were already in the bucket.

Huh, I think my brain is not wired to think about `x` as a storage, it is closer to "add 3 to x for x = 2", which then gets reduced to "add 3 to 2" and then the destination is missing...

In mathematics variable = value ≡ value = variable

That's just a convention. The way we would order the sentence in English is also just a convention.

You know what the logical convention to use would have been? The order that every assembler on the planet already used.

Postfix , infix, prefix, crucifix.

That is extremely confusing for comparisons, which are effectively a subtraction.

I’m talking about moves and copies.

It's even more confusing if moves have a different operation order from arithmetic ops and comparisons, no?

No, each should have what makes sense, whether analogous to math or a shell command.

This implies that dst<-src "doesn't make sense"; but then why does practically every programming language use this ordering?

A minor historical mistake/misdesign around the equals sign. Looks like algebra but fundamentally different.

TFA says "The `source, dest' convention is maintained for compatibility with previous Unix assemblers."

Sketchy part is when operations read and write with the same argument. Op first is nice for that as it becomes op arg0 arg1.

I quite like the SSA style which tends to be dst0 dst1 opcode src0 src1 but that doesn't model assembly brilliantly. Perhaps that order with read-write arguments required to appear on both sides of opcode with the same symbol has some merit.

Which is my all memcpy-like functions in C/C++ standard library take arguments in dst, src order.

They are using a classic dollar sign for assignment, so clearly at&t is better.

> They are using a classic dollar sign for assignment

They're using a dollar sign for immediates.

As if you can't notice that it's a number.

    addl $4, %eax

that's 3 different completely unnecessary symbols for things which are not ambiguous in the first place:

- the operation width is provided by the registry

- a number is an immediate

- a register is named

Hence the much less noisy Intel syntax:

    add eax, 4

addl is not necessary if it is not ambiguous

    add $4, %eax

- is fine

Compare with

    add 4, %eax

The "less noisy" Intel syntax becomes:

    add eax, DWORD PTR [4]

Most assemblers for Intel syntax will let you write:

    add eax, [4]

if you desire. Indeed, many disassemblers will follow suit in unambiguous cases. IDA, for example, does this.

The only time “DWORD PTR” is required is when (1) you're working with old assemblers, or (2) you're using a memory operand with an immediate:

    add eax, [4]       ; inferred
    add [eax], 4       ; ambiguous
    add DWORD [eax], 4 ; explicit

A disassembler may output it when not necessary, however.

The comma is unnecessary too, so that’s 4 unneeded symbols.

Contemplate the AT&T vs Intel syntax for x86 addressing modes and say that again.

X86 addressing modes are an atrocity: https://stackoverflow.com/questions/63571979/clarifying-thre...

They are an atrocity in AT&T syntax. They are perfectly readable in Intel format. For example:

https://blog.yossarian.net/2020/06/13/How-x86_64-addresses-m...

That is an excellent write up, thanks.

Reply on news.ycombinator.com