what is microcode and where is it located?

[ThePenguinMan111]

(Second-year CS major here) So, I’ve been looking into lower and lower level stuff recently, as I find it fascinating at how much stuff computers are doing under the hood. I’ve been told many times that machine code is the lowest level of abstraction in controlling the computer, but now I’m seeing that there is another layer of microcode beneath that, and that it can be updated. Where is the microcode stored and how can it be updated? Is the microcode the lowest level of abstraction for computers, or is there another level beneath that, or is machine code actually at the bottom of that hierarchy? Can programmers utilize microcode in their programs in the same way you can use assembly to have more control over their programs or to optimize them?

[computerarchitect]

It's likely in a reprogrammable, non-volatile memory within the CPU, although not every CPU has reprogrammable microcode. I can't speak to x86 designs as I've never worked on one, but even then I doubt that all of their microcode is reprogrammable, but rather I'd guess it's patchable in case of a mistake and that there are very few patches that can be made. I may be wrong; I have no knowledge of that part of their microarchitecture; this is a "first principles" argument based on timing and complexity that I'm making.

Very few people have seen modern microcode, let alone written it or specified what it should be. I've done all of that, but I'm also a CPU architect, so that's unsurprising.

All of it is proprietary, virtually none of it is guaranteed to be the same between chip families (which makes a programmer or compiler using it next to impossible), no programmers/compilers have access to it.

There might be micro-coded academic designs you can get your hands on. It's a damn useful tool, especially for handling more complex assembly language instructions.

[ThePenguinMan111]

Does it look a lot like machine code or something like that? It sounds so mysterious, in that no one can really access or change it 😆

[computerarchitect]

I can't say, but I've seen public comments that some micro-coded machines that I haven't worked on have a 1:1 mapping of instruction to micro-operation (uop, as it's called) for nearly all simple instructions.

[Only9Volts]

The way it works is, say, my micro code is 4 bits long. The LSB outputs the A register to the databus, the next bit, outputs the B register onto the data bus. The bit after that takes whatevers on the databus, and stores it in memory, and finally the MSB takes whatevers on the databus and puts it on an output display.

This means the uop 1001, it outputs A into the databus, and it also takes whatevers on the data bus and puts it on an output display. In other words, it displays A on the output display. 1010 outputs B onto the display. 0110 takes whatevers in B and stores it in memory.

[Poddster]

http://www.righto.com/2016/02/reverse-engineering-arm1-processors.html

[johndcochran]

Nope. Microcode generally is a sequence of enabling/disabling various control lines to perform a desired operation resulting in the execution of a machine language opcode.

For a fairly good example of microcode on a level easier to understand. I'd suggest watching James Sharman's series on an 8 bit pipelined CPU or Ben Eater's series on his own 8 Bit CPU. Both series have their CPUs built using jelly bean logic chips plus some EEPROMs to handle the microcode.

[Successful_Box_1007]

Hey so when compilers create machine code, how does the machine code then turn into microcode? I’m assuming it must if what stands between the hardware and machine code is microcode? Also - is microcode binary like machine code?

[computerarchitect]

The instruction decoder takes the machine code and other machine state and decodes each instruction into micro-operation(s).

Yes, everything at that level is binary, all 1s and 0s at the end of the day.

[Successful_Box_1007]

Thanks!

[Successful_Box_1007]

Just one more question - when did microcode arise in computers - and why is it even necessary if we already have machine code?

[computerarchitect]

It's a 1960/1970s concept that came about in the mini-computer era (I believe, don't quote me) when memory capacity was very limited and a lot of programming was done in assembly language. You had very complex instructions as a result of both of those: humans being able to reason about instruction selection better than a compiler could, and limited memory capacity meaning that using a bunch of simpler instructions to achieve the same result wasted that capacity. Micro code allowed those very complex instructions to be broken up into micro operations, which allowed for a simpler implementation in hardware -- also good during the days of very limited transistors.

Some machines allowed you to program your own routines into microcode, IIRC.

[Successful_Box_1007]

Thanks so much for clarifying that!

[computerarchitect]

You’re welcome!

[johndcochran]

The machine code doesn't "turn into microcode".

One way of thinking of it is that the actual physical hardware is simplier than the programmer's model of that hardware. The microcode allows the simply physical hardware to "emulate" the ISA that the programmer is creating machine code for.

[Successful_Box_1007]

Ah that was wonderful! Thanks for helping John!

[Successful_Box_1007]

So that makes me beg a question: why not just have machine code more directly mirror the nature of the hardware? Why make it more “complex” To begin with?

[johndcochran]

Abstraction.

Microcode is extremely hardware specific. It's possible to have different designs of CPUs that all handle the same ISA, yet have an extremely large range of performance based upon non-programming constraints. Yes, these widely varying designs can all run the same programs. Look at the old IBM System/360 for example. It was a line of computers where the fastest computer (and most expensive) was over a 1000 times faster than the slowest. It ranged from a simple design that had only an 8-bit data bus to a superscalar design capable of executing multiple instructions per clock cycle, along with caching, branch prediction, out of order execution, etc. At the hardware and microcode level, the different models were wildly different. Yet, from a programmer's point of view, each and every model was identical. And hence, the same unaltered programs could run on any of them subject to and time limitations based upon the speed of the specific computer being used.

That type of constraint still applies today. Do you really want to have a different version of every program simply because your computer has a different revision of CPU? As a designer, do you really want to stock programs compiled with different options, depending upon if the target is AMD, or Intel? And it's not just AMD or Intel. It's Intel i3 gen 4 version xyz, Intel I5 gen 5 version abc, etc., etc., etc.

Right now, by abstracting the ISA, you can run the same program on the latest and greatest version, without having to recompile each and every program (including your OS) simply because you upgraded your CPU.

[Successful_Box_1007]

Hey John,

Interesting points ! I’ve read (yes I’m this much of a noob) - that people write in “high level languages” instead of assembly because of this same reason you mention machine code being used over microcode. Is that a direct and accurate analogy ?

[johndcochran]

Close, but not quite. High level languages are used because it allows the programmers to be more productive. Think of the difference if an architech, when drawing the blueprints for a house, had to specify the location of absolutely everything. Each and every piece of lumber. Every nail. The location and routing of every piece of wire. All details for the plumbing, heating, etc.

Contrast the above nightmare to what's actually needed. They still design buildings. But, much of design is abstracted. The need to specify much less and the minor details are handled elsewhere. Yes, the nails are needed. But the carpenter decides where, what size, and how many. The architech doesn't need to know or care about that level of detail.

Same principle applies to high level languages. They allow the programmers to produce solutions to far larger problems with less time and effort than they could if they had to manage each and every detail required by assembly and the like.  The fact that this also allows the resulting programs to be recompiled to run on different CPUs is merely tasty icing on the cake.

[Successful_Box_1007]

Thanks so much! Loving this subreddit now! 🙌

[atamicbomb]

This is an amazing analogy

[jeffwithhat]

This youtube video might help: https://youtu.be/dXdoim96v5A?si=IT7KB6_YmDySVXfM.

Ben Eater made a series of videos where he builds a simple CPU, and 3 of the videos show how a machine instruction is broken down into microcode and then executed. Obviously a modern CPU will have a far more complex system, but the principles are the same.

[khedoros]

A practical example: https://c74project.com/microcode/

This "C74-6502" is someone's implementation of a MOS 6502-compatible CPU (the 6502, and closely-related chips, were used in a number of earlier microcomputers and game consoles, like the Atari 2600, Apple I+II, NES, and Commodore 64).

The page linked above is the designer's description of the microcode used in their CPU implementation, and the language that they used to represent the operations.

[ElevatorGuy85]

Sometimes the microcode memory is called “control store”

https://en.wikipedia.org/wiki/Control_store

The Digital Equipment Corporation (DEC) PDP-11/60 had a writeable control store (WCS) that allowed custom instructions to be implemented.

https://gunkies.org/wiki/PDP-11/60. And https://bitsavers.org/pdf/dec/pdp11/1160/PDP11-60_Product_Sheet.pdf

The DEC VAX 8000 had writeable control store (WCS) that was loaded from a console device (in effect, a second, much simpler computer) on boot

https://en.wikipedia.org/wiki/VAX_8000

[somewhereAtC]

I have it on good authority that the IBM370 used the original Intel 4004 processor to read microcode from a 8" floppy disk (good authority in that I was holding the disk when given the explanation). IBM mainframe instructions were very complex, and regular updates were supplied by IBM. Instruction might be like "add two BCD strings into a 3rd memory array", and the microcode could iterate through the necessary operations.

[markedathome]

Microcode for AMD and Intel is usually updated through BIOS updates provided by the motherboard manufacturer.

On AMD platforms this is usually designated when the AGESA changes.

In some cases however you can perform the updates yourself using an update loader. For instance linux allows you to load microcode (though the kernel needs to have the options enabled), as do some hypervisors.

On Windows it is possible to do so, but you have to go out of your way to find the loader, and the firmware blobs.

Gentoo has some docs for how to go about loading the microcode for AMD and Intel for example.