Hacker News Reader

Comment by Pet_Ant | Hacker News Reader

In the "Why MIPS?" section:

> some have shitty addressing modes necessitating that they would be slow (RISCV)

What is wrong with the RISC-V addressing modes?

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.

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

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

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

Compile same code for aarch64 and riscv64. Compare.

It is well known design deficiency. Much like lack of bit field ops.

Sounds extremely subjective.

i.e. it does not have my favored instructions or addressing modes, so it must be worse.

Much like juggling with your feet instead of hands is subjectively worse.

From 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)

I just meant that it's somewhat unergonomic when dealing with the instruction set directly, FWIW. Thanks for the reference.

You’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?

"well known design deficiency" is the subjective part.

Do you have code examples for this? I'm looking for cases where RISC-V is lacking compared to arm.

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

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

Probably nothing unless you want to emulate it on severely underpowered hardware.

Reply on news.ycombinator.com