> I can't see what the difference is outside the FE decoding.
In a sufficiently small CPU, the instruction decoder becomes a very significant proportion of the whole thing.
As an example of this consider the SeRV bit-serial RV32I core, which on a Xilinx FPGA uses 125 LUTs (most simple RISC-V cores use 1000-2000).
QeRV was just introduced, with a 4-bit wide data path and ALU instead of 1-bit wide. It increases speed by 3x while increasing the LUT count by 15%.
Clearly, instruction fetch / decode / control was totally dominating the data path. And still is on QeRV.
A couple of obvious RISC-V instruction decoding advantages over any of Arm's ISAs:
- src and dst registers are always encoded in the same bits in RISC-V but not in Arm. e.g. in A32 all data processing instructions have Rd in bits 15:12, except MUL & MULA put Rd in bits 19:16, and STR and other store instructions (which don't have an Rd) use bits 15:12 for the src register whose contents are to be stored. This seems trivial, but it adds significant extra muxes and wiring on a small design.
- It's the same in T16 (and the 16-bit opcodes in T32) which usually has Rd in bits 2:0, except the store instructions use those bits for a src register, and SP-relative load/store and "load address" (add a constant to SP or PC) have the Rd (again a src for store) in bits 10:8. So this hits Arm's smallest Cortex-M0 core.
- RISC-V uses slightly funky encodings for constants/offsets of varying sizes (including LUI and AUIPC, which encode bits 31:12, and conditional and unconditional branches, which do not encode bit 0) which minimises the number of places in the instruction that bits in the final 32 bit constant come from. This adds a couple of lines of code to assemblers and disassemblers, and makes it harder for humans trying to encode or decode binary instructions (mostly branch offsets), but considerably simplifies the muxes and wiring in the instruction decoder.
T16 also simply has a lot of instruction formats (19) and instructions (close to 90?) compared to RV32I's 4 formats (6 counting the different offset encoding for branch instructions, but src/dst/opcode etc are in the same places) and 37 instructions.
RISC-V's "C" extension (16 bit opcodes) adds nine more instruction formats, but that's optional and on a very small CPU core in an application with not much program code you can choose to not implement it.
In a sufficiently small CPU, the instruction decoder becomes a very significant proportion of the whole thing.
As an example of this consider the SeRV bit-serial RV32I core, which on a Xilinx FPGA uses 125 LUTs (most simple RISC-V cores use 1000-2000).
QeRV was just introduced, with a 4-bit wide data path and ALU instead of 1-bit wide. It increases speed by 3x while increasing the LUT count by 15%.
Clearly, instruction fetch / decode / control was totally dominating the data path. And still is on QeRV.
A couple of obvious RISC-V instruction decoding advantages over any of Arm's ISAs:
- src and dst registers are always encoded in the same bits in RISC-V but not in Arm. e.g. in A32 all data processing instructions have Rd in bits 15:12, except MUL & MULA put Rd in bits 19:16, and STR and other store instructions (which don't have an Rd) use bits 15:12 for the src register whose contents are to be stored. This seems trivial, but it adds significant extra muxes and wiring on a small design.
- It's the same in T16 (and the 16-bit opcodes in T32) which usually has Rd in bits 2:0, except the store instructions use those bits for a src register, and SP-relative load/store and "load address" (add a constant to SP or PC) have the Rd (again a src for store) in bits 10:8. So this hits Arm's smallest Cortex-M0 core.
- RISC-V uses slightly funky encodings for constants/offsets of varying sizes (including LUI and AUIPC, which encode bits 31:12, and conditional and unconditional branches, which do not encode bit 0) which minimises the number of places in the instruction that bits in the final 32 bit constant come from. This adds a couple of lines of code to assemblers and disassemblers, and makes it harder for humans trying to encode or decode binary instructions (mostly branch offsets), but considerably simplifies the muxes and wiring in the instruction decoder.
T16 also simply has a lot of instruction formats (19) and instructions (close to 90?) compared to RV32I's 4 formats (6 counting the different offset encoding for branch instructions, but src/dst/opcode etc are in the same places) and 37 instructions.
RISC-V's "C" extension (16 bit opcodes) adds nine more instruction formats, but that's optional and on a very small CPU core in an application with not much program code you can choose to not implement it.