5 ms·

The concept of microcode is fairly old. It was present at least as far back as the IBM 360 (1964), so it predates microprocessors. One big motivating factor fo

The concept of microcode is fairly old. It was present at least as far back as the IBM 360 (1964), so it predates microprocessors. One big motivating factor for microcode is that it insulates the Instruction Set Architecture (ISA) from its actual implementation in hardware. That makes it a lot easier to be forward/backwards compatible. Without microcode, you have a situation where every generation of processor, and even different implementations of a microprocessor will have different internal resources and circuits. You need to be able to control things inside the processor like the flow of data between registers, ALU(s) and the memory bus... But for each processor implementation, the available connections and execution units are going to be different. Microcode allows you not to expose all those underlying details to the outside. It's also more compact than having to directly control all of the connections inside of a CPU manually. An alternative would be to have circuits that implement boolean logic and go directly from instructions bits to the internal control logic, but microcode also makes it easier to execute an instruction in multiple steps instead of being tied down to the constraint that each instruction must execute in exactly one cycle.

skissane 4y ago
> An alternative would be to have circuits that implement boolean logic and go directly from instructions bits to the internal control logic, but microcode also makes it easier to execute an instruction in multiple steps instead of being tied down to the constraint that each instruction must execute in exactly one cycle. Microcode is effectively just a program. Can't you just write the same program in Verilog or whatever? I think the answer is "yes", but then you can't patch it afterwards, plus Verilog/etc didn't exist when microcode was invented. Which I think is why microcode was invented – it was a big time-saver when circuit design was an entirely manual pen/paper process, and also it kept component counts down when the per-component cost was very high. Now we have HDLs, and transistor budgets in the hundreds of millions or billions, those reasons don't really apply any more. But the need to patch post-shipment is even bigger than it used to be. As we put ever more complex features in silicon, the probability of bugs increases. With 3rd generation computers, you could always fix bugs by having a technician rewire some of the circuitry – more work than just replacing the microcode, but still feasible. It is completely infeasible to physically rewire the circuitry of a microprocessor, if you can't fix the problem in software (and microcode is ultimately a form of software), all you can do is manufacture a replacement then throw out the original. > But for each processor implementation, the available connections and execution units are going to be different. Microcode allows you not to expose all those underlying details to the outside. That's another reason which probably isn't as strong as it once was. In the 1960s, lots of software was written in assembler – having the same assembly language across the entire IBM S/360 line was a big win, since it made it easy to port software between machines, reuse skills, etc. Nowadays, very little code is still hand-written in assembler, almost all software is compiled from a high-level language – so if different machines have different ISAs, or (more commonly) a common ISA but with each machine implementing a different subset of it, and that forces you to recompile to move the code to a new machine – still somewhat of a burden, but far less than in the 1960s, or even 1980s.
- temac 4y ago
  You could not patch 8086 microcode though. On this CPU was just because it was simpler and maybe smaller than random logic. Most CPU have a form of microcode in one place or another, often sequencing transfers between registers and buses. Also, ISA compat is still crucially important. Maybe slightly less than before high level languages prevalence, but only slightly. You can only just recompile high level code if: * you have the source * you have a compiler for source to target * it is completly generic (e.g. no specific accelerator used) In practice Windows on ARM shows that few people do it - even less so in a timely manner.
  - skissane 4y ago
    > You could not patch 8086 microcode though. On this CPU was just because it was simpler and maybe smaller than random logic. From what I understand, when the 8086 was being designed, the design was still mostly being done by hand, and the transistor budgets were still really small, so those two reasons for microcoding still applied. Things today are high much more automated and have much higher transistor budgets > Most CPU have a form of microcode in one place or another, often sequencing transfers between registers and buses. You need a control state machine, and you have two basic choices on how to implement it: microcode or random logic. Either way you will need registers (or something equivalent) to store control state > Also, ISA compat is still crucially important. Maybe slightly less than before high level languages prevalence, but only slightly. You can only just recompile high level code if: * you have the source Some of this is because OCO (object code only) software took over the market. I say “OCO” because in the 70s it was common for proprietary software to come with source - nobody called it “shared source” because it was just the norm which didn’t need a name. Indeed, when (in 1983) IBM stopped allowing customers source code access to their proprietary mainframe products, they had to invent a name for it (OCO). OTOH, unlike mainframe/minicomputers and commercial Unix, “secret source” became mainstream on microcomputers much earlier in their history. Also, in part this is because technologies such as OSF’s ANDF (aka TenDRA) never really took off, although WebAssembly may change that > * you have a compiler for source to target Not that big an issue given open source compilers (LLVM, GCC). Historically most vendors with their own CPUs had their own compiler development teams too (IBM, Sun, DEC, HP, Intel, among others). An incompatible ISA might nonetheless be just a small variation on an existing one so the necessary change to the backend might be small > * it is completly generic (e.g. no specific accelerator used) Many apps don’t use acceleration directly only through libraries (like crypto libraries using hardware crypto instructions)-again, a vendor with their own CPUs and compilers likely has these libraries too, and is responsible for changing them > In practice Windows on ARM shows that few people do it - even less so in a timely manner. Some of that’s because of the nature of the Windows ecosystem. Swapping CPU architecture on Linux is generally a lot easier, because many Linux hosts are 100% FLOSS except for the in-house apps they are used to run
boygobbo 4y ago
Even older. Maurice Wilkes first proposed the concept in 1951 & the EDSAC-2, the first computer to use microprogramming, was operational by 1958.
dreamcompiler 4y ago
> It's also more compact than having to directly control all of the connections inside of a CPU manually. I expect this compactness -- or more specifically transistor count -- was a big driver of the design. Ken discusses the "hybrid" microcode of the 8086: Both more microcode or less microcode would probably have required more transistors than the final design incorporated.

skissane 4y ago

> An alternative would be to have circuits that implement boolean logic and go directly from instructions bits to the internal control logic, but microcode also makes it easier to execute an instruction in multiple steps instead of being tied down to the constraint that each instruction must execute in exactly one cycle. Microcode is effectively just a program. Can't you just write the same program in Verilog or whatever? I think the answer is "yes", but then you can't patch it afterwards, plus Verilog/etc didn't exist when microcode was invented. Which I think is why microcode was invented – it was a big time-saver when circuit design was an entirely manual pen/paper process, and also it kept component counts down when the per-component cost was very high. Now we have HDLs, and transistor budgets in the hundreds of millions or billions, those reasons don't really apply any more. But the need to patch post-shipment is even bigger than it used to be. As we put ever more complex features in silicon, the probability of bugs increases. With 3rd generation computers, you could always fix bugs by having a technician rewire some of the circuitry – more work than just replacing the microcode, but still feasible. It is completely infeasible to physically rewire the circuitry of a microprocessor, if you can't fix the problem in software (and microcode is ultimately a form of software), all you can do is manufacture a replacement then throw out the original. > But for each processor implementation, the available connections and execution units are going to be different. Microcode allows you not to expose all those underlying details to the outside. That's another reason which probably isn't as strong as it once was. In the 1960s, lots of software was written in assembler – having the same assembly language across the entire IBM S/360 line was a big win, since it made it easy to port software between machines, reuse skills, etc. Nowadays, very little code is still hand-written in assembler, almost all software is compiled from a high-level language – so if different machines have different ISAs, or (more commonly) a common ISA but with each machine implementing a different subset of it, and that forces you to recompile to move the code to a new machine – still somewhat of a burden, but far less than in the 1960s, or even 1980s.

temac 4y ago
You could not patch 8086 microcode though. On this CPU was just because it was simpler and maybe smaller than random logic. Most CPU have a form of microcode in one place or another, often sequencing transfers between registers and buses. Also, ISA compat is still crucially important. Maybe slightly less than before high level languages prevalence, but only slightly. You can only just recompile high level code if: * you have the source * you have a compiler for source to target * it is completly generic (e.g. no specific accelerator used) In practice Windows on ARM shows that few people do it - even less so in a timely manner.
- skissane 4y ago
  > You could not patch 8086 microcode though. On this CPU was just because it was simpler and maybe smaller than random logic. From what I understand, when the 8086 was being designed, the design was still mostly being done by hand, and the transistor budgets were still really small, so those two reasons for microcoding still applied. Things today are high much more automated and have much higher transistor budgets > Most CPU have a form of microcode in one place or another, often sequencing transfers between registers and buses. You need a control state machine, and you have two basic choices on how to implement it: microcode or random logic. Either way you will need registers (or something equivalent) to store control state > Also, ISA compat is still crucially important. Maybe slightly less than before high level languages prevalence, but only slightly. You can only just recompile high level code if: * you have the source Some of this is because OCO (object code only) software took over the market. I say “OCO” because in the 70s it was common for proprietary software to come with source - nobody called it “shared source” because it was just the norm which didn’t need a name. Indeed, when (in 1983) IBM stopped allowing customers source code access to their proprietary mainframe products, they had to invent a name for it (OCO). OTOH, unlike mainframe/minicomputers and commercial Unix, “secret source” became mainstream on microcomputers much earlier in their history. Also, in part this is because technologies such as OSF’s ANDF (aka TenDRA) never really took off, although WebAssembly may change that > * you have a compiler for source to target Not that big an issue given open source compilers (LLVM, GCC). Historically most vendors with their own CPUs had their own compiler development teams too (IBM, Sun, DEC, HP, Intel, among others). An incompatible ISA might nonetheless be just a small variation on an existing one so the necessary change to the backend might be small > * it is completly generic (e.g. no specific accelerator used) Many apps don’t use acceleration directly only through libraries (like crypto libraries using hardware crypto instructions)-again, a vendor with their own CPUs and compilers likely has these libraries too, and is responsible for changing them > In practice Windows on ARM shows that few people do it - even less so in a timely manner. Some of that’s because of the nature of the Windows ecosystem. Swapping CPU architecture on Linux is generally a lot easier, because many Linux hosts are 100% FLOSS except for the in-house apps they are used to run

boygobbo 4y ago

Even older. Maurice Wilkes first proposed the concept in 1951 & the EDSAC-2, the first computer to use microprogramming, was operational by 1958.

dreamcompiler 4y ago

> It's also more compact than having to directly control all of the connections inside of a CPU manually. I expect this compactness -- or more specifically transistor count -- was a big driver of the design. Ken discusses the "hybrid" microcode of the 8086: Both more microcode or less microcode would probably have required more transistors than the final design incorporated.