I never liked the syntax used by gas. It feels like something intended to be part of a C compiler, not like something you'd use for the joy of assembly language.
AT&T Syntax versus Intel Syntax (2001)
61–70 of 112 posts
Re: AT&T Syntax versus Intel Syntax (2001)
#62Similar thing also happens on 68k: Motorola syntax v.s. "MIT" syntax which is probably only used by GNU toolchain
Practically, 68k is far more usable in AT&T syntax than x86. When I used to do PalmPilot development, you could basically write standard 68k asm with just some extra %s sprinkled before registers and as would be fine with it. The x86 AT&T syntax is far more alien compared to the syntax in the official manuals, with arguments backward and nonstandard instruction names like addl and movabsq.
Re: AT&T Syntax versus Intel Syntax (2001)
#63Earlier quoted context omitted.
...math has no such order. Half the point of algebra is that the two sides of the equation are semantically equivalent and can be swapped at will.
Good luck convincing anyone that value = variable makes sense.
Some older C coding styles recommend that order because before compilers added warnings, “if (17 = variable)” resulted in a diagnostic, while “if (variable = 17)” would not. Nowadays, I think most programmers prefer putting the fastest-changing expression first.
Re: AT&T Syntax versus Intel Syntax (2001)
#64Earlier quoted context omitted.
Good luck convincing anyone that value = variable makes sense.
Some older C coding styles recommend that order because before compilers added warnings, “if (17 = variable)” resulted in a diagnostic, while “if (variable = 17)” would not. Nowadays, I think most programmers prefer putting the fastest-changing expression first.
[deleted]
Re: AT&T Syntax versus Intel Syntax (2001)
#65Earlier quoted context omitted.
Also the % before register names is completely unnecessary, it just another extra character to type.
It disambiguates labels from registers, assuming of course you allow labels to have register names. eg this is valid: mov rax,%rax rax: .ascii "hello\0" Stupid perhaps, but valid.
I wonder if it would have been more ergonomic to have the labels be % prefixed instead of registers.
Re: AT&T Syntax versus Intel Syntax (2001)
#66AT&T vs. Intel syntax has caused many arguments in some of my circles. AT&T is an atrocity and if you disagree... you're wrong. :)
op src dest is the logical order, the rest of the syntax I don’t care about much.
Which is my all memcpy-like functions in C/C++ standard library take arguments in dst, src order.
Re: AT&T Syntax versus Intel Syntax (2001)
#67Earlier quoted context omitted.
But English "add 4 to x" tells you nothing about where to store the result. : - ) "Add 4 to x and store result in x" vs "Let x be x + 4"?
Without any other context, you generally assume that the target is an accumulator. So "add 4 coins to that bucket", generally means at the end of that operation the bucket contains at least four coins plus any coins that were already in the bucket.
Huh, I think my brain is not wired to think about `x` as a storage, it is closer to "add 3 to x for x = 2", which then gets reduced to "add 3 to 2" and then the destination is missing...
Re: AT&T Syntax versus Intel Syntax (2001)
#68AT&T syntax is the most elite syntax. I've used it to write some famous hacks, like Actually Portable Executable, which is a 16-bit BIOS bootloader shell script ELF / Mach-O / PE executable. People dislike it because writing assembly Bell Labs style requires great responsibility. What makes AT&T syntax so powerful is its tight cooperation with the linker. I don't think it would have been possible for me to invent APE…
I’m sorry, no. This is incredibly misleading. Even if the linker step and assembly are completely separated, everything you’ve built in Cosmopolitan and APE is 100% buildable in other tools. It might take more effort in some cases, but there’s more to a native stack than choice of tooling and syntax; if you genuinely know your stack and architecture, anything is possible.
Your accomplishments have zero to do with the ‘elite’ tooling you use (why are you gatekeeping and creating class distinctions out of assemblers?), and more that you’ve taken the time to really think about how memory is laid out and how the architecture works - which most of us who started out writing operating systems instead of Rails understand perfectly fine. Nothing about the relationship between gas and ld achieves uniqueness not seen in other native stacks. That’s just made up.
There are multiple operating systems built with hand written NASM. Arguing about assemblers like they matter for more than five seconds is tiring 1990s IRC stuff. They turn syntax into a byte layout. It’s like realizing oh, this assembler sucks at ELF, why don’t I just hand lay one out? and boom, you’re on the way to APE. And really, if you don’t like your assembler, an “elite” programmer would write their own, but that fell out of fashion before most of us were alive.
Given the knowledge it takes to write something like APE I know you know what I’m saying, too, so why are you misleading like this? It comes across like an overstretched attempt to promote your work for a reader who knows the stuff you’re talking about.
Re: AT&T Syntax versus Intel Syntax (2001)
#69On Linux, is there a way to convert an assembly language file from one syntax to the other?
I know that there are ways to ask GCC to emit one syntax or the other, as well as ways to assemble code in either syntax. However I don't know any program that just translates one to the other.
Re: AT&T Syntax versus Intel Syntax (2001)
#70Earlier quoted context omitted.
Isn't this a function of the tools you were using, not the syntax? Couldn't any of these tools support any syntax and do the same thing?
The line between syntax and functionality is pretty thin for an assembler. I've definitely had code that some assemblers accepted and others didn't on the same arch, so even if they could be equally expressive in practice they aren't. Fairly sure that's also true of inline assembly on clang x64, had to change between intel and at&t for something a while ago.
Not really. Intel vs AT&T syntax is about how to generate machine code from mnemonics.
Cooperation with the linker comes with other directives and options. gas has tight cooperation with GNU ld via directives (which mostly are just implemented with ELF constructs AFAIK), not instruction syntax. It can actually be set to accept either AT&T or Intel syntax, without losing any support for other features.