The concern about the bits of immediate values being scattered around the instruction is overemphasized.
RISC-V instruction encodings are not pretty. It is difficult to believe that they are optimal for hardware decoding. More so, they show a flagrant contempt for compiler writers, debuggers, validation, JITs, emulators, and generally people who have to look at the instruction bits
Yes, it does take the implementor of a simulator a little longer to code up, but once that’s done, it is done. The concern about effort involved in shifting some bits around is way overblown.
I actually highly encourage the author to take an existing simple open-source RISC-V core and modify it to use this instruction encoding and implement both in FPGA and compare.
I am highly confident this modified version will 1) use a lot more LUTs, and 2) have a significantly lower FMAX.
I agree with this analysis.
As usual, people who do not understand RISC-V will try and reinvent the wheel, only to make it worse.
This fixes the worst bit of premature optimisation in the RISC-V encodings. The idea was that source operands should always be in the same place in the encoding so that you could do register fetch in parallel with decode. This stops being useful if any of the following is true:
You have an FPU (or anything else similar) and so need to decode to know which register file to fetch from.
You are implementing either the standard C extension or anything else that uses the variable-length encodings.
You are building a superscalar chip and so don’t want to do register fetch until you know which pipeline to send the values to (which happens past decode).
It basically benefits small microcontrollers at the expense of everything else. It causes all sorts of pain for toolchain because immediate fields are scattered across instructions. Worse, loads and stores do not have the same layout. This means that you need different relocations for the same addressing modes in loads and stores. This adds complexity in the compiler back end, the linker, the run-time linker, and everything else for no benefit.
The immediate operand encoding is especially terrible in the compressed instruction set, where there’s at least 10 different bit-shuffling formats used by different instructions..
Bruce Hoult didn’t think the redesign was well thought-out enough. His response:
https://old.reddit.com/r/asm/comments/14418lp/reencoding_riscv/jneaoda/
The concern about the bits of immediate values being scattered around the instruction is overemphasized.
Yes, it does take the implementor of a simulator a little longer to code up, but once that’s done, it is done. The concern about effort involved in shifting some bits around is way overblown.
I agree with this analysis.
As usual, people who do not understand RISC-V will try and reinvent the wheel, only to make it worse.
This fixes the worst bit of premature optimisation in the RISC-V encodings. The idea was that source operands should always be in the same place in the encoding so that you could do register fetch in parallel with decode. This stops being useful if any of the following is true:
It basically benefits small microcontrollers at the expense of everything else. It causes all sorts of pain for toolchain because immediate fields are scattered across instructions. Worse, loads and stores do not have the same layout. This means that you need different relocations for the same addressing modes in loads and stores. This adds complexity in the compiler back end, the linker, the run-time linker, and everything else for no benefit.
The immediate operand encoding is especially terrible in the compressed instruction set, where there’s at least 10 different bit-shuffling formats used by different instructions..