x86 is not RISC by any meaningful definition. RISC vs CISC has always been about architecture, not microarchitecture. Breaking down instructions into microinstructions is as almost as old as the CPU itself and predates the CISC/RISC nomenclature by decades.
Many people describe the uOps inside a modern x86 as RISC-like and that's a good analogy. The internals really are much more similar to a RISC pipeline than older microcoded processors were. But it is still just an analogy because you're right about architecture versus microarchitecture.
but microcoding has existed for ever and while uops is probably a very specialized form of microcoding, it still not a new thing.
Also I do not think uops are fixed size as IIRC they can take a variable number of slots in the uop cache, and fix size instructions is pretty much one of the only two remaining differentiating RISC features. The internal x86 microarchitecture is also not load-store, the other one RISC feature, at least in the fused domain, and as far as I understand, in the uop cache.
So, even if we want to abuse the RISC term to describe the microarchitecture, I do not think it cleanly apply to the usual x86 implementations.
edit: this is a pet peeve of mine. It seems I have this discussion every 6 months on HN :)
Everything I've read about Intel uOps says that they're fixed size[1]. Now, the size isn't a power of 2 multiple of a byte like you'd see in a RISC design. I seem to recall some Intel architecture with 83 bit uOps? But it is fixed. And the uOp caches for both Intel and AMD are fixed size. Haswell stores 1.5k uOps[2] and Zen 2k[3] for instance.
But the important thing is that uOps are much higher level than microcode instructions. Except for the odd encoding size they would make a lot of sense as an early RISC ISA. Now, they expose a lot of the odd corner cases of the underlying architecture in a way that no modern ISA would but the original Berkeley RISC had branch delay slots and followed the philosophy that you'd just recompile the code when the ISA changes.
I'm at the edge of my knowledge here but I understand that microcoded instructions would tend to be much lower level, being things like read from memory to such and such an internal buffer. By contrast uOps do specify registers or constants, though they do so (post-rename) in terms of physical rather than architectural registers. But the decision on whether to get that arguments from the physical register or the bypass network is still made further down the pipe as with a RISC processor.
Is the analogy perfect? No, of course not. No analogy ever is. But I do think it illuminates more than it misleads for people learning about the evolution of processors - just as long as people can keep architecture and micro-architecture straight.
FWIW, Agner says that if a uop has multiple constants (for example an address and an immediate), it will borrow up to 32 bits from the next uop cache slot.
Encoding constants in the instructions themselves is a very non-RISC thing BTW.
> Many people describe the uOps inside a modern x86 as RISC-like and that's a good analogy.
Not really. Micro-Ops are typically very large (100+ bits wide) where each bit can be thought of as directly controlling a specific function in an EU. They can do things in parallel; the frontend may emit only one uop for more than one ISA instruction, they can contain constants, they're kinda-of variable-length in some microarchitectures. Overall they're very un-RISC-y.
Overall the whole RISC/CISC debate is pretty much meaningless and has been for decades. Many folks superimpose their own superstitions about unrelated issues (e.g. "PC server" vs "UNIX server" seems a popular one), but at the end of the day pretty much all high-performance cores look fairly similar, regardless of ISA.
Compared to other CISC CPUs designed at the same time as x86s (Vax, 68k, 32k, etc) x86s ARE positively RISCy - the instruction set (with 1 or two minor exceptions - push) only has instructions with 1 memory address making exceptions/restart (paging code) simple and making instructions easy to break into simple uOps (one trip to the TLB for protection checking - Vaxes used to potentially do 27 and guaranteeing that instructions could make progress in all situations was problematical)
