Why did RV64 introduce new opcodes for 32-bit operations instead of the 64-bit ones

Question

While going through the RISC-V Specification I've noticed that the 64-bit version differs from the 32-bit one in the fact, that it

1. Widened the registers to 64-bit
2. Changed the instructions to act on the whole 64-bit range.
3. Added new instruction to perform 32-bit operations

This makes RV32 code incompatible to RV64. However if the 64-bit version had been implemented by:

1. Widening the registers to 64-bit
2. Renaming ADD/SUB/SHL/.. to ADDW/SUBW/SHLW/.. and keep them operating only on 32-bit with sign extend.
3. Add new instructions ADD/SUB/SHL/.. or ADDD/SUBD/SHLD/.. to act on the full 64-bit

This would have allowed RV32 programs to run on RV64 as well. For implementing the CPU the effort would remain the same since in both cases the 64-bit and the 32-bit instructions would have to be implemented and only the opcodes for the 64-bit and the 32-bit versions would have been swapped in contrast to the specification. (Except maybe for the multiply instruction.)

So why did RISC-V decided to assign new opcodes to the 32-bit operations instead of to the 64-bit operations in RV64?

Catalysis

This is not atypical for this kind of IP. No real surprises here. The sad reality is being open then the chip vendors if/when they come will customize and we will have a massive compatibility nightmare with the RV32s not being compatible much less the RV64s or them with each other. That is assuming when the patent suits come, the first ones to have to fight survive. Possible that (one or) those survivors would be the only ones to make risc-v based chips. – Scheme

Treat each implementation of risc-v as a completely different processor, that is for the most part how you will need to get through this. – Scheme

For example look at aarch32 vs aarch64. – Scheme

Thanks a lot. I didn't looked at it that way. So basically the reason is that since it will be incompatible anyhow its just simpler to make things complicated by trying. – Catalysis

it can be done, look at x86, they went from 16 bit to 32 to 64 with the same instruction set, added stuff along the way no doubt but they did it, one might say it was the more painful path one might say it was the less painful. – Scheme

the risc-v is more like the xtensa or openrisc or others like that that are scalable, some might offer a compile with 8 registers or 16 or 32 and that means the instructions have to either leave room for the worst case or be dynamic to handle the different number of bits to describe registers. there are whole chunks of instructions that can come and go, etc, which is fine too, but the combinations start to get painful. – Scheme

not saying that arms choice was right or wrong nor rv32 vs rv64, but it happens, we cant expect a universal instruction set that meets everyones needs. If you and I were given a programming assignment would we choose the same language and come up with the exact same solution? Probably not, the instruction set designers have their own personal and professional reasons for doing things. the rest of us have to live with it. – Scheme

There is perhaps an opportunity here to take their RV32 source code and make a 64 bit derivative that is (more) RV32 compatible and post that somewhere. Kind of like AMD 64 bit vs Intel 64 bit... – Scheme

Questions as to why someone did something, why did you chose this variable name, why did you use this function call, why did you define these bits this way. Unless the person that did that is around, is just speculation. Why did Shakespeare have this character do that thing... – Scheme

I believe riscv64 should have nothing 32 bit et al. That it has 32 bit opcodes but on different hexa values, might be a bad compromise between the purists and the backward compatibility fans. – Quiche

Answer 1

The RV64 and RV32 are quite compatible. If the program don’t rely on implicit modulo 32-bit arithmetic and all addresses fit into 32-bit, the machine code could be the same. However it is very easy to add complete RV32 user mode to RV64 processor.

The 64-bit superset of RV32 would be too complicated. There are not enough opcode space for AUIPC, JAL, LOAD, STORE and BRANCH. It is worse with additional extensions.

The few 32-bit instructions in RV64 are mostly for programs overusing modulo 32-bit arithmetic. This is very common problem. The fast and portable code should avoid them, though.

Periodontics

So RV64 and RV32 are incompatible if the program rely on modulo 32-bit arithmetic? Those programs wouldn't be incompatible if the 32 bit functions were simply renamed. The question was why they weren't simply renamed? – Delicate

There are not enough opcode space to add additional functions. – Periodontics

Indeed there is limited OP code space for those instructions that accept some type of immediate. They also didn't want to go the path of flagging the register with the data width. I was thinking more of the lacking Register-Register operations like the OP, thus my mistake. As for those, I guess they wanted to be minimalist, at cost of the performance on memory constrained programs working with tons of 32-bit pointers/pseudo-pointers/lenghts, like suffix arrays or "riscv's x32" programs. – Delicate

The memory constrained programs can use RV32 user mode. – Periodontics