I've recently read the original RISC paper, "The Case for the Reduced Instruction Set Computer" by D.A. Patterson and I believe that most of the arguments he presents... are just false, as in, they don't hold, at least any more. His arguments for RISC are:
1) the memory speeds are increasing and approach those of the CPU ― that's definitely not true today;
2) code density is not as important because memory is faster and cheaper — again, memory may be cheap, but keeping icache full more important for the performance than ever;
3) designing and implementing CISC is difficult and takes long time — that's true... but designing and implementing a highly performant RISC is also quite difficult and takes a long time, and today the difference is mainly in the decoding stage: after it, its all RISC-like microinstructions in either case;
4) chip area used for complex instructions can be used for something better, like caches — is it really that true today? Does microcode for those take that much space, and if we consider the operation fusion (which happens on RISCs as well), is there even an advantage?
5) Complex instructions can be easily and more performantly simulated by combining several simpler ones — I would generally agree but... he took a very bad example for the unnecessary instruction, the VAX's INDEX instruction. Consider that we have CHERI project (which targets RISC-V as well) which is all about moving the finely-grained boundary checking back into the hardware again, this example has aged very poorly.
What remains is that RISCs are more pleasant to work with for the programmer, they would have less errors in their implementations due to their simplicity (which again, holds only for the most simplistic implementations), and they're faster (which they marginally are? Apples-to-apples comparisons here are not quite easy). The power-effectiveness, the actual advantage of RISCs, was not even considered back then, so the my final conclusion is... "right for the wrong reasons", I guess?
[0] https://inst.eecs.berkeley.edu/~n252/paper/RISC-patterson.pd...
1) the memory speeds are increasing and approach those of the CPU ― that's definitely not true today;
2) code density is not as important because memory is faster and cheaper — again, memory may be cheap, but keeping icache full more important for the performance than ever;
3) designing and implementing CISC is difficult and takes long time — that's true... but designing and implementing a highly performant RISC is also quite difficult and takes a long time, and today the difference is mainly in the decoding stage: after it, its all RISC-like microinstructions in either case;
4) chip area used for complex instructions can be used for something better, like caches — is it really that true today? Does microcode for those take that much space, and if we consider the operation fusion (which happens on RISCs as well), is there even an advantage?
5) Complex instructions can be easily and more performantly simulated by combining several simpler ones — I would generally agree but... he took a very bad example for the unnecessary instruction, the VAX's INDEX instruction. Consider that we have CHERI project (which targets RISC-V as well) which is all about moving the finely-grained boundary checking back into the hardware again, this example has aged very poorly.
What remains is that RISCs are more pleasant to work with for the programmer, they would have less errors in their implementations due to their simplicity (which again, holds only for the most simplistic implementations), and they're faster (which they marginally are? Apples-to-apples comparisons here are not quite easy). The power-effectiveness, the actual advantage of RISCs, was not even considered back then, so the my final conclusion is... "right for the wrong reasons", I guess?
[0] https://inst.eecs.berkeley.edu/~n252/paper/RISC-patterson.pd...