What exactly is microcode and how does it differ from firmware?

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.

Update

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)?

Solution 1:

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.

Solution 2:

https://wiki.debian.org/Microcode

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.

Examples:

https://www.win-raid.com/t3355f47-Intel-AMD-amp-VIA-CPU-Microcode-Repositories.html

Solution 3:

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.