3 ms·

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

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.

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.