4 ms·
Implementing a CPU by writing an interpreter in lower level microcode is a obvious implementation strategy for CISC ISAs. But the mechanism how modern OoO x86 C
by dfox 4y ago
Implementing a CPU by writing an interpreter in lower level microcode is a obvious implementation strategy for CISC ISAs. But the mechanism how modern OoO x86 CPUs (and even many notionally RISC CPUs) works is different: The incoming instruction stream is converted into internal “more RISC” uOps and these are then executed by the OoO pipeline, this happens almost entirely in hardware (and on current x86 implementations with somewhat incredible amount of parallelism) and can in fact even combine multiple instructions into one uOp (or even completely discard an instruction). There is usually some microcode, but this is there to handle instructions that cannot be efficiently mapped to block of the uOps (too much work done in one instruction, interestingly ARM has bunch of such cases) and to handle interrupt and exception handling.
- aidenn0 4y agoSomeone observed to me once that the dominance of ARM has proven both the CISC and RISC sides wrong as ARM has fairly intermediate complexity instructions.
- kimixa 4y agoI've generally heard that the two major successful architectures today are the most complex RISC in ARM, and the most simple CISC in x86.
- panick21_ 4y agoThe reality is that ISA generally don't win because of technical merits. Business models and historical accidents have far more to do with it.
- Taniwha 4y agoActually I've previously made the same claim about the x86 .... I'd argue that of all its generation of CISCS (vax/68k/32K/etc) it was the most RISCy (apart from the microcoded segment crud) almost all it's instructions make at most a single memory reference (push/pop are the exceptions) and so are trivially restartable if there's a TLB fault (look at the CRUD! a 68020 throws on the stack, a vax could touch something like 20 pages in one poly instruction) - x86 has no indirect addressing modes, few side effects (no auto increment/decrement except for push/pop) I think that this is one of the reasons why x86 is still with us, it's relatively easy to decompose an x86 instruction into RISCy uops and do OoO/etc
- userbinator 3y agoThere is usually some microcode, but this is there to handle instructions that cannot be efficiently mapped to block of the uOps I believe the microcode is actually used to generate uops which go into the OoO pipeline too, for when there's too many uops for the decoder to generate directly.