The use of AT&T syntax here is unfortunate. When the processor documentation and every single other toolchain out there uses a different syntax, you should use that syntax too.
EDIT: Would any of the people downvoting this comment care to explain their affection for this historical mistake? I have never understood why anyone would choose it.
> When the processor documentation and every single other toolchain out there uses a different syntax, you should use that syntax too.
All the GNU tools, and many of their clones, use AT&T syntax. I think I run into it more often than Intel, and I turn on the option for the latter where I can. It’s really prevalent.
There are certain things that exist only within University settings, but are almost unheard of in the Real World. So looking in from the outside, it's almost perverse.
As an example, scientific research papers were still being published in raw PostScript (PS) format long after PDF existed and become the defacto desktop publishing standard for 99.9% of the world outside of academia.
The use of AT&T assembler sticks out for me too, because I had learned Intel assembler back in the IBM XT days and wrote "demo" programs and all of that. And then my university used AT&T which was just so bizarre because literally 99% of the students had IBM compatible computers at home with Intel CPUs! Most of the lecturers had Intel PCs, most of the labs had Intel PCs, and it was just a handful of Solaris machines that had RISC CPUs and toolchains based on AT&T assembly.
Similarly, if you Google "Kerberos", an insane number of references pretend that this can only mean "MIT Kerberos", and is used for University lab PC authentication only. Meanwhile, in the real world, 99% of the Kerberos clients and servers out there are Microsoft Active Directory, and all configuration is done via highly available servers resolved via DNS, not static IP addresses.
Some design aspects of Linux and BSD have similar roots, and it shows. The DNS client in Linux is quite clearly designed for University campus networks. Combine this with typical University servers using hard-coded IP addresses for outbound comms, because of things like the Kerberos example above, and you get an end result that doesn't handle the requirements and failure modes of more general networks very well.
I do agree with you on this! I tried to follow the tutorial, but it is not easy for me to decipher the syntax without checking line by line. Maybe I'll come back to this eventually, but would prefer Intel syntax for readability..
As an example, when I first looked at AT&T syntax, I saw
movl 8(%ebx,%eax,2), %eax
What does the 8 mean? How does the stuff in the parenthesis work? Why is there a type suffix? Here’s a general definition of AT&T syntax’s indirect form
segment:offset(base,index,scale)
But the equivalent in Intel syntax (for the above two is):
it is just familiarity. Having learned asm reading GCC output and gdb disassembly, AT&T syntax is obvious to me and it takes me a bit to parse Intel syntax.
That makes sense, but for me when I started learning, Intel just made more sense: I could see which one was being multiplied by the scale, and what was being added; The indirect addressing syntax reads like algebra. AT&T, OTOH, just felt weird and inconsistent: Why is the offset on the outside of the parenthesis? Why are commas used?
The biggest thing for me is that the parameter order doesn’t follow the Intel or AMD opcode manuals; I have to flip the operands in my head to compare them to the opcode manual.
I’m not saying people are wrong for using AT&T syntax, or that it’s not intuitive for some. Just that Intel felt more intuitive to me.
Hmm. I just remember when the Intel assembler came out, thinking "whoa everything's backwards how irritating" so I guess ymmv. I'm guessing Stallman came from a pdp-11 background perhaps? The original (Ritchie) compiler emitted dec style pdp-11 assembler iirc.
Edit: realized that gcc first target was 68k so it would make sense for gas to use right way round assembler syntax.
I don't hate it because it's in src-dest order (though that does bother me). I hate it because it doesn't match the CPU. When you are actually programming something novel in assembly, you pretty much need to have the processor technical reference manual open, to be looking up those minute details that you can gloss over most of the time when reading disassembly, but which are so important to getting the most out of the processor when you're writing assembly. Or else you wouldn't be writing in assembly.
And it really, really bothers me when my tools do not match my documentation, for no good reason. (Just use the `-M intel` switch with x86 GNU tools, and then they will match. Or on ARM, do nothing, because by then they'd sensibly figured out not to bother with their "generic" syntax.)
When I ported my toy compiler backend from NASM macros to straight x86 instructions, as means to remove code I didn't own, I had this clever idea to use AT&T syntax because I wanted the compiler to depend only on GNU as and used the opportunity to try it out.
Never again, after all this years I still have vague memories of how I used TASM and MASM, and trying to write x86 AT&T was such a pain.
EDIT: Would any of the people downvoting this comment care to explain their affection for this historical mistake? I have never understood why anyone would choose it.