3 ms·

What is this "microcode" you speak of? "all those opcodes"? This post is about RISC-V. Also, in the near future, this is going to be the only optimised `memcpy

What is this "microcode" you speak of? "all those opcodes"? This post is about RISC-V. Also, in the near future, this is going to be the only optimised `memcpy()` you need on Applications-class (and many embedded too) RISC-V processors: memcpy: mv a3,a0 1: vsetvli a4, a2, e8,m4 # Vectors of bytes vle.v v0, (a1) # Load bytes add a1, a1, a4 # Bump pointer sub a2, a2, a4 # Decrement count vse.v v0, (a3) # Store bytes add a3, a3, a4 # Bump pointer bnez a2, 1b # Any more? ret

pjmlp 3y ago
It can be VHDL or Verliog for the ISA, if it makes you happier. So have you validated that Assembly example works the same way across all RISC-V vendors, and memory controllers, in regards to performace?
- brucehoult 3y ago
  All that exist at the moment! i.e. - THead C906 in-order single-issue core in e.g. AllWinner D1 and Bouffalo BL808 SoCs - THead C910 3-wide OoO core in THead TH1520 and Sophon SG2042 SoCs LMUL=4 (64 bytes per loop) is optimal for all the above. It is unlikely to be bad on anything. I look forward to the first shipping RVV 1.0 implementations, maybe sometime in 2024. The same code is binary compatible between RVV draft 0.7.1 (which the above implement) and the ratified RVV 1.0, and source compatible with the addition of ",ta,ma" to the `vsetvli` (sadly, a decision was made not to allow that to default in asm) As can be seen at... https://hoult.org/d1_memcpy.txt https://hoult.org/d1_memcpy.txt ... a test I ran on the Allwinner D1 two years ago. Compared to glibc memcpy() at the time, the vector version is 2-3 times faster for sizes up to 1k, then gradually slides back to equality at sizes in L2 cache and RAM where normal integer code can saturate the bus. That's a core (C906) which today is available on for example the $6 Pine64 Ox64 board.

pjmlp 3y ago

It can be VHDL or Verliog for the ISA, if it makes you happier. So have you validated that Assembly example works the same way across all RISC-V vendors, and memory controllers, in regards to performace?

brucehoult 3y ago
All that exist at the moment! i.e. - THead C906 in-order single-issue core in e.g. AllWinner D1 and Bouffalo BL808 SoCs - THead C910 3-wide OoO core in THead TH1520 and Sophon SG2042 SoCs LMUL=4 (64 bytes per loop) is optimal for all the above. It is unlikely to be bad on anything. I look forward to the first shipping RVV 1.0 implementations, maybe sometime in 2024. The same code is binary compatible between RVV draft 0.7.1 (which the above implement) and the ratified RVV 1.0, and source compatible with the addition of ",ta,ma" to the `vsetvli` (sadly, a decision was made not to allow that to default in asm) As can be seen at... https://hoult.org/d1_memcpy.txt https://hoult.org/d1_memcpy.txt ... a test I ran on the Allwinner D1 two years ago. Compared to glibc memcpy() at the time, the vector version is 2-3 times faster for sizes up to 1k, then gradually slides back to equality at sizes in L2 cache and RAM where normal integer code can saturate the bus. That's a core (C906) which today is available on for example the $6 Pine64 Ox64 board.