Comment by TapamN

Comment by TapamN 10 months ago

It's not really the addressing modes, but the instruction format. Immediate values on RISC-V are not stored contiguously on certain RISC-V instructions.

On all MIPS instructions, the bits for a immediate add, load constant, branch, etc value are always stored in order.

On RISC-V, the bits are (sometimes) jumbled around. For example, on a unconditional branch, the bits for the destination offset are stored in the order of bit 19, bits 9-0, bit 10, bits 18-11. In hardware, reordering that is free, you just run your wires the right way to decode it. In software, you have to do a ton of bit manipulation to fix it up.

The reason RISC-V does that is to simplify the hardware design.

Pet_Ant 10 months ago

Okay, so it's more about IMM representation within the bytecode rather than some memory addressing mode.

Reply View 12 replies

dmitrygr 10 months ago

Well, lack of REG+REG and REG+SHIFTED_REG addressing modes handicaps it significantly. And no, it will not get magically fused by magic fusing fairies in your cpu

Reply View | 11 replies
- kouteiheika 10 months ago
  
  > Well, lack of REG+REG and REG+SHIFTED_REG addressing modes handicaps it significantly.
  Does it? Well, there's a vendor specific extension for that (XTheadMemIdx):
  https://github.com/XUANTIE-RV/thead-extension-spec/releases/...
  Not sure about GCC, but on clang it is trivial to enable it. And if you really want to (assuming you have the hardware) you could compile exactly the same code with and without it and compare how much exactly it is handicapped if those instructions are not there.
  Plus, on RISC-V multiplication/division (about which you've complained) is optional, and there is also a variant of RISC-V with only 16 registers instead of 32 (also very simple to enable on recent versions of clang, although Linux would probably need some modifications to be able to run on that).
  So I'm not entirely convinced that RISC-V would be worse here.
  
  Reply View | 1 reply
  
  dmitrygr 10 months ago
  
  Lack of mul/div isn’t actually good. Having it be done ins guest code is a magnitude slower than is host code.
  My other issue was that there is NO working Linux user space for rv32. There is for rv64. No Debian. No Ubuntu. No anything for rv32
  
  Reply View | 0 replies
- snvzz 10 months ago
  
  >lack of REG+REG and REG+SHIFTED_REG addressing modes handicaps it significantly
  Is this a guess, or statistically supported on a body of empirical evidence like the RISC-V spec is?
  
  Reply View | 8 replies
  
  dmitrygr 10 months ago
  
  Compile same code for aarch64 and riscv64. Compare.
  It is well known design deficiency. Much like lack of bit field ops.
  
  Reply View | 7 replies