Back when this debate was happening CPU design teams were a lot smaller, meaning that any given feature hadn't had enough effort put into it to get as far into the realm of diminishing returns, so there was a much bigger payoff to be had in reducing the number of features you implemented.
You also weren't devoting most of your die to huge arrays of cache, so adding - say - more addressing modes would tend to mean you couldn't have as many pipeline stages. Any given feature will still make the overall design more complicated and so will make it more difficult to add any other feature you want, but the issue isn't as pressing as it used to be.
One area where RISC does still has a big advantage is instruction decode. When you run into an x86 instruction you have to read a lot of bits to figure out how long it is, and its not self synchronizing so you could read an instruction stream one way if you start at byte FOO, but if you start at byte FOO+1 you can find an entirely different but equally valid sequence of instructions.[1] So decoding N bytes of x86 instructions grows in complexity faster than linearly. In fact, I suspect that modern processors have to use some sort of "Guess the three most likely solutions throw out the results if we're wrong" solution for current processors to get the performance needed.
If I were to design an ISA I'd probably want some sort of UTF-8 style variable length scheme, where you can always tell where an instruction boundary is without reading from the beginning but with the space savings from having the most common instructions be shorter than the least common ones.
[1] This apparently also annoys my security researcher friend.
> In fact, I suspect that modern processors have to use some sort of "Guess the three most likely solutions throw out the results if we're wrong" solution for current processors to get the performance needed.
IIRC, it's way more sophisticated than that.
As I understand Intel's trace caches, their guess is basically the result of decoding the next N instructions, accounting for branch prediction.
And yes, it includes detection/recovery for writes into the instruction memory that would invalidate that guess.
Back when this debate was happening CPU design teams were a lot smaller, meaning that any given feature hadn't had enough effort put into it to get as far into the realm of diminishing returns, so there was a much bigger payoff to be had in reducing the number of features you implemented.
You also weren't devoting most of your die to huge arrays of cache, so adding - say - more addressing modes would tend to mean you couldn't have as many pipeline stages. Any given feature will still make the overall design more complicated and so will make it more difficult to add any other feature you want, but the issue isn't as pressing as it used to be.
One area where RISC does still has a big advantage is instruction decode. When you run into an x86 instruction you have to read a lot of bits to figure out how long it is, and its not self synchronizing so you could read an instruction stream one way if you start at byte FOO, but if you start at byte FOO+1 you can find an entirely different but equally valid sequence of instructions.[1] So decoding N bytes of x86 instructions grows in complexity faster than linearly. In fact, I suspect that modern processors have to use some sort of "Guess the three most likely solutions throw out the results if we're wrong" solution for current processors to get the performance needed.
If I were to design an ISA I'd probably want some sort of UTF-8 style variable length scheme, where you can always tell where an instruction boundary is without reading from the beginning but with the space savings from having the most common instructions be shorter than the least common ones.
[1] This apparently also annoys my security researcher friend.
EDIT: Found the link to that really good explanation Mashey had on RISC vs. CISC: http://userpages.umbc.edu/~vijay/mashey.on.risc.html