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

That is logic.

In mathematics variable = value ≡ value = variable

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

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

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

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.

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.

Postfix , infix, prefix, crucifix.

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.

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. Also, 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 accept Intel’s manual 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.

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

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

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.

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.

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