Coder Perfect

What is Intel microcode, and how does it work?


According to what I’ve read, it’s used to address CPU issues without altering the BIOS. Assembly instructions are divided into microcodes by the CPU and executed accordingly, according to my minimal knowledge of Assembly. However, Intel allows some upgrades to be made while the system is up and running.

Is there anyone who knows more about them? Is there any documentation on what microcodes may be used for and how they can be used?

EDIT: I read the wikipedia article, but I’m not sure how I’d go about writing some on my own, or what purpose it would serve.

Asked by Quamis

Solution #1

Microcode was widely utilised in CPUs in the past: every single instruction was broken into microcode. This allowed for reasonably sophisticated instruction sets to be implemented in small CPUs (consider that a Motorola 68000, with its many operand modes and eight 32-bit registers, fits in 40000 transistors, whereas a single-core modern x86 will have more than a hundred millions). This is no longer the case. For performance reasons, most instructions are now “hardwired”: their interpretation is performed by inflexible circuitry, outside of any microcode.

Some sophisticated instructions, such as fsin (which computes the sine function on a floating point value), may be implemented with microcode in a current x86, whereas basic instructions, such as integer multiplication with imul, may not be. This restricts the scope of what can be accomplished with custom microcode.

Microcode format, on the other hand, is not only very specific to the specific processor model (for example, microcode for a Pentium III and a Pentium IV cannot be freely exchanged — and, of course, using Intel microcode for an AMD processor is not an option), but it is also a closely guarded secret. The technique by which an operating system or motherboard BIOS can update the microcode (it must be done after each hard reset; the update is stored in volatile RAM) has been disclosed by Intel, but the microcode contents have not. The update technique is described in the Intel® 64 and IA-32 Architectures Software Developer’s Manual (volume 3a), however the actual microcode is “encrypted” and clock-full of checksums, according to section 9.11 “microcode update facilities.”

If the “encryption” doesn’t include a digital (asymmetric) signature, and/or if Intel screwed up the protection system in some way, it’s possible that a remarkable reverse-engineering effort could produce such microcode, but given the likely limited applicability (since most instructions are hardwired), chances are that this wouldn’t buy much in terms of programming power.

Answered by Thomas Pornin

Solution #2

Consider a virtual machine or simulator that can imitate an arm processor on an x86 host, such as qemu-arm; the program running on the simulated arm should have no notion that it isn’t a genuine arm. Take this concept to the next level: the entire chip is built such that it always seems to be an x86, and the software has no notion there are programmable objects within. And there’s another CPU inside that’s supposed to implement/simulate an x86 in some way. According to rumors, the popular AMD 29000 product series was discontinued because the hardware team and maybe the processor/core were used in an early x86 clone. Linus worked for Transmeta, which has a vliw processor that was produced in Japan.

There isn’t any linux operating there with a qemu software within each chip, so it’s not as much of an emulation layer as I’m indicating. It’s halfway between hardwired and full blast emulation, with no software/microcode in the midst. The programmable bits could be programmable gates, such as an fpga, or software or programmable state machines, which are not programmable gates, but the code that runs on them is.

Processors that aren’t x86 or big iron. Take ARM, for example, which has no microcode and is hardwired. Microcontrollers, such as the PIC, MSP430, and AVR, are not microcoded. In general, don’t assume that all processors are microcoded; in fact, few, if any, processor families are microcoded. It’s only that the ones we deal with on computers have been and may still be, making it appear as though they are all the same.

As entertaining as playing with this microcode may sound, it is likely to be quite specialized to the CPU family, and you will almost certainly never learn how it works unless you work for Intel or AMD, both of which are likely to have their own internals. So you’d have to get a job at one of the two, then work your way up through the ranks to become a member of what is almost certainly an elite team doing this work. And once you reach to that point, your career is locked, and your talents may be limited to a single job at a single organization. You might have more fun programming individual GPUs on a video card, something that is documented or at the very least has tools, and something that you can accomplish yourself.

Answered by old_timer

Solution #3

Micro-code isn’t something you’d ordinarily write. To accomplish so, you’ll need a thorough understanding of the CPU’s microarchitecture. Intel does not publicly disclose any details about its microarchitecture or microcode.

Answered by Paul R

Post is based on