>And the baroque instruction encoding on the x86 is actually a _good_
>thing: it's a rather dense encoding, which means that you win on icache.
>It's a bit hard to decode, but who cares? Existing chips do well at
>decoding, and thanks to the icache win they tend to perform better - and
>they load faster too (which is important - you can make your CPU have
>big caches, but _nothing_ saves you from the cold-cache costs).
>The low register count isn't an issue when you code in any high-level
>language, and it has actually forced x86 implementors to do a hell of a
>lot better job than the competition when it comes to memory loads and
>stores - which helps in general. While the RISC people were off trying
>to optimize their compilers to generate loops that used all 32 registers
>efficiently, the x86 implementors instead made the chip run fast on
>varied loads and used tons of register renaming hardware (and looking at
>_memory_ renaming too).
And that's true. ARM folks found out that while ARM is nice and great for low-performance low-power computing, you really need to do all sorts of tricks x86 does once you want to move to high-performance computing. Large register file does not give you much in that case.