> It seems like we ought to have switched from CISC to RISC.
If you ever have a question about computer architecture, ask two questions: 1) where does the memory bandwidth go, and 2) where does the die area go. All else follows from this.
RISC only made sense when CPU clock speeds were at rough parity with central memory speed, on-chip I-caches were limited, pipelines were short, and compilers were only good at modest optimizations.
If you look at functionality per instruction byte, RISC is fairly low. In today's world, CPU clocks are hugely faster than memory speeds, on-chip I-Caches are huge, pipelines are very very deep, branch prediction hardware is very good, and compiler back-ends are much much smarter than the peak days of RISC. CISC wins because the amount of functionality that you can move into the I-Cache per clock is higher and the amount of functionality you can keep in a given amount of I-Cache die area is higher, and compilers are good enough to target specialized instructions efficiently.
Is what Intel has crammed into X86 impressive? Yes, very. And it was damn hard work. I can tell you that walking all the way out to byte 15 of an instruction to look at the MOD R/M byte to decide if you have to raise an illegal instruction exception is a painful long path to squeeze under the clock constraint. But breaking backwards compatibility is just not something customers will put up with. So logic and circuit designers get to ply their trade in it's most convoluted form with the X86.
Perhaps these days I should amend my question list and add a third: 3) where does the power go? This is where ARM has an advantage over X86. The equations that you have to resolve to issue an X86 instruction are simply more complex than for ARM, and all that bit-flipping consumes power.