The two extreme cases still existed in that era. One extreme was the DEC VAX. The instruction set is complex, convenient, high level, and slow. The other extreme was the original IBM 801, which led to the IBM POWER architecture. In its pure form, it was one instruction per clock, had lots of registers, and was quite simple. MIPS went down that road in a big way.<p>Then CISC microprocessors became superscalar, and started executing more than one instruction per clock. Now RISC machines were behind in speed. So they had to become superscalar. That killed the simplicity. There was no longer any real point to pure RISC instruction sets.<p>(The author mentions the Itanium. That existed mostly because Intel wanted a patentable technology others couldn't clone. It was very original, and not in a useful way.)
> [Editor's note: this example actually finds 20^4, not 20^3. I'll correct it when the load on the server goes down. Still, it serves its purpose.<p>I guess the load on the server has yet to abate for 24 years.
Dave Ditzel (mentioned in the article) is still involved with RISC architectures. His current company Esperanto is shipping a 1088 core RISC-V processor.<p><a href="https://www.youtube.com/watch?v=5foT3huJ_Gg">https://www.youtube.com/watch?v=5foT3huJ_Gg</a>
Interesting to see John conclude like me after reading Patterson that RISC vs CISC was always about a philosophical difference in how you approach chip design.<p>This is what I argue in this article as well but I reach a different conclusion from him and I think that is in large part because the rise of RISC-V has made the RISC and CISC distinction more relevant again.<p><a href="https://itnext.io/risc-vs-cisc-microprocessor-philosophy-in-2022-fa871861bc94" rel="nofollow">https://itnext.io/risc-vs-cisc-microprocessor-philosophy-in-...</a><p>When John wrote that article RISC processors had gotten very complex. Then it was a lot about complex address modes. But the last decades complexity stems more from lots of SIMD instructions.<p>RISC-V has aimed to reverse that trend and create å significantly smaller ISA. The RISC counter-trend to complexity is thus still alive and kicking.
During a recent conference I attended, a keynote speaker discussed their idea of having CPUs with at least 10,000 RISC-V cores and servers with one million RISC-V cores [1].<p>The idea is appealing, but how feasible is it and how does RISC make this possible or useful? I'm just curious what people think about this.<p>[1]: <a href="https://www.microarch.org/micro55/media/keynote_ditzel.pdf" rel="nofollow">https://www.microarch.org/micro55/media/keynote_ditzel.pdf</a>
>RISC architecture is gonna to change everything. -- Acid Burn<p>That line from the movie Hacker's elicited many "that didn't age well" comments in the years after the movie came out but ultimately proved to be correct. It just needed a long enough timeframe to happen.
I am curious. As I understand it, both RISC and CISC processors are implemented in microcode for the actual hardware gates on the chip. And perhaps different hardware generations make it easier to build different micro-code machine architectures.<p>So why not just offer an instruction set that matches the base hardware architecture? Rather than have all that decoding done on the chip, why not by a compiler? I understand that branch prediction can only be done at run time, but presumably there is some "closer to the metal" instruction set that would be faster than instruction decoding. Or is instruction decoding very low cost?
As more RISC and CISC architectures add more sets and extensions the more similar they become as they end up targeting each other's design challenges.<p>Which makes architecture moot.
It's a great submission, but please don't post archive links to HN when there's a live version of the original available. You're welcome to put the archive link in a comemnt; lots of people do that.<p>We changed the URL from <a href="https://web.archive.org/web/19991129051550/http://arstechnica.com/cpu/4q99/risc-cisc/rvc-1.html" rel="nofollow noreferrer">https://web.archive.org/web/19991129051550/http://arstechnic...</a>.