Hacker News Reader

Comment by kstenerud | Hacker News Reader

> Putting the destination operand first emphasizes the site of mutation.

This doesn't make any more convincing an argument than the "linguistic" and "consistency" arguments he shot down earlier.

Why should putting the mutated argument first emphasize it any more than putting it second? If you order things the same way every time, people will implicitly know which one is the mutated argument because that's how the language is structured.

There really is no strong benefit to either ordering, other than that [src, dst] is closer to human language (which is a minor benefit at best and not worth fighting over).

View on HN

I'd agree that there is no strong inherent benefit to either ordering, except that it would be good not to needlessly violate expectations about mathematical operations. AT&T also permutes the order of operands of comparisons, which is just bizarre: https://gcc.godbolt.org/z/h6EcP5Yv9

"Compare A and B and do X if result is 'less than'" should never mean "do X if B is less than A".

Anyway, the most important consideration for me is that standard documentation uses Intel operand order. Intel's manuals are hard enough to read, I wouldn't want to additionally permute operands in my head.

Certainly, I'm not defending AT&T in any way, shape, or form. I think it's ugly and confusing as hell.

My only point is that argument ordering is not something to worry about, and every argument I've heard one way or the other has been weak at best.

the comparison operand ordering problem is a legitimate problem that i keep having even after having written thousands of lines of assembly in at&t syntax. i hope it goes away after i get to tens of thousands...

The actual argument there is that most instructions with explicit, specified output registers have exactly one output register (which is mutated) where as most have multiple, non-mutated input registers. Of the instructions with multiple mutated output registers, most encode 1 or 0 (I am just going by memory here) output registers with the remaining being implicit.

Google C++ guide says to put mutable parameters last, but I've seen other style guides say the opposite.

If your mutable thing is mandatory, then I think it should go first. Otherwise, you will be in a strange position when there are default arguments. The mutable thing would then be sandwiched between immutables. Of course if your mutable parameter is optional, it must be after all the required parameters.

The argument above applies neatly to assembly instructions, which generally change one thing.

> [src, dst] is closer to human language

In English, but not Telugu.

Programming languages are pretty much always in English though, including these mnemonics.

I think because it's always in the same place and always first. That definitely emphasises it.

Personally I think assembly should just have a little more syntax. If we wrote

  dst = mv src

  dst <- add src

it would just be obvious.

People tried that (I forget the actual language now), and it just turns into a mess because now you have all these special cases (+, -, =, etc) and special syntaxes that don't transfer well to non-mathematical or multi-parameter instructions.

This really is where AT&T fell over: Their syntax evolution feels bolted on for the most part, and not well thought out. The result can be quite confusing in a lot of cases.

Kalray's MPPA does that, and it's really refreshing: https://gcc.godbolt.org/z/8Wch4MfMq

The operand order is because intel were flip flopping between load semantics and move semantics with the 4004, 8008, 8080, 8085, 8086 progression.

Remember that when the 8080 engineers left to found Zilog, they changed the MVI instruction to LD, as it had been intended.

(LD on 4004 and 8008, MOV on 8080, LD/ST and MOV on 8085, MOV on 8086)

8080 and 8085 are basically the same, and have both MOV, MVI and LD/ST. The advantage is that the mnemonics directly correspond to the operations supported by the hardware, once you learn them you know what registers can be used where.

Z80 is also highly unorthogonal (even more so than x86), but obscures this by using the same mnemonic with different operand combinations, not all of which are legal and some require prefix bytes.

While I hadn't considered the emphasis argument before, I think it actually makes a lot of sense. You're kind of front loading the mutation context in your consciousness.

Reply on news.ycombinator.com