4 ms·
variable length instructions == CISC is not quite a correct equivalence. The compressed 'C' extention is designed to re-use a lot of the existing decode infras
by bunnie 3y ago
variable length instructions == CISC is not quite a correct equivalence.
The compressed 'C' extention is designed to re-use a lot of the existing decode infrastructure. On RV32 the C instructions are a strict subset of the full length instructions, so at least on RV32 it is very light weight, and it adds barely any logic to a core. It's almost always worth it to turn on C extensions versus making the cache bigger or trying to speed up main memory.
In my experience I-cache pressure is real, especially on lightweight implementations that don't have multiple levels of cache hierarchy and huge amounts of associativity to reduce the impact of an instruction cache miss.
I have played with both C and non-C variants, and also played with compiler tuning that saves code size versus 'performance' (which includes loop unrolling and thus more I cache misses). Generally smaller code size is better for power and system complexity, while keeping performance at par. Of course if you aren't as restricted on power or complexity (as is the case on a high end CPU), the calculus is different.
This kind of simplicity to me embodies the heart of RISC. If your CPU is hitting cache lines more often, you don't have to speculate as deep, don't have to re-order as much, thus less logic, less complexity, less power, higher clock rates and fewer side channels.
On the other hand, I suppose if you are already committed to deep speculation and out of order, compressed instructions might extract a disproportionate cost, maybe less so in decode and more so in precise exception handling and in tricks like register renaming.
- gchadwick 3y ago> variable length instructions == CISC is not quite a correct equivalence. Yeah I'd tend to agree, in particular x86 variable length encoding is a lot more complex than the RISC-V encoding! What I'm really getting at is CISC and RISC aren't well-defined things and it's interesting seeing how the design of RISC-V is getting pulled in different directions. > so at least on RV32 it is very light weight, and it adds barely any logic to a core. It's almost always worth it to turn on C extensions versus making the cache bigger or trying to speed up main memory. Definitely, and the Qualcomm proposals are that things should stay that way for RV32/low end in general. It's high-end RV64 they care about. > On the other hand, I suppose if you are already committed to deep speculation and out of order, compressed instructions might extract a disproportionate cost, maybe less so in decode and more so in precise exception handling and in tricks like register renaming. This is the root of it. It's easy enough to do a study demonstrating changes in static code size, also easy enough to build a low-end RISC-V processor and examine the trade-offs. It's all a lot more complex at the higher-end especially as high-end RISC-V cores are far from mature.
- o11c 3y agoReally, by a reasonable definition CISC was dead long before x86 became a thing. We don't even conceive of architectures where every instruction has 6 operands, including double indirection and implicit increments.
- Pet_Ant 3y ago> We don't even conceive of architectures where every instruction has 6 operands, including double indirection and implicit increments. Is this an exaggeration, or were there ever such ISAs?
- o11c 3y agoIt's a half-remembered description of VAX, but it's not much of an exaggeration if at all.
- Pet_Ant 3y agoFor those curious, I found this VAX manual, but haven't found anything truly egregious yet: https://www.ece.lsu.edu/ee4720/doc/vax.pdf https://www.ece.lsu.edu/ee4720/doc/vax.pdf
- brucehoult 3y agoMOVC6