# Micro programming and hard wiring

I have a question about the details of microprogramming and hard wiring in CPU architecture.

In hardwiring, we write a code, the compiler translates it to the ISA, then the ISA is run in the hardware.

In microprogramming, we write a code, the compiler translates it to the ISA (which is much more complicated than the ISA in hardwiring), then a device (I don't know the name) translates it to the hardware language.

Am I correct?

It would be clearer to think of the microcode as an "interpreter" for the ISA. Just like a BASIC interpreter (written in assembly language) reads tokens from the source code and performs whatever actions they indicate, the microcode in a CPU reads ISA instructions from memory and performs the required actions.

And just like you can have different language interpreters for a given ISA, you can have different sets of microcode that implement different ISAs on a given set of CPU hardware primitives. Indeed, there have been commercial systems that did exactly this.1

This concept can be applied at many levels of programming. I once wrote a text editor for my CP/M system that consisted of two layers — a low level layer that implemented all of the actual editing operations, and a high-level layer that "interpreted" the user input and called those editing functions. I wrote a user interface that imitated the vi editor, while a friend of mine wrote a different UI that imitated the ted editor, because that's what he was used to using.

1 Interesting historical note: This is the reason the very first floppy disk was invented.

With microcoding there is not a step where the ISA code is translated. A better way to think of it is that the ISA instructions are really just subroutine calls where the subroutines are written in an even lower level code and the subroutines are stored in a ROM on the processor chip.

• What you just described is an example of translation. – Chris Stratton Oct 12 '18 at 3:54
• @ChrisStratton I think its a matter of semantics. I was trying to make it clear that there was not a hidden compilation stage where the entire executable is converted from one language to another. Another answer likened it to an interpreter. Also, translation implies an (almost) one-for-one conversion, but a single CISC instruction can result in many microcode instructions being executed. – Elliot Alderson Oct 12 '18 at 11:29

Not exactly, no. In a microcoded processor, what happens is that the ISA is read by the processor and each instruction (and, potentially, some part of the current state of the processor, e.g. flags) is used as an index into a lookup table that determines what exactly the processor does. Each instruction is allowed to have multiple entries in that table that are then performed sequentially. No direct translation from the primary ISA to a "hardware language" is ever produced -- it's more a case of an extra level of indirection between the ISA and the hardware is used, with the contents of the microcode usually just being a bunch of signals that directly control the hardware of the processor (e.g. selecting the inputs to multiplexers, controlling when registers are written to, etc).

The real difference between this and a hardwired processor is that the microcode is written as a lookup table rather than the controls being generated by fixed logic. Of course, as we all know the two are actually logically equivalent, so in reality there's not much actual difference between the two.

Where a hardwired processor really differentiates itself from a microcoded one is that it is much easier to implement pipelining for a hardwired design, so most pipelined designs avoid using microcode as much as possible. This is made easier if the ISA doesn't specify many operations that need to be performed sequentially, which is where RISC comes in -- RISC instructions are generally different from CISC ones because they only do one thing, i.e. either access memory or perform calculations, whereas CISC architectures often do both in the same instruction. This makes designing a fixed pipeline for a RISC architecture much easier.