If you look at a die photo of a 6502, about forty percent of the chip is taken up by what's obviously microcode, both by its regular structure and by the obvious need for such from the instruction set, which has some relatively long instructions that need to do half a dozen things in exact sequence.

But it's not a ROM; as explained in the answer to How was microcode implemented in retro processors? it's actually a PLA, which differs from ROM in that it "allows partial decoding, one entry can fire on different instructions. For example, all instructions loading the second byte as immediate share one single PLA entry (microcode line). In comparison with textbook microcode engines, this is equivalent to a kind of compressed microcode."

Such compression is obviously useful. Die space is expensive; reducing the space taken up by microcode means you can make the chip cheaper, or spend the space adding more features, more performance or some combination thereof.

As I understand it, later chips like the 8086 and 68000 use microcode of the conventional ROM variety.

Why did later chips not also use PLA's and thereby gain the advantages of compressed microcode?

  • I think the main difference was the 6502 was laid out by hand without reliance on tools/software, that would have needed some sort of advanced AI to accomplish what Mensch did manually.
    – Brian H
    Commented Jun 18, 2020 at 13:37
  • The 6502 doesn't have microcode. What you're calling microcode is just a complex sequencer. It goes through sequence of up to 7 steps per instruction and then resets to 0 for the next instruction. Actual microcode is more like machine code. It can do things like conditionally loop allowing the implementation of instructions like multiply and divide.
    – user722
    Commented Jun 18, 2020 at 14:06
  • 1
    Microcode is NOT like machine code -- at least, not always. There are types of microcode, vertical and horizontal, where vertical one is indeed more like machine code, while horizontal one is more like a very wide word, where each bit directly controls something elsewhere in the CPU. en.wikipedia.org/wiki/Microcode . And what 6502 has is more like horizontal microcode, with a seven-stage microcode instruction pointer and all microcode execution along with architectural instruction decoding done in a single PLA.
    – lvd
    Commented Jun 18, 2020 at 15:28
  • 1
    @RossRidge If the sequencer works from a clock and fires lines, then it's microcode. The one used in the 6502 is just a very fine reduced version. Also, there is no rule that microcode per se has to be able to loop. That's only to be added if needed. Last but not least, the 6502 doesn't always go thru all 7 steps, but restarts with the next instruction when hitting a stop condition.
    – Raffzahn
    Commented Jun 18, 2020 at 16:50
  • 1
    I am not convinced that there is any bright line that separates "complex sequencer" from "microcode engine" I wrote microcode for a minicomputer back in the 80s. I know it was microcode, because I didn't have any input into the hardware design, and the hardware guys dropped a "micro-architecture manual" on my desk. But if the same folk who do the gate-level design are also the ones who decide what to put in the ROMs, then I don't know how you say for certain whether the ROM contents are "microcode" or just truth tables. Commented Nov 19, 2020 at 19:39

4 Answers 4


But it's not a ROM; [...] it's actually a PLA

Then again, a ROM and a PLA is essentially the same technology. What differs here is not only the decoding, but that in case of the 6502 only the decoding part is present and it's not monotone.

Such compression is obviously useful. Die space is expensive

True. But it's worth to note that the cited answer says "a kind of compressed microcode" as it's not simply compressed microcode. Its savings from leaving out the data part and as well from structuring the instruction set around this feature. 'Simple' microcode leave full freedom to the instruction set designer about how to encode, aka what bit pattern results in what instruction to be taken. The 6502's way relies on arranging them in a certain structure to take advantage of the 'compression'. Not doing so will result in zero savings.

As I understand it, later chips like the 8086 and 68000 use microcode of the conventional ROM variety.

  • Most important here: a cleaner design (process). With classic microcode hardware design and instruction set design becomes independent or at least less tight coupled. Late changes can be included without much problems, especially if the ROM is designed a bit larger than the bare minimum.

  • Next, the way of 'compression' used in the 6502 delegated the work to the random logic activated by each line. Where standard microcode output has dedicated functions for all blocks handled by all instructions, the 6502's way mangles this up. In some way it can be seen like spaghetti code in BASIC. Great approach for a simple task, but it soon gets out of hand when the job gets more complicated. What works for the rather simple instruction set of a 6502 with just 56 (essentially only 25) instructions and 13 (8) addressing modes doesn't work the same way for either of the 16 bit CPUs with their huge number of instructions and addressing modes.

    Any change here always means also a change in random logic, not just microcode data.

  • Which brings the issue of complexity. Where an instruction set like the 6502 features and it's execution units can be optimized and 'compressed' by hand in a reasonable time, it will be a gigantic task to do the same for a 8086 or 68k. Not saying it can't be done, but the gain will be much smaller and the risk of screwing it up much higher.

    Of course it may be possible to handle the additional complexity of an 8086 or 68k by a comparable small PLA, but it will most definitely increase the random logic several times, not only eating up much of the savings (or even adding) but increasing the needed effort exactly in the area point where it's hardest

  • Last but not least, it's an economic decision between effort in design, cost of chip space and risk of problems/failure:

    • A tightly fitted system like for the 6502 simply costs more engineering time than using an rather standard microcode approach.
    • Saved chip space is always in relation to technology. While saving a small group of transistors, like 13 for a PLA row, was a big deal for a 6502, doing the same for a 8086 or 68k would have a neglectable effect.
    • Using an 'unconventional' approach like the 6502 did increases the risk of failure. Heck, even MOS did mangle it up with the first rund, screwing the ROR.

Especially the last points are nothing one wants to have on a small budget project meant as a short time stop-gap measure, like the 8086 was (*1). Design situation on the 6502 was a different one. They had even less funding, but way more time on their hands - and more pressure to save on size.

Long story short: Cost, time and risk outwights any possible gain.

P.S.: With today's tools it might be possible to have a random logic version of either chip generated, eventually creating faster versions. But for top end results, the microcode as abstraction layer persists - sometimes even on multiple levels.

*1 - The 68k in contrast is a typical Motorola product - by the book - so microcode it is anyway.

  • 2
    During the 6502 era, transistors cost a lot less than routing. PLAs use a lot of transistors, but they minimize routing area. Chips with three or more layers of metal have very different trade-offs from those with only one metal layer.
    – supercat
    Commented Jun 19, 2020 at 13:56
  • 3
    Interestingly, Chuck sort of mentions this whole topic during his CHM interview. They were dreaming up ways to save a few microns of space here and there at a party. Commented Jun 19, 2020 at 14:28

Two interconnected moments in history with the popularity of microcode in microprocessors need to be distinguished:

  • Firstly, the ratio of price, volume and speed of various types of memory;
  • Secondly, the ratio of manual labor and the development of automation, including the theory of compilers.

The heyday of the microcode came at a time when the means for automatic development of integrated circuits were just beginning to flourish, and manual development on the ruby ​​film of processor circuits with tens of thousands of transistors was already too slow.

At the same time, the cost of RAM, and at all levels - from SRAM processor registers to DRAM RAM itself was still very high, which required a high code density. High code density was often achieved by manual optimization at the level of assembler and even machine codes, which required some convenience and human readability from the instruction set / processor architecture.

An additional layer of some abstraction between the actual executive blocks of the processor and the code was a generally accepted compromise.

And then the RISC revolution happened.


It is also worth mentioning the problem of debugging processors.

Satisfactorily prototyping the microprocessor on assemblies of ICs of small and medium integration when using PLA in the late 70s was difficult due to the physical limitations of the method. Emulating software on mainframes was difficult to impossible because of the dampness of software and the size of RAM, slowly and also took a lot of time. Debugging directly on silicon required many production cycles on the fab, which resulted in many weeks of debugging.

Using microcode brought some of the debugging problems to a different, simpler level - in prototypes it was possible to replace the firmware ROM with a (even external) SRAM module and quickly identify / correct errors.

  • 1
    the dampness of software??? Commented Jun 19, 2020 at 14:01
  • 2
    Direct tracing from the Russian expression "сырой софт", i.e. unprepared, new / under development and debugging, having defects Commented Jun 19, 2020 at 14:10
  • Interesting. But very close to a googlenope - only 3 matches (will be 4 once this page gets indexed). Commented Jun 19, 2020 at 14:28
  • "Raw software" would be a better translation for "dampness" Commented Nov 23, 2020 at 17:39

For those interested in the hands-on use of microcode, including how to implement a CPU (1802 - which was NOT microcoded, but a FSM control unit) and a display controller, I developed a compiler that generates the [horizontal] microcode and instruction mapper memory. https://hackaday.io/project/172073-microcoding-for-fpgas


As I understand it, later chips like the 8086 and 68000 use microcode of the conventional ROM variety.

This is simply not true. 68000 CPU used a combination of PLA-driven decoding and ROM-driven microcode engine. Look https://dl.acm.org/doi/10.1145/1014198.804299 for reference (remember that there is Sci-Hub at your service if you know DOI: https://sci-hub.st/https://doi.org/10.1145/1014198.804299).

Another example is LSI-11 chipset WD16xx, where there are also microcode PLA to decode PDP-11 instructions (particularly to get starting point in microcode ROM) and microcode ROM (all in different chips) to execute micro-sequences.

Modern amd64 CPUs first do hardwired decoding, then go into microcode ROM (or RAM, partly) to generate micro-op sequences for some architectural instructions.

The general idea behind PLA vs ROM microcode is the following: with PLA (or just logic) you can easily decode instruction and group similar but differently-coded instructions in a single bunch, and this is very costly to do with just ROM microcode alone (look at 68000 with 16-bit opcodes). Alternatively, executing sequences of internal operations is better done with ROM microcode, hence both technologies are usually combined (starting from the venerable 68000 chip and LSI-11 chipset).

8-bit CPUs are a special case, where both ROM or PLA would be approximately the same size alone, and the natural choice is to have only PLA, which also does most tasks of ROM with the help of a standalone sequencer, as it is in 6502.

The answer to the question would be then "No, PLA- (or generally, logic-) directed decoding is still used, along with ROM- (or RAM-) based microcode sequencers."

  • 2
    Erm, reading the cited paper I can only see a very classic sequential (vertical) microcode. In fact even using two level of micocode, as there is a secondary horizontal one. And both ROMs are with 26,000 bit (640x10 and 280x70) about 2.5 times the single level microcode (512x21 -> 10.752 bits) used in the 8086. The instruction decoder you're referring to as PLA is a straight decoder without any sequencing. The PLA of the 6502 is decoder and sequencing, all in one. So for any comparison it needs to be seen as one functional unit, depite different naming.
    – Raffzahn
    Commented Jun 18, 2020 at 16:34
  • @Raffzahn look also at WD1600 chipset. Also, I can't say for sure whether decoding in 68000 is made with PLA, but it is a probable case.
    – lvd
    Commented Jun 23, 2020 at 9:30

You must log in to answer this question.

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