TASM Ideal mode was great.
No one should use the AT&T syntax (2021)
51–60 of 112 posts
Re: No one should use the AT&T syntax (2021)
#52I didn't really read the article, because/but I spent a minute or two playing with the cat. Nice little animation.
It used to be known as Oneko or Xneko, and chase your Windows or X11 desktop cursor. I once used it on both. Forcing it as a high-contrast distraction upon people who just want to read an article seems like it will discourage some of them. Discouraged people who nevertheless want to read the article, while using their pointing device to scroll, could add this to their uBlock Origin "My filters" tab: ||outerproduct.ne…
[deleted]
Re: No one should use the AT&T syntax (2021)
#53> 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…
> [src, dst] is closer to human language
In English, but not Telugu.
Re: No one should use the AT&T syntax (2021)
#54I 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 boo…
Don't forget the weirdness of AVX-512 masks in AT&T syntax!
Re: No one should use the AT&T syntax (2021)
#55Earlier 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.
> If you write for any CPU other than an x86
The at&t syntax didn't appear in a vacuum. There are several architectures, e.g. popularly m68k, which use this order.
Re: No one should use the AT&T syntax (2021)
#56> 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.
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)
Re: No one should use the AT&T syntax (2021)
#57Related:
AT&T syntax is broken (2021) - https://news.ycombinator.com/item?id=33652023 - Nov 2022 (44 comments)
Why no one should use the AT&T syntax ever - https://news.ycombinator.com/item?id=27089329 - May 2021 (8 comments)
Also:
AT&T Syntax versus Intel Syntax (2001) - https://news.ycombinator.com/item?id=33585154 - Nov 2022 (105 comments)
What was the original reason for the design of AT&T assembly syntax? (2017) - https://news.ycombinator.com/item?id=26127368 - Feb 2021 (58 comments)
Others?
Re: No one should use the AT&T syntax (2021)
#58I much prefer AT&T to intel syntax. i concede that cmp has the operand order swapped but otherwise i have to think less about it. Of course it's a matter of taste, but to me at least AT&T just feels nicer.
Re: No one should use the AT&T syntax (2021)
#59Earlier quoted context omitted.
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-sy…
Careful, in C++ `abs(x) = y` is equally likely to put y into abs(x).
Jokes about C++ aside, many DSPs with their own assembly languages have chosen to learn from C and higher level languages. The following style of syntax is not uncommon for DSPs (I am not using a specific one, but an abstract style), where writing assembly is expected:
R1 = R2 + R3;
R5 = R1 * R3;
R4 = POPCOUNT(R1);
R3 = [R0] Curiously, RISC-V didn't do this despite having the option to write their own new assembler. I guess the old opcodes die hard, but I also assume it has to do with LLVM strongly suggesting [OPCODE] [ARGS] syntax for assembly.
Re: No one should use the AT&T syntax (2021)
#60> 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…
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.