4 ms·

> 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 high

by 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.

by ketzu 2y ago

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.