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