I am not entirely disagreeing, but there are some interesting things one can do with a CISC processor. Arguably code density can be higher on a CISC device. Y

I am not entirely disagreeing, but there are some interesting things one can do with a CISC processor. Arguably code density can be higher on a CISC device. You'll note that ARM has implemented basically code compression in their ISA with thumb. As for microcode on x86, most of the actual instructions running on the processor are pulled from L1 already translated. This used to be the trace cache, but after P4 that was dropped and now comes back as a u-op cache, meaning mostly that the instructions are stored in decoded format and so don't get run through translation again. (In P4's trace cache, branches were smashed and whole trace sequences up to three branches long were cached and then speculatively retrieved and executed.) Interestingly, there's research that shows you can spend plenty of time and gates to optimize the instructions as they come out of translation and go into the trace or u-op cache without negatively affecting performance, which allows some optimization basically for free. No one would do this these days because it's extra power and heat, but it was seriously considered back in the gigahertz wars. In addition, it should be noted that the translation between x86_64 and u-op is not super larger or challenging and is much much less challenging than most things we'd think about as a compiler pass. Decoupling internal architecture from externally exposed ISA is not an unreasonable choice, but x86 is certainly no longer a highly desirable external interface these days either. In a world where single thread performance isn't a significant differentiator, there's fewer reasons to use x86.