5 ms·
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
by TapamN 2y 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 2y agoOkay, so it's more about IMM representation within the bytecode rather than some memory addressing mode.
- dmitrygr 2y agoWell, 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
- snvzz 2y 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?
- dmitrygr 2y agoCompile same code for aarch64 and riscv64. Compare. It is well known design deficiency. Much like lack of bit field ops.
- camel-cdr 2y agoDo you have code examples for this? I'm looking for cases where RISC-V is lacking compared to arm.
- snvzz 2y agoSounds extremely subjective. i.e. it does not have my favored instructions or addressing modes, so it must be worse.
- smolder 2y agoMuch like juggling with your feet instead of hands is subjectively worse.
- snvzz 2y agoFrom a hardware perspective, juggling is better without flags and without unnecessary addressing modes. Neither are concepts RISC-V invented, but rather, adopted. Ideas that have been plenty tested out there, and proven beneficial. Large body of evidence trumps intuition and guesswork. Most of this is documented in the spec itself and/or in: Computer Architecture: A Quantitative Approach (John L. Hennessy, David A. Patterson)
- smolder 2y agoI just meant that it's somewhat unergonomic when dealing with the instruction set directly, FWIW. Thanks for the reference.
- jodrellblank 2y agoYou’re replying to the author of the post explaining why he would have to do more in software to emulate RISC-V than MIPS and that would be more effort and run slower, and you’re telling him “that’s extremely subjective”? How is that subjective?
- Dylan16807 2y ago
- kouteiheika 2y 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/tag/2.2.2 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.
- dmitrygr 2y agoLack 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