6 ms·

> 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

by ketzu 2y ago

> 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 :)

pclmulqdq 2y ago
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.
- ketzu 2y ago
  > 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)
  - pclmulqdq 2y ago
    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] <- loads data at pointer in R0 into R3 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.
    - ketzu 2y ago
      > Careful, in C++ `abs(x) = y` is equally likely to put y into abs(x). I know, if it returned something it could write into, it would. .__. https://godbolt.org/z/7h6YMqbEW https://godbolt.org/z/7h6YMqbEW > 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] <- loads data at pointer in R0 into R3 That's really cool to know, my exposure to assembly is mostly limited to a little bit disassembly for all kinds of reasons (so mostly x86 reading) or 1 instance of inline assembly. Most of the other instances I worked with SSE intrinsics instead, so my knowledge is very limited. This thread was extremly interesting to read.
- AshamedCaptain 2y ago
  > 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.
  - pclmulqdq 2y ago
    All of them but x86 are obsolete. I don't know anyone who has written 68000 assembly for professional use in the last 20 years.
ralferoo 2y ago
I first learned assembler on Z80, and so the Intel syntax should be more natural to me, but I migrated from that to 68000 which uses destination-last syntax, and never really had any problems with it even though I'd been using Z80 for a few years by then. About a year after learning 68000, I started coding 8086 assembler and felt that Intel syntax was backwards, even though it's the same order as the Z80 I started on. Now it's been almost 2 decades since I wrote 68000 code, and I've drifted back to Intel syntax as the default, although I've always had a particular hatred for the square brackets for memory accesses. I remember being particularly disgusted by the DWORD PTR nonsense that the original MASM insisted on, and back in the day preferred a86 (no, not the Linux one, the old shareware DOS assembler from the late 80s) which had a much more sane syntax. AT&T syntax also pre-dated Intel syntax by several years, and was based on the PDP-11 assembler which had the destination last. Many UNIX vendors later moved to 68000 which also had the destination last (possibly influenced by AT&T syntax, as all their 8-bit processors embedded the destination in the opcode). Other chips like SPARC, which was developed by a UNIX vendor for a UNIX-like machines followed suit, probably because all their engineers were already using AT&T syntax anyway. As for the other arguments in the article, I think it's kind of fair to complain about the syntax, but also important to remember that as part of the GCC toolchain, the assembler was never really intended for humans to use, other than for short bits of glue code, but was instead really intended to just have enough functionality to assemble the output from cc1. When GCC was ported to Intel, it almost certainly made sense to keep AT&T syntax in gas because gcc developers were familiar with it, and the cc1 backend would probably have required extensive changes to output in a different order even though it wouldn't really benefit anyone because nobody was actually intended to read the intermediate .S file other than while debugging gcc itself. Obviously nowadays, cc1 directly outputs to .o and the -S flag is more for debug, and sometimes generates code that doesn't always exactly correspond to the generated code in the .o. But anyway, despite all that defence for why AT&T syntax, I agree, it's ugly and I always hate writing code with it. I almost always use an assembler that uses the chip vendor's preferred syntax on whatever platform I'm using, mostly because it's then easier to refer to documentation.
- pclmulqdq 2y ago
  If Intel allowed you to do "MOV RAX, [address]" (inferring the QWORD PTR part from the "RAX"), most peoples' primary aesthetic objection to the syntax would be gone.

by ketzu 2y ago

pclmulqdq 2y ago

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.

ketzu 2y ago
> 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)
- pclmulqdq 2y ago
  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] <- loads data at pointer in R0 into R3 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.
  - ketzu 2y ago
    > Careful, in C++ `abs(x) = y` is equally likely to put y into abs(x). I know, if it returned something it could write into, it would. .__. https://godbolt.org/z/7h6YMqbEW https://godbolt.org/z/7h6YMqbEW > 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] <- loads data at pointer in R0 into R3 That's really cool to know, my exposure to assembly is mostly limited to a little bit disassembly for all kinds of reasons (so mostly x86 reading) or 1 instance of inline assembly. Most of the other instances I worked with SSE intrinsics instead, so my knowledge is very limited. This thread was extremly interesting to read.
AshamedCaptain 2y ago
> 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.
- pclmulqdq 2y ago
  All of them but x86 are obsolete. I don't know anyone who has written 68000 assembly for professional use in the last 20 years.

ralferoo 2y ago

I first learned assembler on Z80, and so the Intel syntax should be more natural to me, but I migrated from that to 68000 which uses destination-last syntax, and never really had any problems with it even though I'd been using Z80 for a few years by then. About a year after learning 68000, I started coding 8086 assembler and felt that Intel syntax was backwards, even though it's the same order as the Z80 I started on. Now it's been almost 2 decades since I wrote 68000 code, and I've drifted back to Intel syntax as the default, although I've always had a particular hatred for the square brackets for memory accesses. I remember being particularly disgusted by the DWORD PTR nonsense that the original MASM insisted on, and back in the day preferred a86 (no, not the Linux one, the old shareware DOS assembler from the late 80s) which had a much more sane syntax. AT&T syntax also pre-dated Intel syntax by several years, and was based on the PDP-11 assembler which had the destination last. Many UNIX vendors later moved to 68000 which also had the destination last (possibly influenced by AT&T syntax, as all their 8-bit processors embedded the destination in the opcode). Other chips like SPARC, which was developed by a UNIX vendor for a UNIX-like machines followed suit, probably because all their engineers were already using AT&T syntax anyway. As for the other arguments in the article, I think it's kind of fair to complain about the syntax, but also important to remember that as part of the GCC toolchain, the assembler was never really intended for humans to use, other than for short bits of glue code, but was instead really intended to just have enough functionality to assemble the output from cc1. When GCC was ported to Intel, it almost certainly made sense to keep AT&T syntax in gas because gcc developers were familiar with it, and the cc1 backend would probably have required extensive changes to output in a different order even though it wouldn't really benefit anyone because nobody was actually intended to read the intermediate .S file other than while debugging gcc itself. Obviously nowadays, cc1 directly outputs to .o and the -S flag is more for debug, and sometimes generates code that doesn't always exactly correspond to the generated code in the .o. But anyway, despite all that defence for why AT&T syntax, I agree, it's ugly and I always hate writing code with it. I almost always use an assembler that uses the chip vendor's preferred syntax on whatever platform I'm using, mostly because it's then easier to refer to documentation.

pclmulqdq 2y ago
If Intel allowed you to do "MOV RAX, [address]" (inferring the QWORD PTR part from the "RAX"), most peoples' primary aesthetic objection to the syntax would be gone.