A look at the die of the 8086 processor (2020)
righto.com
righto.com
If you look at a die shot of the 6502, for example, you will see an area that looks confusingly similar to where microcode would be stored. Turns out, this is a PLA, not a microcode store. The best quick intro to microcoding that I have encountered is https://people.cs.clemson.edu/~mark/uprog.html.
1. https://www.reenigne.org/blog/8086-microcode-disassembled/
Both ROMs and PLAs have a regular array structure, where you can change the stored bits with some minor changes in one of the masks, without having to make any changes in the layout of the CPU.
So the most useful definition of whether an instruction is micro-programmed or hard-wired is whether the method of changing what it does is by changing just the values of some bits in a table or by redesigning some CPU part.
This is the right definition from the point of view of the CPU designer.
Application programmers tend to partition the instructions of the modern CPUs in hard-wired and micro-programmed based on whether they execute in a single clock cycle or in multiple clock cycles, but in old CPUs it was quite frequent to have hard-wired instructions that executed in multiple cycles. Modern CPUs have much more available resources, so now it is normal for any hard-wired instruction to also be a single-cycle instruction, but there is no logical necessity for this.
An extra complication in many modern CPUs is that even if most instructions are usually hard-wired, there are also means to intercept the decoding for any opcode and replace the hard-wired operation with a micro-program, in order to be able to correct any dangerous bugs.
The results of those fetched microcode instructions then control the actual CPU internal hardware elements. And depending on the type of microcode (horizontal or vertical) those microcode instruction's bits either directly control the hardware elements, or get further decoded to then control the hardware elements.
A good 10k foot description is "a mini-cpu controlling the hardware - that mini-cpu controlled by the outside visible machine language instructions"
https://retrocomputing.stackexchange.com/questions/15227/why...
1. http://www.righto.com/search/label/8086 (Click Older Posts at the bottom to make sure you see all of them)
2. http://www.righto.com/2020/08/latches-inside-reverse-enginee...
3. http://www.righto.com/2020/06/die-shrink-how-intel-scaled-do...
In hindsight it seems rather inscrutable. Why were they hobbling their product like that? Well it seems just the arbitrary preference of one executive. But the seeming absurdity of it is partially an artifact of later thinking, from the era of single-chip microcontrollers. The 4004 and 8008 both needed a large amount of dedicated support electronics. Not just bus multiplexers, but clock drivers, special memory interfaces, etc. You couldn't turn an 8008 on without at least half a dozen support chips which were as much an integral part of the "computer" to the designers as the 8008 itself was. And while multiplexing brutally hindered the chip's performance, oddly enough pure performance doesn't seem to have been a major design goal for either the 4004 or 8008. Basically anything would be fast enough -- even multiplexed at 0.5 MHz -- for the industrial control and calculator-like applications envisioned.
The 8008 used P-channel silicon gate MOS technology and was packaged in an 18-pin package: a very poor choice, imposed by Intel management’s aversion to high pin-count packages.
[1] pages 55-56 of http://archive.computerhistory.org/resources/text/Oral_Histo...
It's worth noting that the trend has been towards (high speed) serial buses in later CPUs, e.g. the Pentium 4 was the last generation to use a parallel FSB; that was replaced with the serial https://en.wikipedia.org/wiki/Direct_Media_Interface
https://www.youtube.com/watch?v=OtA_9eYnj8U
Not much content yet, but the other ones uploaded are also intrested if small details is your thing.
But basically what you noticed is exactly why RISC swept everything else away in the late 80s to early 90s. If you have a 50,000 or 100,000 transistor budget and RAM is relatively cheap and fast, then complex microcoded designs really are a bad idea. You can get so, so much more performance out of a design like MIPS or ARM rather than an 80186, etc.
Hindsight is 20/20. If you sent me back to 1976 - 77 in a time machine, I would propose not something like the 68000 or 8086, but something very much like MIPS, or Berkeley RISC (minus the register windows). It could have been done in the late 70s. It would have been easily 3 - 5x as fast per MHz, and could probably be clocked faster. Doing so just wasn't obvious until later. Everyone was trying to pack as much sophistication into the instruction set and architecture, to ease assembly language programming, as possible.
E.g. imagine a simpler 16 bit extension of the 8080 than the 8086 was, with basically just more registers and focusing on making instructions execute in fewer cycles but maintaining a register–memory architecture (potentially also removing or simplifying some instructions but I think the 8080 ISA was already pretty minimal)?
It's a very good point. I think it's worth to ask a few questions in return.
How many years separated the two designs?
Does ARM2 support an equivalent ISA, in terms of features (not encoding)?
For instance, the 8086 has support for BCD integers, specialized instructions for loops, the ability to use its registers as 16 bits or 8bits (doubling the register count in the later case).
They each correspond to a different era, with different needs, as BCD clearly tells.
If today's HW engineers had a chance to implement a small cpu core with the same tr count, would they come up with the same ISA as the ARM1 or 8086? Would they choose to implement integer division (DIV and IDIV in x86), or not and leave it to software (ARM)? Would they pick CISC, RISC, VLIW, or something else?
The other aspect of your question is there's a lot of implicit manufacturing knowledge that you'd need if you tried to reconstruct the chip. Things like the resistance of the lines and the characteristics of the transistors that you'd need to get right for the chip to work reliably.
> It seems to! While most of the unused parts of the ROM (64 instructions) are filled with zeroes, there are a few parts which aren't. The following instructions appear right at the end of the ROM
Could it be the signature of the microcode implementor?