Insofar as terminology, what exactly is "microcode" and if it can be updated, how does it differ from firmware?

This question is not a duplicate of this question (as far as I can tell) which I've also asked about modifying microcode. Here I'm strictly wanting to know how to use these terms properly.


I have an answer selected, but I'm not particularly satisfied with it. I've engaged a lot of the answers and I find a lot of those responses equally unsatisfying. So let me present to you my two frames,

  1. "Processor microcode is akin to processor firmware." As I read this more and more, that's how I take it. "Microcode" is in this context is just marketing over "processor firmware." Bear with me,..
  2. Or, I'm wrong, and I know it happens! In this case, I need a much more thorough idea of why I am wrong. In that answers that I read to point to me being wrong, I am struggling understanding them,
    • "Execution vs data" a lot of answers use this paradigm, but for the CPU that doesn't make much sense to me. Some assert firmware is executed, but by what? When it comes to the CPU, are programs instructions or data?
    • If the firmware bridges software and hardware (read: the electrical engineering stuff of the Gods), then how is microcode not also satisifying that distinction.
    • "Interpreting" as time goes on, this even makes less and less sense. What does it mean to say "hardware instructions are interpreted" with Microcode. If that was true, would something be as performant if it wasn't interpretted but precompiled to different hardware instructions and merely "executed"? Also, how is General MIDI not interpreted in the same light? It's a language that gets interpreted by "MIDI microcode" and runs on the hardware. Or, dumb terminals that interpret teleprinter instructions for visual display?
    • Does "microcode" apply to the code that runs on sound cards, and video cards (GPUs)?
  • 1
    I'm not an expert, but I would say that microcode is processor firmware. I imagine all the data on how microcode is executed would be proprietary by intel/AMD, but I can guess on how it would work. You have a simple CPU set, basic stuff like fetching from memory and maths operators. Then you have a complex instruction set (such as x86/intel). The CPU gets the instruction from memory and uses the microcode to convert the complex instruction into simpler ones. One example would be multiplication. Most CPU's have a multiply instruction, but actually multiplying consists of multiple bit shifts. Jan 8, 2018 at 20:20
  • The term Microcode refers to the fact that it uses/underlies many of the CPU „code“ instructions. It basically tells the CPU how to emulate instructions and features. Hence it’s name. From the point of a computer owner it is yet another set of code shipped by hardware vendor, so it can alternatively be summarized as firmware.
    – eckes
    Jan 9, 2018 at 6:15
  • 1
    IMO, the best simple answer is, "Each time a processor executes an instruction, it is actually executing a microcode program." What seems to you to be a single processor instruction is a particular sequence of microcode instructions, a 'microcode program'. Each instruction has its own microcode program. The individual microcode instructions enable/disable/etc the various internal bits of the processor. Jan 19, 2018 at 5:29

14 Answers 14


The origin of the word firmware is a mid-point between hardware and software - software embedded on hardware. It refers to software that it is stored in non-volatile memory (such as ROM, EEPROM or Flash memory) on a hardware device, and is used by the device itself.

It's becoming more common in some types of hardware for its "firmware" to be stored in driver software and loaded onto the device when it's booted/initialised, instead of leaving it permanently on the device. It's not a big deal nowadays, for example, to store a few hundred KB of firmware code in a software driver loaded onto the host OS, and to send that down to the device as it's initialised by the driver.

This is still commonly referred to as "firmware" even though it is not resident on the hardware (if you detach the hardware and put it in another system, it won't retain that version of "firmware").

Microcode is a subset of this. Microcode is not a generic term for all firmware that is loaded onto a device at boot. Instead, it's specific to CPUs, where the microcode forms the translation layer between higher level standard CPU instructions and the lower-level operations specific to that CPU. It may be loaded onto the CPU at boot, by the BIOS, and replaced later in the boot stage by the OS as well.

An update to microcode can allow a CPU's low-level behaviour to be modified to work around certain yet to be discovered bugs, without needing to replace the CPU hardware. Microcode usually contains the most efficient mapping from higher to lower level instructions as possible for the best speed and energy efficiency, so sometimes when a change to microcode is necessary to fix some bug, it can result in reduced performance.

Note that unlike Spectre, Meltdown (the vulnerability affecting only Intel chips) cannot be fixed with microcode updates alone and requires changes to core OS functionality, which may reduce performance even further.

To answer some of your specific questions since your edit:

  1. Yes, microcode is basically firmware that runs on the processor. The special term "microcode" specifically refers to the firmware on a processor that contains the blueprint for translating from standard machine language to low level processor instructions. So it is a more specific term than firmware.

    Note that as I discuss above it isn't stored on the CPU while it's off but loaded onto it each time you boot.

  2. I don't think you're wrong. Firmware doesn't have to be written in a certain machine language and its execution doesn't have to be triggered in a certain way. At a certain low level all machine code is "data" that is "read" by a processor and interpreted in a certain way.

    The term "microcode" is typically only used for main CPUs and not graphics cards or other hardware, even though those other devices may have code loaded onto them in the same way.

  • 1
    Your second sentence is incorrect; firmware includes software stored in ROM. Once upon a time most firmware was in ROM, before alternatives became affordable. Jan 8, 2018 at 7:10
  • 1
    Clearly, "microcode" is specific to a CPU. The question is other than being specific was does it do different. Removing the scope ("the CPU"), you get an almost direct quote of "translation layer between higher level instructions and the lower-level operations". That's pretty much just the definition of firmware. Is that not what all firmware does? It's a lot of words, but I think the most descriptive and terse description is the above, "Processor microcode is akin to processor firmware." Jan 8, 2018 at 16:33
  • @Evan, most devices receive their instructions indirectly, sent from code that is running on the CPU. Only the CPU is directly processing code provided by the user. Also consider that most devices contain an embedded CPU of some sort that runs the firmware, and that CPU might have its own microcode. The distinction may only matter to hardware designers and kernel programmers, but it isn't an arbitrary one. Jan 8, 2018 at 17:52
  • "most devices contain an embedded CPU of some sort that runs the firmware, and that CPU might have its own microcode" that's what I mean. So the code that processes a midi stream on a sound card is also "microcode"? Or the code that draws/renders display characters on a dumb terminal? Jan 8, 2018 at 17:55
  • No. The code that is running on the sound card to process a MIDI stream is just ordinary firmware. The code that processes the code that is running on the sound card to process a MIDI stream would be microcode. (In practice I'm not sure that the embedded CPU on something as simple as a sound card would need microcode in the first place, but that's beside the point.) The key thing is that a MIDI stream, or the characters being sent to a dumb terminal, aren't code. They're just data. Jan 8, 2018 at 18:04


CPU Microcode

Processor microcode is akin to processor firmware. The kernel is able to update the processor's firmware without the need to update it via a BIOS update. A microcode update is kept in volatile memory, thus the BIOS/UEFI or kernel updates the microcode during every boot.

Processors from Intel and AMD may need updates to their microcode to operate correctly. These updates fix bugs/errata that can cause anything from incorrect processing, to code and data corruption, and system lockups.

The BIOS (or UEFI) updates the CPU microcode during boot, however most of the time either the motherboard vendor won't issue frequent BIOS/UEFI updates, or the user won't install such updates. For these reasons, the system processor is likely to be running with outdated microcode on a vast number of systems.



  • 9
    It is not that simple: Microcode is "a technique that imposes an interpreter between the hardware and the architectural level of a computer". As such, the microcode is a layer of hardware-level instructions that implement higher-level machine code instructions or internal state machine sequencing in many digital processing elements. Source: en.wikipedia.org/wiki/Microcode
    – SYS_V
    Jan 7, 2018 at 22:24
  • 18
    So wait ... a "boat" is just a particular kind of "vehicle"? What a useless word! :-) Jan 8, 2018 at 7:11
  • 4
    @HarryJohnston Well, I consider it rather useful to distinguish "a boat" from other types of vehicles in certain contexts... and "microcode" is a very specific type of "something" that is present in many modern CPUs... (thus it is rather desirable to have a term for it). Jan 8, 2018 at 14:14
  • 5
    @RadovanGarabík: That's exactly Harry's point, made with sarcasm. Jan 8, 2018 at 14:20
  • 4
    I don't get it. If "The kernel is able to update the processor's firmware without the need to update it via a BIOS update", then why does the fact that "the motherboard vendor won't issue frequent BIOS/UEFI updates" mean that "the system processor is likely to be running with outdated microcode on a vast number of systems"? Why doesn't the kernel just patch the microcode? Why rely on the BIOS if the BIOS never gets updated, and there's a more frequently updated alternative available?
    – Ajedi32
    Jan 8, 2018 at 17:36

Well, Intel "microcode updates" are in fact "firmware" updates in the sense that they update a lot more than just the microcode translation unit of the processor.

These unified processor package updates we call "microcode updates" for Intel also update other on-die microcontrollers (such as the PMU and the power management core) as well as several parameter tables for different on-die processor subsystems. They are rather complex.

This information is available on several of the Intel patents related to microcode and microcode updates.


I think the term "microcode" refers primarily to what the code does (it executes low-level instructions using even lower-level instructions), while the term "firmware" refers primarily to how it is stored and managed (less easily updated than software, more easily updated than hardware). In that sense it's rather like the distinction between an "application" and a "JAR file" - the same program might be both, but you are looking at it from two different perspectives.

Incidentally, the idea of microcode goes back to Maurice Wilkes in 1951, decades before computer processors were embedded in silicon.


Firmware usually refers to code for devices that contain a CPU not the CPU itself e.g. the firmware for a android phone.

Microcode is a translation layer between complex instruction sets (e.g. 486, 686, AMD-64 ect.) and the lower level instructions that chip makers design silicon for. So a number of instructions in the CPU instruction set are not implemented in silicon but translated via microcode into multiple instructions that are implemented in silicon.

  • But, isn't that true of all firmware. Instructions ABIs that could be implemented in Silicon but aren't and are otherwise updatable through software? Jan 7, 2018 at 22:22
  • 1
    Intel's "microcode updates" can do much more than modify how microcoded instructions decode. e.g. they can disable the loop buffer (in Skylake to fix the SKL150 erratum) because when possible the CPU is designed to make this possible in case hardware bugs are discovered. Jan 8, 2018 at 23:55

"Microcode" was the original term, and referred to instructions which were used to implement an interpreter for a processor's "public" instruction set.

But over time, with many variations in in implementation schemes, the distinction, such as it was, got more vague. First there was horizontal vs vertical microcode, then various schemes for writing "microcode" (to implement, say, the I/O instructions) in the "main" processor instruction set. Then there was a need to distinguish between code which was easily loaded via ordinary program "run" operations, vs code (for BIOS, eg) which was saved in ROM or some other protected and relatively immutable storage. Thus the term "firmware" was invented to refer to these instructions which were somehow made more persistent (and less accessible for user modification) in storage.

But things have morphed and twisted many times since these first distinctions were made, and anymore the terms are only definable with any precision within a given processor and OS environment.

  • +1, the key here is that there are many meanings of the term "microcode", and I think the OP really wants to know about "microcode updates", not the other meanings. Jan 9, 2018 at 4:09

[NB: this answer is specifically intended to address the recent edit and does not otherwise add to the several sound answers that have already been posted.]

So, to reiterate: microcode (at least to a first approximation) is a specific kind of firmware.

"Microcode" is in this context is just marketing over "processor firmware."

Well, it's not marketing. Marketing would have called it XBoost Pro(TM) or something. Rather, it's an engineering term; if you design CPUs, the distinction between microcode and the CPU's other firmware (and the sort of firmware typical to other devices) is important to you. If not, it probably isn't.

If you design motherboards or write operating systems, you probably use "microcode update" as shorthand for the more unwieldy and less familiar "CPU firmware update". Most CPU firmware updates primarily affect the microcode, so it's close enough to the same thing. You probably do know the difference, but you don't need to care about it.

The end user doesn't need to know or care about the difference, and in an ideal world would never hear the word "microcode" at all.

I'm guessing it came to your attention in press coverage of the recent speculative execution vulnerabilities, though you might also have heard it earlier in a context that made it more obvious that you didn't need to care. These vulnerabilities were released earlier than planned which may have resulted in press coverage being less curated than it might otherwise have been. From the end user's point of view, you need to install BIOS updates, operating system updates, and in some cases application updates; you need neither know nor care which if any of these include new microcode.

So, even realizing that you probably don't need to know or care, you may still be interested out of pure curiosity: how might you go about distinguish microcode from other firmware?

Well, the first thing to recognize is that there isn't necessarily a single hard and fast definition, it is more of a Bleggs and Rubes situation. Still, there are some things we can say about microcode:

  • Microcode generally runs inside a CPU rather than on a CPU. That's the high-level view.

  • The architecture of microcode typically looks quite different to the architecture of ordinary code, including ordinary firmware. It is likely to be highly parallel, and be implemented much closer to the hardware. Several of the existing answers (including your own answer) discuss this, though it should be noted that the details may vary depending on the CPU design.

  • Although hardware is often designed to run only the firmware provided by the manufacturer, it is not particularly uncommon for third-party firmware to be used - though it will probably invalidate the warranty! Third-party microcode is much much rarer, though I believe that in ancient times (I'm talking about when a CPU was about the size of a breadbox) some end-users would modify the microcode in their CPUs. So far as I'm aware, this isn't possible in the sort of CPUs used in PCs.

  • Microcode typically translates or helps to implement a public instruction set architecture, i.e., it runs the machine code that the operating system designer and application programmers use. More on this in the next section.

"Execution vs data" a lot of answers use this paradigm

In confusingly different ways, I fear, but I'll address my own comment. This section also serves to expand on the last bullet point above. The goal here is to try to distinguish between the job that a CPU is doing (achieved by a combination of hardware and microcode) and the job that a typical device is doing (achieved by a combination of hardware and firmware). I'm going to choose a SATA hard disk drive.

The SATA drive follows instructions from the computer, which are along the lines of "read the data from sector 5,123" and "write this data into sector 1,321". The drive's firmware is responsible for making the hardware make this happen, and it is typically pretty ordinary code running on an embedded CPU of some sort. The drive's instructions arrive sequentially, though they might not be processed in the order in which they arrive. These instructions aren't a program, they are sent by a program running on the main CPU. In particular there is no flow of control, i.e., no instruction to tell the SATA drive which instructions to run next.

The CPU is in charge of the computer. Once it has finished initializing it runs the instructions ("machine code") provided by the motherboard (the BIOS, another type of firmware) which direct it to run the machine code provided by the operating system which directs it to run the machine code provided by application vendors. The CPU itself retrieves the machine code from EEPROM (in the case of the BIOS) or RAM (in the case of the operating system and applications). In particular, machine code has a flow of control: the machine code tells the CPU what machine code to perform next. You can loop over the same machine code repeatedly, you can run different bits of code depending on the data the code is working on - the instructions in a device interface language like SATA code can do a limited set of simple tasks, but machine code can do anything. (See also Turing Completeness.)

We could rewrite that final bullet point above as: microcode usually implements a Turing Complete language; ordinary firmware usually doesn't.

What does it mean to say "hardware instructions are interpreted" with microcode.

True but probably confusing; the important point is the distinction between machine code, which has a flow of control and is Turing Complete, and the instructions defined by a device interface such as SATA, which doesn't and isn't.

Does "microcode" apply to the code that runs on sound cards

No, sound cards receive instructions, not code, just like SATA drives. The instructions might be like "play A sharp" or "interpret this data as a waveform and play it". Still very simple.

and video cards (GPUs)?

Old fashioned video cards (those without GPUs) are the same as SATA drives. The instructions are like "set this pixel to this colour" or "write an A to this position".

... GPUs are complicated and sit somewhere between the two worlds I've attempted to describe above. It is probably simplest to think of them as an specialized computer sitting inside the main computer, one which has its own CPUs. It's true that devices like SATA drives also have embedded CPUs, but the difference is that the embedded CPU in a SATA drive only runs code provided by the drive manufacturer, whereas GPUs also run code provided by the operating system and/or application vendor. Really this is a whole separate question.

TL;DR: microcode is a specific kind of firmware, which helps the hardware to implement a Turing Complete instruction set.


Microcode ("control store") is data to reside in a volatile or nonvolatile memory--generally a rather small but very wide memory, whose data output signals are wired to the control signal inputs of parallel hardware functional units, random control logic, etc. The microcode memory's address inputs are provided by a state machine which steps through a word of memory ("microprogram instruction") at a time, to effectively sequence the control signals of one or many hardware blocks. This time-multiplexes hardware and allows complex operations to be implemented with significantly less random logic.

In modern microprocessors there may be a hierarchy of microcode/sequencing units necessary to abstract the physical silicon microarchitecture to a more general architecture family with a common "machine code" interface. For example there may be several layers of microcode/sequencing to implement instruction decoders and floating point units.

Firmware in a traditional sense is any software/data residing in a non-volatile memory, which is expected to be infrequently or never changed. This directly contrasts software stored in or rather written to and executed from system memory which is constantly changing. Microcode specifically refers to data representing a microprogram to sequence control of hardware.

Microcode may be implemented in firmware/firmware may contain microcode, but they are not the same.

  • 1
    Modern x86 CPUs are much more hard-wired than you describe; it sounds like you're describing a non-pipelined 386, not a Haswell / Skylake. Intel's "microcode updates" can do much more than modify how microcoded instructions decode. e.g. they can disable the loop buffer (in Skylake to fix the SKL150 erratum) because when possible the CPU is designed to make this possible in case hardware bugs are discovered. Jan 9, 2018 at 0:24
  • @PeterCordes 1) x86 architecture is irrelevant to presenting the concept of microcode 2) had you understood my answer we'd be in agreement that it sequences control signals, as you allude
    – Gregory Chiasson
    Jan 9, 2018 at 0:47
  • 1
    No, Intel uops aren't really control signals. They don't directly program the logic units like in a classic MIPS pipeline. uops are read by the out-of-order scheduler to figure out which uops have a data dependency on which other uops. This is a very different internal model from something like a 6502 where the multiple steps of executing a single instruction are read from a decode ROM. What you describe is one historical meaning of the term microcode, but it's not what "microcode updates" for modern CPUs are about. Jan 9, 2018 at 0:55
  • Where did I (or the question for that matter) mention Intel or x86 micro-operations (which is NOT the same as a "microprogram" in a control-store)? Also, literally anything provided from a control store is a control signal, whether or not the signal is sequenced or static, logical or a wire. What I describe is the literal definition of microcode, "microcode updates" too. You're hung up on the sequencing aspect of my answer because many of said signals in a Haswell will be static. For the record, many are sequenced, sequencing is absolutely not mutually exclusive to pipelining or OoOE.
    – Gregory Chiasson
    Jan 9, 2018 at 1:31
  • 1
    So you're correctly answering the "what is a microcoded instruction" question, but a "microcode update" for a CPU doesn't have the same technical meaning of the word "microcode". This is an important point that should be made explicitly, as it's at the root of the OP's confusion I think. Jan 9, 2018 at 1:40

Firmware is executable code placed in a ROM or other non-volatile memory.

The original and primary purpose of firmware is to be there when a CPU starts, so it has code to execute to start or boot whatever system the CPU is part of. In the case of PCs, firmware also is used to provide services to the running operating system and also holds code for the embedded controllers that control fans, power, and a few other things, and code for the ME/PSP that runs in the background.

Peripheral devices that take firmware, such as hard drives, USB devices, etc. have an embedded CPU.

Microcode is not executable code, but a code used by the internal facilities of a device.

It's loaded into Intel or AMD CPUs with a WRMSR instruction. Loading firmware into a device involves programming a ROM or flash medium, or relying on a small loader program to be present in the device to accept the firmware.

Firmware and microcode updates are in a similar category - things you need to do to get hardware working and may need updating from time to time - but they are very different things.

Complex instructions in many CPUs are not directly wired in hardware, but "executed" by a smaller CPU-like facility in the main CPU. Microcode controls these operations. This goes back to at least the Motorola 68000 which had a "MicroROM" containing microcode.

No one other than Intel or AMD processors know what the microcode really controls or does, as they do not release details. There are attempts to hack it. Reference.

Practically, microcode updates essentially are used to disable instructions that cause problems on known models/steppings of CPUs, and the latest CPUs from Intel often require at least one microcode update before they function reliably.

Some perspective on what a CPU microcode could actually do/actually is might be gained if you read about the 6502 PLA decode ROM - the 6502 is an old 8-bit CPU and its instructions were sequenced/controlled by an internal PLA. The PLA would basically say what parts of the chip were involved at each step of each instruction (6502 instructions range from 2 to 7 cycles). This is far, far before things like caching, superscalar architecture, branch prediction, etc. Not sure if microcode on modern CPUs would control something like that PLA.

  • 1
    Intel's "microcode updates" can do much more than modify how microcoded instructions decode. e.g. they can disable the loop buffer (in Skylake to fix the SKL150 erratum) because when possible the CPU is designed to make this possible in case hardware bugs are discovered. Jan 8, 2018 at 23:59
  • 1
    Interesting point about the 6502 PLA, but pipelined CPUs have to be more hard-wired than that. Classic MIPS used different fields of the instruction-word to directly control internal logic in a way somewhat similar to that, but of course a pipelined CPU has multiple instructions in flight, potentially one for each pipeline stage if there aren't stalls. (Or for superscalar, 2 or more in each pipeline stage, and for out-of-order it's even more complex.) A lot of the internals of modern CPUs are hard-wired, but with knobs that microcode updates can tweak. Jan 9, 2018 at 0:01


I'll answer this myself using only use-context in this this pdf.

  • Firmware - Microcode is updated through a path provided by the CPU's firmware.

    "Typically, a microcode patch is uploaded to the CPU by the motherboard firmware (e.g., BIOS or UEFI) or the operating system during the early boot process."

  • Microcode - is itself the data used by the "Instruction Decode Unit (IDU)." An IDU can either be hardwired or microcoded. Microcoded in this context simply means programmed. ALSO means "the plurality of microcode." The IDU

    The IDU plays a central role within the control unit and generates control signals based on the contents of the instruction register.

  • Macro-instruction one instruction sent to the IDU to be decoded, may return any amount of Micro-instructions.

  • Micro-instruction one precomputed "control word", all of the state and instructions to execute for one clock cycle. Sent to the CPU to generate the control signals.

So in this context, you'd update the microcode with firmware. You would send macro-instructions to the microcoded IDU to resolve the macro-instruction into a "micro-instruction" for execution on the CPU, which turns them into control signals.

My reading of this

Microcode is data, but updating the microcode is done through firmware. And confusingly because you're talking about what essentially amounts to an internal lookup table, it's certainly also itself firmware in that it's essentially stored on the chip and used in the execution flow of the chip. I think you could make an argument that General MIDI, hardware PostScript, and control signals for dumb terminals are also interpreted in the same sense, in hardware, and that something takes the instruction and ultimately generates "control signals" in some kind of interpretation process.

It seems we have a special names for these processes and components within the CPU: "IDU" on a CPU, and a name for the specific input table the IDU employs which holds all the "microinstructions": the "microcode." The information about that process is proprietary and closed. I would assume it's analogous to any other technology from modems (with ATDT and the like on a Hayes modem), to MIDI cards but we don't name the specific lookup table "microcode", and instead use the umbrella term "firmware" for the flashing process and the entire payload stored on chip.

  • 2
    Linux (and Windows) can update CPU microcode totally independently of the motherboard firmware which you're talking about. Motherboard firmware does contain the latest CPU microcode and a mechanism for applying it before any code is loaded from disk, but if you haven't updated your mobo firmware for a while, you can still have the latest CPU microcode by merely updating software. You are making far too big a deal out of the connection between mobo firmware and CPU microcode. It's useful to have the firmware update the microcode every boot, but not necessary (except for stability sometimes). Jan 9, 2018 at 0:05
  • 2
    Also, not all x86 macro instructions are decoded by looking them up in the microcode sequencer ROM. On Intel CPUs, instructions that decode to 4 or fewer uops (micro-ops) are hard-coded into the decoders. Most instructions are not "micro-coded" in this sense of the word. Integer division is (div and idiv), but even FP division is single uop (because it's more performance critical, the multi-step iterative logic is done inside the divide unit instead of with microcoded uops). Jan 9, 2018 at 0:09
  • @PeterCordes you're the guy to write this answer, feel to edit any of my answer to make it more technically correct. You've got the carte blanche. Though I'll try to roll those changes in tonight, if you're short on time. Jan 9, 2018 at 0:15
  • If I get around to it, I'll finish writing the answer I started. For now, Harry Johnston's answer is probably the best one so far at answering what I think you really want to know (which is what a "microcode update" really updates, which isn't the same thing as what "CPU microcode" does, because it's an over-simplified name, as is common with technical stuff that needs a one-word name the general public can keep track of.) Jan 10, 2018 at 2:49

I've taken a course in basic ISA design, mainly in the study and design of a RISC processor modeled off MIPS concepts. Here's what I have come to remember

To my understanding, the basic blocks of a processor such as registers, ALUs, multiplexers and memory modules require certain signals for them to do their work. You would call these signals your "assertion" signals, since they are the signals required to operate these blocks. CPUs in essence, are a spaghetti block of ALUs, memory modules, registers and other hardware. Meaning each CPU must assert a certain sequence of control signals to do their work (I mean basic instructions such as ANDI, ORI, JMP, BNE, BEQ, etc.). I have had mixed feelings about it when I had to assert the signals myself (literally going through all the MIPS instructions) during testing and debugging of an instruction set since the curriculum's pace hadn't taught me anything about control units at that time.

On the other hand, assembler language boils down to opcodes and their operands in the instruction word (basically the width of your data bus). In terms of MIPS, the first 6 bits of your instruction word is your opcode. By sheer mathematical inspection alone, you cannot "assert" your ALU, register, memory, muxes.. basically the rest of your hardware with 6 bits alone.

Not unless you have... AN INSTRUCTION DECODER. The instruction decoder basically takes your opcode and generates ALL your "assertion" signals required to operate your hardware. However, instruction decoders differ in implementation between architectures and in some cases, is programmable. Microcode affects the programmable section of the instruction decoder.

I have come to believe that firmware is a general term for any information embedded in hardware. In some cases it would also refer to microcode as the its bitstream can be encoded and stored in hardware such as EEPROM and flash memory. Most of the time however, it is compiled code, asm, or even VHDL/Verilog bitstreams used in FPGAs. Microcode to me seems like semantics used for specifying the "assertion signals" in the processor of choice.


Though some company like IBM treats microcode as the synonym of firmware, I think microcode and firmware are two orthogonal concepts nowadays.

CPUs, or other digital processing units, are usually programmed through some machine instructions. These instructions as a whole are called instruction set for that processor.

Initially, instruction set is implemented directly through hardware wiring. But that lead to more and more difficulties as the instruction set getting sophisticated.

There's a famous aphorism of David Wheeler: "All problems in computer science can be solved by another level of indirection" ref. I think it can be applied to the motivation of microcode as well.

With the introduction of microcode, programmer-visible instructions are not directly implemented at the hardware level, but indirectly implemented as micro-programs, which is implemented in programmer-invisible microcode. And the microcode is implemented at hardware level to achieve some most fundamental actions.

With the one extra layer of microcode, hardware circuit design/debug can be simplified. And much sophisticated instructions can be achieved with much less effort.

BTW, I think microcode is kind of like the RISC instruction set with regard to they both simplify the hardware design.

As to firmware, I think there are mainly boot firmware and runtime firmware.

For boot firmware, such as the UEFI firmware on Intel platform as an example. It's mainly written in assembly/C code, which is higher than microcode. And it does much higher-level initialization things for the platform such as configure each hardware components on the platform to a usable state. And then boot the OS. And then leave the stage.

For runtime firmware, I think many RTOSes on embedded platforms are examples. They exist all the time the system is running. They take care of the whole platform during the runtime. And their complexities and design can vary.


From Intel's point of view, the CPU is chipset (PCH), what we call CPU is really a "Bigcore": just a plug-in device, ucode is for it and is loaded through CRBUS.

Now the firmware is just what it is: a linux like operating system, Minix, that has drivers for VISA framework (signal analyser with picosecond clocks), and all USB/SATA/PCIE/crypto/Bigcore/etc devices connected using IOSF (Intel On-chip System Fabric). Minix is running on its own CPU in chipset and controls Bigore and stuff. See https://kakaroto.ca/2020/08/exploiting-intels-management-engine-part-3-usb-hijacking-intel-sa-00086/

Also see this for what is inside ucode (disassembler after decrypted ucode is leaked from CRBUS, yet nobody hacked modern RSA encryption yet, but previous two are hacked already CRBUS has it already decrypted): https://github.com/chip-red-pill/uCodeDisasm

And see this to see what is inside firmware, which is actually a lot of folders! https://camo.githubusercontent.com/f8ffd2944bf3393b5957d02e4fa9a1558b4995c2cc3ae8aea0b782eb7332bac0/68747470733a2f2f692e696d6775722e636f6d2f444a4a505750582e706e67


The microcode is sub-asm level, cpu-integrated firmware.

  • Actually, no. It is sub Minix OS layer. Minix controls CRUBUS through that you get access to Bigcore, that is what we call CPU. The actual CPU it runs on is PCH. Sep 26, 2021 at 16:08

Not the answer you're looking for? Browse other questions tagged or ask your own question.