Not always, but the problem with CISC was that the complexity led to increased possibility of hardware bugs which were not possible to change as they were set in silicon. RISC was created to reduce the possibility of such bugs by making the instruction set as simple to implement in hardware as possible. That trade-off resulted in greater memory use (when memory was at a premium) along with being harder to program. Modern CPUs are hybrids, so that if there is a dodgy CISC instruction or a security flaw, it can be patched by microcode.
I thought that the point of RISC was to reduce the variable complexity of instructions, thus making them more amenable to pipelining, and keeping the common simple operations fast. Most RISC architectures have fixed-length instructions, simplifying the instruction fetching and decoding so it can run ahead and not have to interpret each instruction, for example.
Yeah, I'm with you. Namely an explicit separation of load/store operation from operations that operate purely on the register file. Also, and I don't know how incidental this was, allowing for more registers that most instructions could encode as operands, with fewer implicit operands. Thus reducing the frequency of loads and stores. All of this reflecting the fact that the register file is much more readily accessible than even cached memory, something that I believe was not always true. At some point CPUs weren't running that much faster than the memory, so it was less of a big deal to be accessing it all the time.
Such a luxury when e.g. doing a FIR and keeping all the coefficients in registers, or emulating a CPU and keeping them all in registers.
(post is archived)