Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

No one should use the AT&T syntax (2021)

outerproduct.net

Post reply on HN
Print view View original

31–40 of 112 posts

Re: No one should use the AT&T syntax (2021)

#31

Post by kstenerud »

IshKebab wrote: post #29
kstenerud wrote: post #14

> 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 lan…

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

Re: No one should use the AT&T syntax (2021)

#32

Post by comex »

The best argument for Intel syntax is subtraction and division.

Intel syntax's

    sub rax, rbx
is equivalent to AT&T syntax's

    subq %rbx, %rax
...and it computes (rax - rbx), not (rbx - rax)!

I suppose you could justify the AT&T syntax as meaning "subtract rbx from rax". But it seems incredibly counterintuitive to me.

Edit: As another comment pointed out, this issue also applies to comparisons and is even worse there. Intel's

    cmp rax, rbx
    jg foo
is equivalent to AT&T syntax's

    cmp %rbx, %rax
    jg foo
and it means "compare rax to rbx; if it's 'g'reater, then 'j'ump to foo". There's no good way to write that in English where rbx comes first. At best you could say: "compare rbx to rax; if rax is greater"…

Re: No one should use the AT&T syntax (2021)

#33

Post by kstenerud »

gergo_barany wrote: post #30
kstenerud wrote: post #14

> 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 lan…

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 considera…

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.

Re: No one should use the AT&T syntax (2021)

#34

Post by ketzu »

pclmulqdq wrote: post #25
ketzu wrote: post #17

Earlier quoted context omitted.

> Operand order in AT&T is really dumb I always found AT&T order much more intuitive to read. The "what am I doing" and then "where will it go" felt natural to me. But I didn't do much assembler, so my opinion doesn't matter :)

If you write for any CPU other than an x86, the Intel assembler syntax matches the syntax order you would get. It also sort of lines up with C and C++ syntax of putting the result on the left. I might be biased as an Intel-syntax-loving assembly-writing heathen.

> It also sort of lines up with C and C++ syntax of putting the result on the left.

The article also discussed this argument, and I find it weird, because higher level languages also put the operation on the right side.

Maybe I just prefer having the operation and the target close together? Having `abs(x) = y` put the absolute value of y into x, would be extremly weird to me in C++.

> I might be biased as an Intel-syntax-loving assembly-writing heathen.

I guess the world is on your side, and I just avoid assembly where possible :D (although, not really because of the syntax part, I can live with either syntax decision in the end after getting used to it)

Re: No one should use the AT&T syntax (2021)

#36

Post by gergo_barany »

IshKebab wrote: post #29
kstenerud wrote: post #14

> 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 lan…

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 or dst it would just be obvious.

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

Re: No one should use the AT&T syntax (2021)

#37

Post by brianmurphy »

VWWHFSfQ wrote: post #8
irusensei wrote: post #5

Might suggest to change the title to specify this is about the Assembly language.

I'm curious if there's another "AT&T syntax" that would be confused with this? I always assumed was a very well-known assembly style.

I guessed it was about the (Hayes) AT Command Set for modems.

AT vs AT&T phone company and childhood memories.

(Clearly this was wrong after clicking into the article)

Re: No one should use the AT&T syntax (2021)

#38

Post by bawolff »

DonHopkins wrote: post #15
VWWHFSfQ wrote: post #8

Earlier quoted context omitted.

I'm curious if there's another "AT&T syntax" that would be confused with this? I always assumed was a very well-known assembly style.

AT&T: Local Analog Loopback Test The modem will perform the local analog loopback test if &T1 is selected. The test can be run only when in an asynchronous operation in non-error-correction mode (normal). To terminate the test in progress, the escape sequence must be entered first (see Section 3.1.1). If S18 is non-zero, the test will terminate automatically after the time specified by S18 and the OK result code will…

Is that a syntax? Would anyone be reasonably be confused by it?

Re: No one should use the AT&T syntax (2021)

#39

Post by amluto »

I think there are two legitimate reasons to use Intel syntax:

1. It matches the manual. AMD and Intel’s manuals agree about operand order, and IMO there is no justification whatsoever for an assembly syntax to fail to match the documentation. This is especially true for 3-address instructions and for two-input instructions like CMP.

All these arguments about mathematical notation or linguistics are nonsense in my book. The correct order for the operands of ADD is what the corresponding manual says.

2. Intel address syntax is so much better than AT&T’s that it’s not even funny.

Re: No one should use the AT&T syntax (2021)

#40

Post by Veserv »

kstenerud wrote: post #14

> 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 lan…

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.
Post reply on HN