15

In the earlier days of microprocessors instructions were hard-wired, i.e. a particular instruction triggered circuitry that was mostly (if not completely) implemented for that instruction. I believe somewhere in the late 1980s or early 1990s the x86 architecture migrated to being more of a RISC core that had its legacy CISC instruction set implemented on top of it.

I want to say that this was first with the Pentium Pro (i686 circa 1995) but at the same time I think it might have been earlier.

What was the last x86 processor from any vendor that was hard-wired and wasn't actually a CISC implementation on a RISC core?

13
  • 27
    Even the original 8086 had microcode… <reenigne.org/blog/8086-microcode-disassembled> Dec 6, 2022 at 17:47
  • 2
    I am very interested in this topic. Does microcode work similar to programming an FPGA?
    – zomega
    Dec 6, 2022 at 17:48
  • 5
    And the whole ‘RISC-in-CISC’ spiel is mostly a marketing ploy. Both terms have just become diluted into meaninglessness. What is ‘CISC implementation on a RISC core’ supposed to mean? Dec 6, 2022 at 17:54
  • 4
    @zomega Does microcode work similar to programming an FPGA? No. It works similarly to writing an emulator. There is some hardware implementing architecture A, running programs that implement architecture B. Of course, when it's microcode, 'A' is carefully designed to allow for efficient and effective emulation of 'B'. (This is more a description of vertical microcode than of horizontal microcode) Dec 6, 2022 at 18:49
  • 4
    @user3840170 it means that complicated opcodes are broken down into multiple “micro-ops”. Those micro-ops are typically fixed-length. The opcode-to-microop translation layer takes up quite a lot of chip real estate on x86 and x64 CPUs.
    – RonJohn
    Dec 6, 2022 at 18:55

4 Answers 4

48

The original 8086 was microcoded; x86 has never been hard-wired.

The P6 microarchitecture, first seen in the Pentium Pro, was the first Intel design to buffer a RISC-esque translation of the x86 stream though the Nx586 had done so earlier.

1
  • 8
    The closest to fully hard-wired may have been 486 or P5 Pentium; pipelined with parallel decode so that must be hardware, not just microcode. But unable to break up an instruction like add [eax], ecx into separate load/ALU/store operations, meaning that compilers optimizing for 586 would tend to prefer the RISC-like subset of x86, avoiding memory-destination or even memory-source instructions. (agner.org/optimize) Dec 7, 2022 at 15:32
32

All x86 CPUs have always used microcode.

Since the i486, the simplest and most used instructions are directly decoded without passing through the microcode ROM, which would have incurred additional delay. But there is still a microcode ROM for all the other instructions, and all the complex operations such as call gates, interrupts, ... The x87 FPU, which used to be a separate chip, is now integrated but still have its own separate microcode for complex math operations (trigonometric, exponentials...).

The i486 was also the first that Intel claimed had a RISC inside, because it had a full pipeline and could execute many instructions in 1 cycle, like contemporaneous RISCs. It was mostly marketing.

Later models, starting mainly with the Pentium Pro, split instructions into one or several elementary micro-ops that could be scheduled out-of-order.

I don't like that claim that there is a RISC inside x86 CPUs since the Pentium, because it's largely misleading. RISC and CISC are about instruction sets, not the internal microarchitecture. All CISC CPUs have always split complex operations into series of elementary steps, represented by fixed patterns in microcode ROMs. Using pipelines is not exclusive to RISCs either. Scheduling independant elementary operations is needed in all modern OoO CPUs, whatever the instruction set.

2
  • There was an article I recently read (was posted on Hacker News) that said "Out-Of-Order" is the next paradigm after RISC--so you have CISC, RISC, and OoO, and it was an interesting perspective. x86 is not RISCy as far as the instruction set, but AArch64 isn't really anymore either.
    – LawrenceC
    Dec 10, 2022 at 0:14
  • @LawrenceC. Didn't see that article, but it seems to mix instruction sets with microarchitecture. It's wrong. The two are quite independant. There are RISC, CISC, VLIV / DSP... instruction sets. There are sequential, pipelined, superscalar, in-order, Tomasulo, dataflow out of order... microarchitectures. For example it is possible to make a RISC-V CPUs with microcode and no pipelline. It will be very slow, but very small. There are actually a few examples of that on github, for FPGAs synthesis.
    – TEMLIB
    Dec 10, 2022 at 15:07
25

TL;DR: Already the very first 8086 was microcode based.


In the earlier days of microprocessors instructions were hard-wired

Yes, but ...

Even early microprocessors, like the Z80, 6800 and 6500, live in a gray area between pure random logic and a school book microcode engine. There are good arguments to see the 6502 PLA as a compressed microcode stepped thru by a sequencer.

The the 8086 in contrast was a very classic microcoded implementation. Same way for Motorolas 68,000. In fact, of the late 1970s 16 bit 'revolution', only the Z8000 was random logic based.

The 8086 microcode has been decoded and described in good detail by Andrew Jenner in 2020. Just a week ago Ken Shirriff added an in depth description of the microcode hardware and its workings.

I believe somewhere in the late 1980s or early 1990s the x86 architecture migrated to being more of a RISC core that had its legacy CISC instruction set implemented on top of it.

Not really. Beside that the whole RISC vs. CISC distinction is way less clear than some may put it, the whole notion of 'CISC to RISC' translation is marketing humbug.

Let's just take it serious for a minute: Wouldn't you agree that it could mean something like:

  • Read some 'complex' instruction from memory
  • Turn it into a sequence of one or more simple instructions
  • Execute that sequence on a 'core' that only understands those simple instructions

Right?

Well, that's the exact description of a microprogram.

Reordering that sequence according to available resources doesn't change it, not even if that is done across borders of fetched instructions. After all, every pipeline long enough will do so even without translation into a micro program. It does create any way of RISCyness.

What was the last x86 processor that was hard-wired and wasn't actually a CISC implementation on a RISC core?

In fact, and if at all, later CPUs reversed that to some extend by adding more dedicated hardware to reduce micro code. The NEC V20, makes an extraordinary example. And that's the essential part behind the CISC/RISC buzzword disguise: later CPUs added hardware to improve certain aspects, from dedicated units, like multipliers and barrel shifter all the way to out of order execution and parallel units.

Except, all of that is hard to sell to non techies, in contrast, telling that x86 now incorporates the buzz of the day (which RISC was) is an easy one.

2
  • @njuffa Isn't the difference just that in 'older' implementation the micro-ops get executed in sequence, while later 'newer' handle them as reorderable data? So kind of execute from ROM vs. Execute from RAM? After all, it does not change the principle if that data is wide (one bit per component) or encoded (a group of bits noting the component in question). That's only a measure to reduce size, not workings.
    – Raffzahn
    Dec 9, 2022 at 18:24
  • @njuffa ROM vs. RAM in context of fixed execution vs. variable reordering. Also, all of what you name is about interpretation. Or where is the fundamental difference between three bits that say "select A, select !B, select CY=CF" or an arbitrary bit combination that gets decoded to do the same? In my book only a layer of encoding and decoding used to reduce intermediate words size. the meaning is exactly the same. After all, the very existence of micro-ops is to set a certain state. It doesn't matter how they are created or forwarded.
    – Raffzahn
    Dec 9, 2022 at 21:09
2

The NEC V33 and NEC V53 were hardwired processors, and software-compatible with the Intel 8086. From what I can tell, these processors first came out in 1990, well after newer x86 processors came out. The earlier and later processor designs all used microcode.

1
  • Presumably NEC's reaction to the lawsuit Intel had filed regarding the V30: " August 1, 1988 -- Hearings in the Intel Corp lawsuit against NEC Corp, in which the San Jose chipmaker alleges that NEC infringed its copyright in the code that makes up the microcode of the 8086 and 8088 chips when designing the NEC V30 and V20 microprocessors, ended on Friday, and Judge William Gray said he would issue a ruling later this year, sometime after he returns from his vacation. [...]"
    – njuffa
    Dec 27, 2022 at 1:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .