6 ms·

I've never liked this idea that x86 CPUs decode instructions into RISC form internally. Before there was RISC, before there was even x86, there were microcoded

I've never liked this idea that x86 CPUs decode instructions into RISC form internally. Before there was RISC, before there was even x86, there were microcoded instruction sets [1]. They were first implemented in Wilkes' 1958 EDSAC 2. Indeed the Patterson Ditzel paper even comments on this: Microprogrammed control allows the implementation of complex architectures more cost-effectively than hardwired control. [2] These horizontally microprogrammed instructions interpreted the architectural instruction set. The VAX 11/750 microcode control program had an interpreter loop. There could be more than 100 bits in these horizontal instructions with 30+ fields. Horizontally microprogrammed instructions were not in any way reduced. Indeed, reduction would mean paying the decode tax twice. There was another form, vertical microprogramming, which was closer to RISC. But there was no translation from complex to vertical. [1] https://www.cs.princeton.edu/courses/archive/fall10/cos375/BestWay.pdf https://www.cs.princeton.edu/courses/archive/fall10/cos375/B... [2] https://inst.eecs.berkeley.edu/~n252/paper/RISC-patterson.pdf https://inst.eecs.berkeley.edu/~n252/paper/RISC-patterson.pd...

fulafel 3y ago
Yep, and microcomputer processors were also microcoded. See eg 8086 here https://www.righto.com/2022/11/how-8086-processors-microcode-engine.html https://www.righto.com/2022/11/how-8086-processors-microcode... And current x86 still implement some instructions via microcode. Some are even performance sensitive (eg rep movsb)
- p_l 3y ago
  P6 architecture was always microcoded - it's even somewhat archetypical example of superscalar microcoded CISC. With quite horizontal microcode.
  - fulafel 3y ago
    Frontend decoding x86 instructions to uops, like from P6 onwards, is a bit different from microcode in the usual terminology. I guess you could make an argument that uops are also a type of microcode. But it gets confusing since there is also traditional ROM based microcode in post-P6 x86 chips.
    - p_l 3y ago
      I don't see much difference, except for the existence of variable length instructions making decode harder. Having fully hardwired decoder from macrocode to microinstruction was pretty normal for early microcoded architectures, because a simplest such decoder is to latch the opcode as part of ROM address with ROM output being a wide microinstruction. If you ensure the indexes are actually multiple microinstructions away from each other (for example, shift opcode to upper part of uOP program counter) you can easily map multiple uOPs when necessary without branching into more complex microcode.
Sparkyte 3y ago
I don't think I could articulate my concern as well as you. There is always some form of overhead when trying to translate instructions.
mort96 3y ago
The "CISC CPUs just decode instruction into RISC internally" thing is getting at something I think is important: RISCs and CISCs aren't necessarily that different internally. "CISC CPUs and RISC CPUs both just decode instructions into microcode and then execute that" is probably a more accurate but less "memeable" expression of that idea. What exactly we mean by "RISC" and "CISC" becomes important here. If, by RISC, we mean an architecture without complex addressing modes, then "CISCs are just RISCs with a fancy decoder" is wrong. But if we expand our definition of "RISC" to allow for complex addressing modes and stuff, but keep a vague upper limit on the "amount of stuff" the instruction can do, it's sort of more appropriate; the "CISCy" REPNZ SCASB instruction (basically a strlen-instruction) is certainly decoded into a loop of less complex instructions. I think the main issue with most of these discussions is in the very idea that there is such a thing as "RISC" and "CISC", when there's no such distinction. They are, at best, abstract philosophies around ISA design which describe a general preference for complex instructions vs simpler instructions, where even the terms "complex" and "simple" have very muddy definitions. TL;DR: I agree
- brucehoult 3y ago
  True RISC processors do NOT decode instructions into µops. The instructions ARE the microcode. This is true for all mainstream implementations of RISC-V, Alpha [1], and MIPS. To whatever extent a "RISC" core decodes (some) instructions into µops, it is deviating from RISC. ARM has always had mixed designs, marketed as "RISC". x86 is the least CISCy of the CISC ISAs. Except for the string instructions, it has only one memory operand in each instruction, and the addressing modes are simple with at most two registers (one scaled) plus a constant. In particular (unlike most CISC and indeed most pre-CISC/RISC ISAs) there is no indirect addressing. If you are looking at x86 as representative of CISC and ARM as representative of RISC and saying "there is hardly any difference" then 1) you are correct, and 2) you are looking a neither true CISC nor true RISC -- both of which do actually exist. [1] with one exception on some cores: cmov
  - hajile 3y ago
    In all but the most simple designs, you’re going to add LOTS of additional information specific to your uarch. For example, you need more bits internally for register remaining. Likewise, you need bits for hazards, synchronization, ordering, etc. Parts of the instruction will likely be dropped (eg, instruction length bits). It’s more accurate to say that there will be a 1-to-1 relationship between RISC-V instructions and uops, but there’s a push to perform fusion for some instructions, so even that may not actually be true either.

fulafel 3y ago

Yep, and microcomputer processors were also microcoded. See eg 8086 here https://www.righto.com/2022/11/how-8086-processors-microcode-engine.html https://www.righto.com/2022/11/how-8086-processors-microcode... And current x86 still implement some instructions via microcode. Some are even performance sensitive (eg rep movsb)

p_l 3y ago
P6 architecture was always microcoded - it's even somewhat archetypical example of superscalar microcoded CISC. With quite horizontal microcode.
- fulafel 3y ago
  Frontend decoding x86 instructions to uops, like from P6 onwards, is a bit different from microcode in the usual terminology. I guess you could make an argument that uops are also a type of microcode. But it gets confusing since there is also traditional ROM based microcode in post-P6 x86 chips.
  - p_l 3y ago
    I don't see much difference, except for the existence of variable length instructions making decode harder. Having fully hardwired decoder from macrocode to microinstruction was pretty normal for early microcoded architectures, because a simplest such decoder is to latch the opcode as part of ROM address with ROM output being a wide microinstruction. If you ensure the indexes are actually multiple microinstructions away from each other (for example, shift opcode to upper part of uOP program counter) you can easily map multiple uOPs when necessary without branching into more complex microcode.

Sparkyte 3y ago

I don't think I could articulate my concern as well as you. There is always some form of overhead when trying to translate instructions.

mort96 3y ago

The "CISC CPUs just decode instruction into RISC internally" thing is getting at something I think is important: RISCs and CISCs aren't necessarily that different internally. "CISC CPUs and RISC CPUs both just decode instructions into microcode and then execute that" is probably a more accurate but less "memeable" expression of that idea. What exactly we mean by "RISC" and "CISC" becomes important here. If, by RISC, we mean an architecture without complex addressing modes, then "CISCs are just RISCs with a fancy decoder" is wrong. But if we expand our definition of "RISC" to allow for complex addressing modes and stuff, but keep a vague upper limit on the "amount of stuff" the instruction can do, it's sort of more appropriate; the "CISCy" REPNZ SCASB instruction (basically a strlen-instruction) is certainly decoded into a loop of less complex instructions. I think the main issue with most of these discussions is in the very idea that there is such a thing as "RISC" and "CISC", when there's no such distinction. They are, at best, abstract philosophies around ISA design which describe a general preference for complex instructions vs simpler instructions, where even the terms "complex" and "simple" have very muddy definitions. TL;DR: I agree

brucehoult 3y ago
True RISC processors do NOT decode instructions into µops. The instructions ARE the microcode. This is true for all mainstream implementations of RISC-V, Alpha [1], and MIPS. To whatever extent a "RISC" core decodes (some) instructions into µops, it is deviating from RISC. ARM has always had mixed designs, marketed as "RISC". x86 is the least CISCy of the CISC ISAs. Except for the string instructions, it has only one memory operand in each instruction, and the addressing modes are simple with at most two registers (one scaled) plus a constant. In particular (unlike most CISC and indeed most pre-CISC/RISC ISAs) there is no indirect addressing. If you are looking at x86 as representative of CISC and ARM as representative of RISC and saying "there is hardly any difference" then 1) you are correct, and 2) you are looking a neither true CISC nor true RISC -- both of which do actually exist. [1] with one exception on some cores: cmov
- hajile 3y ago
  In all but the most simple designs, you’re going to add LOTS of additional information specific to your uarch. For example, you need more bits internally for register remaining. Likewise, you need bits for hazards, synchronization, ordering, etc. Parts of the instruction will likely be dropped (eg, instruction length bits). It’s more accurate to say that there will be a 1-to-1 relationship between RISC-V instructions and uops, but there’s a push to perform fusion for some instructions, so even that may not actually be true either.