3 ms·

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 fr

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.