Earlier quoted context omitted.
Reminds me of a little quip in a 68000 programming language book I read a long time ago. Paraphrasing: "Upon executing HALT, the processor will stop, and nothing short of a reset will get it going again. Although threatening it with a hammer has been known to work on occasion, especially if it knows you've killed before."
And there will always be a customer that writes to support asking what size hammer should be used to test that parameter.
No one should use the AT&T syntax (2021)
91–100 of 112 posts
Re: No one should use the AT&T syntax (2021)
#92Earlier quoted context omitted.
> Because it's translated into a single machine instruction!!! Actually we never learned the x86 binary representation of instructions in that assembly language class. The textbook also did not cover that. All I wanted to say is: Intel syntax hides the fact that there are only 4 things in address calculation: displacement, base, index, scale. The compilation error is also hard to understand (at least for the compiler…
It's easy enough to learn "base + index*scale +- displacement". And it can be written in exactly that way, in whatever order makes the meaning of the code clearest, as you would do it in a higher level language. AT&T syntax forces you to learn this before writing or even reading a single line of code that references memory, instead of giving the illusion that maybe something like [eax+ebx+ecx] or [[eax]] was also all…
Well, you already know this requirement, so it is not a problem for you. However for learners, who don't have even the remotest idea of machine instructions, all they get is some invalid expression error messages. Same message for all (1) (2) and (3) cases I listed above.
Maybe Intel syntax works better for experienced programmers. But at least for me, when I was a newbie to assembly, AT&T was better than Intel syntax. It made learning process easier.
> AT&T syntax forces you to learn this before writing or even reading a single line of code that references memory
I do believe that rules forced by language is a good thing. At least it helped me understand why (1) (2) and (3) didn't work
Many people believe Rust can help people write safer code. Why? Because of its rules. Incorrect ownership will be discovered by the borrow checker so a compilation error will force the programmer to correct it.
Maybe an experienced C++ programmer will be able to handle memory management correctly in C++, and loves the extra freedom that C++ brings. But Rust can be helpful for learners. It provides clear error message helping them understand why their code is wrong. While in C++? Segmentation fault.
(Needless to say, Rust also helps experienced programmers. Even experienced programmers write buggy C++ code.)
Re: No one should use the AT&T syntax (2021)
#93Earlier quoted context omitted.
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.
The argument above applies neatly to assembly instructions, which generally change one thing.
Re: No one should use the AT&T syntax (2021)
#94I 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…
I found them to be very regular and understandable.
So when I encountered intel chips and their assembly syntax, I disliked them.
So about that time I switched to higher level languages.
Are there still chips left have a nice orthogonal assembly language? I vaguely recall 68k being orthogonal too.
Re: No one should use the AT&T syntax (2021)
#95Re: No one should use the AT&T syntax (2021)
#96I didn't really read the article, because/but I spent a minute or two playing with the cat. Nice little animation.
Re: No one should use the AT&T syntax (2021)
#97I 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…
Re: No one should use the AT&T syntax (2021)
#98As someone who has both written and read a lot of assembly in a professional context, my colleagues who are assembly writers very frequently prefer Intel syntax. The ones who are mostly (exclusively) readers seem to generally prefer AT&T. It is pretty undisputed that AT&T is easier for computers to parse, but it's also generally easier for humans to parse when reading it. * The suffixes give you a lot of easy specifi…
For me, it was exposure to M68k that made Intel syntax seem absolutely awful. AT&T syntax is also awful, but at least the operand order is the way that I'm (still) more used to.
Re: No one should use the AT&T syntax (2021)
#99Re: No one should use the AT&T syntax (2021)
#100> mov eax, ebx ; (1) load one dword from the EBX register and store it in the EAX register
Note how the comment says something entirely different than the assembler mnemonics ("load" instead of "move", and the source and target register in the comment are in different order than in the mnemonics).
My simple rule of thumb when I worked both on Z80 and 68k in the early 90s:
- LOAD dst WITH src
- MOVE src INTO dst
Intel syntax would make a lot more sense if it would use the Z80-style LD instead of MOV.
Not that I'm an AT&T syntax fan, but this one detail always bothered me. But I guess I should get used to it because ARM also got it "wrong" ;)