3 ms·
Back when the terms CISC and RISC came out they were terms for whole collections of traits that inevitably all came in one package or the other. But since the
by Symmetry 8y ago
Back when the terms CISC and RISC came out they were terms for whole collections of traits that inevitably all came in one package or the other. But since the 80s the world has become more complex. The coherent philosophy behind RISC has ceased to make sense for the highest end computers just as CISC had ceased to make sense for them when RISC rolled around.
We don't need to reduce the number of instructions to fit the whole processor on a single piece of silicon any more. With the decoupling of the processor and memory clocks and the introduction of caches load-store is a less pressing matter than it was. And the complexity of a processor is dominated by the fiendish complexity of executing operations out of order while still appearing in order to all outward appearances, even in the face of interrupts.
The legacy of these styles is still with us in the ISAs that were defined back then and the complexity of decoding an ISA can still make a small but noticeable difference. It can even have security implications when a sequence of bytes could be read as one of two valid instruction streams depending on where you start reading. But most of the architectural complexity of a modern processor has very little to do with the ISA and whether the architecture it was originally written for was RISC or CISC.
- jabl 8y ago> load-store is a less pressing matter than it was. I'd guess load-store with sufficient architectural registers is still an advantage if you're doing an in-order design, as that allows the compiler to schedule the load as early as possible? Sure, for an OoO design which splits a load-op into separate micro-ops this doesn't matter.
- Symmetry 8y agoYes, for in-order designs all the classic RISC benefits are much more relevant.