3 ms·

This of course utter nonsense. There's nothing different about the performance of compressed instructions.

adrian_b 5y ago
For competitive performance in 2021 with CPUs that can be used at performance levels at least as high as those required for mobile phones, it is necessary to decode simultaneously at least 8 instructions per clock cycle (actually more for RISC-V, because its instructions do less than those of other CPUs). The cost in area and power of a decoder for variable-length instructions increases faster with the number of simultaneously-decoded instructions than the cost of a decoder for fixed-length instructions. This makes the compressed instruction encoding incompatible with high-performance RISC V CPUs. For the lower performance required in microcontrollers, the compressed encoding is certainly needed for adequate code density. The goals of minimum code size and of maximum execution speed are contradictory and the right compromise is different for an embedded computer and for a personal computer. That is why ARM has different ISAs for the 2 domains and why also RISC-V designs must use different sets of extensions, depending on the application intended for them.
- serentty 5y ago
  8-wide is the absolute state of the art. Last I checked, AMD’s fastest core was 4-wide, and Intel’s was 6-wide. I only know of Apple doing 8-wide, and not anyone else. So branding this as the minimum necessary for mobile devices when even most desktops do not achieve it is silly.
- socialdemocrat 5y ago
  RISC-C compressed instructions cannot be compared to CISC variable length instructions. The instruction boundaries are easy to determine in parallel for multiple decoders. Something which is hard for e.g. x86. Compressed instructions don’t have arbitrary length. It is two instructions fitted in a 32-bit word. Decompression is part of the instruction decoding itself. It only requires a minuscule 400 logical gates to do. In fact RISC-V is very well designed for doing out-of-order execution of multiple instructions as instructions have been specifically designed to share as little state as possible. No status registers or conditional execution bits. Thus most instructions can run in separate pipelines without influencing each other.

For competitive performance in 2021 with CPUs that can be used at performance levels at least as high as those required for mobile phones, it is necessary to decode simultaneously at least 8 instructions per clock cycle (actually more for RISC-V, because its instructions do less than those of other CPUs). The cost in area and power of a decoder for variable-length instructions increases faster with the number of simultaneously-decoded instructions than the cost of a decoder for fixed-length instructions. This makes the compressed instruction encoding incompatible with high-performance RISC V CPUs. For the lower performance required in microcontrollers, the compressed encoding is certainly needed for adequate code density. The goals of minimum code size and of maximum execution speed are contradictory and the right compromise is different for an embedded computer and for a personal computer. That is why ARM has different ISAs for the 2 domains and why also RISC-V designs must use different sets of extensions, depending on the application intended for them.

serentty 5y ago
8-wide is the absolute state of the art. Last I checked, AMD’s fastest core was 4-wide, and Intel’s was 6-wide. I only know of Apple doing 8-wide, and not anyone else. So branding this as the minimum necessary for mobile devices when even most desktops do not achieve it is silly.
socialdemocrat 5y ago
RISC-C compressed instructions cannot be compared to CISC variable length instructions. The instruction boundaries are easy to determine in parallel for multiple decoders. Something which is hard for e.g. x86. Compressed instructions don’t have arbitrary length. It is two instructions fitted in a 32-bit word. Decompression is part of the instruction decoding itself. It only requires a minuscule 400 logical gates to do. In fact RISC-V is very well designed for doing out-of-order execution of multiple instructions as instructions have been specifically designed to share as little state as possible. No status registers or conditional execution bits. Thus most instructions can run in separate pipelines without influencing each other.