4 ms·

Does a "clean" vs. "messy" ISA really affect power utilisation more than low single digits? I can't see what the difference is outside the FE decoding. Perhap

Does a "clean" vs. "messy" ISA really affect power utilisation more than low single digits? I can't see what the difference is outside the FE decoding. Perhaps an ISA having more useful instructions would matter, as we would then be able to implement hardware optimisations. But just having poor ISA encoding or inconsistency seems, to my uneducated eyes, more of a human problem than a machine problem?

dkjaudyeqooe 3y ago
I think complexity always costs. You have to devote more gates to implementing it, more engineering, more area, and more power. People claim that there is no efficiency difference in ISAs, but why did Intel not implement a low power processor to compete with ARM, even when it had a process advantage? Maybe they could have pulled it off in terms of power budget but the implementation was too hard.
- Qwertious 3y ago
  >I think complexity always costs. You have to devote more gates to implementing it, more engineering, more area, and more power. Complexity also benefits - instead of having to do 12 different simple instruction, you can just do the one obscure instruction appropriate to the situation. The question is whether the actual perf benefits outweigh the costs, and the only correct answer to this is to actually measure what runs faster. Currently we don't have a decades-mature RISC-V chip, but ARM currently outperforms RISC-V massively so it's best to reserve judgement, and not make any hasty claims. Especially since people were claiming RISC would beat out CISC since at least the 90s, and yet three decades later CISC still dominates.
  - gary_0 3y ago
    > instead of having to do 12 different simple instruction, you can just do the one obscure instruction appropriate to the situation That one instruction just turns into 12 micro-ops, though, and then you need a much more complicated front-end to decode it. (And a smart enough compiler to use it in the first place.) You do benefit from higher code density, but when you compare real-world RISC and CISC code the size difference is arguably small enough that it's not worth it, especially when there are other improvements to spend resources on that provide more benefits, like better branch prediction. Also, instruction sets like ARM and RISC-V aren't needlessly minimalist, so you still get "extra" instructions such as vector/SIMD extensions where it makes sense. The old-school kitchen-sink instruction sets aren't popular any more for a reason.
  - brucehoult 3y ago
    > ARM currently outperforms RISC-V massively Only if you compare CPUs with vastly different microarchitectures e.g. a 4-wide OoO Arm and a single issue in-order RISC-V, or an Arm running SIMD code to a RISC-V CPU without SIMD/Vector. Arm has more advanced microarchitectures and Neon deployed in the field right at this moment, certainly, but RISC-V vendors have cores up to Cortex-X3 (SiFive) or even Zen/M1 level designed, simulated, and announced and those will all be in chips you can buy in 3-4 years. Comparing similar to similar e.g. SiFive U74 vs Arm A55 (on code not using Neon) you'll find very similar performance, and in my experience the U74 usually winning.
  - imtringued 3y ago
    Look I'm a fan of x86 processors for the high end, because the gap is just that large. But when you are building these MCUs, you actually want your transistor count to be as small as possible. These chips don't have anything complicated going on. They probably have a simple five stage pipeline with most of the transistors going into the minimum 32 general purpose registers, CSR registers and pipeline registers instead of actual logic.
brucehoult 3y ago
> 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.
imtringued 3y ago
>ISA really affect power utilisation more than low single digits? Your overall power consumption is already in milliwatts. Of course it matters. The fans on your desktop consume more power than these chips.

dkjaudyeqooe 3y ago

I think complexity always costs. You have to devote more gates to implementing it, more engineering, more area, and more power. People claim that there is no efficiency difference in ISAs, but why did Intel not implement a low power processor to compete with ARM, even when it had a process advantage? Maybe they could have pulled it off in terms of power budget but the implementation was too hard.

Qwertious 3y ago
>I think complexity always costs. You have to devote more gates to implementing it, more engineering, more area, and more power. Complexity also benefits - instead of having to do 12 different simple instruction, you can just do the one obscure instruction appropriate to the situation. The question is whether the actual perf benefits outweigh the costs, and the only correct answer to this is to actually measure what runs faster. Currently we don't have a decades-mature RISC-V chip, but ARM currently outperforms RISC-V massively so it's best to reserve judgement, and not make any hasty claims. Especially since people were claiming RISC would beat out CISC since at least the 90s, and yet three decades later CISC still dominates.
- gary_0 3y ago
  > instead of having to do 12 different simple instruction, you can just do the one obscure instruction appropriate to the situation That one instruction just turns into 12 micro-ops, though, and then you need a much more complicated front-end to decode it. (And a smart enough compiler to use it in the first place.) You do benefit from higher code density, but when you compare real-world RISC and CISC code the size difference is arguably small enough that it's not worth it, especially when there are other improvements to spend resources on that provide more benefits, like better branch prediction. Also, instruction sets like ARM and RISC-V aren't needlessly minimalist, so you still get "extra" instructions such as vector/SIMD extensions where it makes sense. The old-school kitchen-sink instruction sets aren't popular any more for a reason.
- brucehoult 3y ago
  > ARM currently outperforms RISC-V massively Only if you compare CPUs with vastly different microarchitectures e.g. a 4-wide OoO Arm and a single issue in-order RISC-V, or an Arm running SIMD code to a RISC-V CPU without SIMD/Vector. Arm has more advanced microarchitectures and Neon deployed in the field right at this moment, certainly, but RISC-V vendors have cores up to Cortex-X3 (SiFive) or even Zen/M1 level designed, simulated, and announced and those will all be in chips you can buy in 3-4 years. Comparing similar to similar e.g. SiFive U74 vs Arm A55 (on code not using Neon) you'll find very similar performance, and in my experience the U74 usually winning.
- imtringued 3y ago
  Look I'm a fan of x86 processors for the high end, because the gap is just that large. But when you are building these MCUs, you actually want your transistor count to be as small as possible. These chips don't have anything complicated going on. They probably have a simple five stage pipeline with most of the transistors going into the minimum 32 general purpose registers, CSR registers and pipeline registers instead of actual logic.

brucehoult 3y ago

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

imtringued 3y ago

>ISA really affect power utilisation more than low single digits? Your overall power consumption is already in milliwatts. Of course it matters. The fans on your desktop consume more power than these chips.