3 ms·

> 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

> 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
geocar 4y ago
> Microcode is effectively just a program. Can't you just write the same program in Verilog or whatever? I think the answer is "yes" No. FPGAs are basically big fat lookup tables, some clever partitioning logic, and a boolean function. Inputs and outputs are (from the perspective of the "programmer") simultaneous, and if you want to do any state-keeping, it has to be done in response to some transition (such as a clock pin strobing). State like registers. So you want to implement program registers and make those inputs be address and data lines, decode the instruction, map it to the appropriate internal "registers", then write out the data back to memory (if any), you're talking two transitions (or four if you want to reuse the address/data likes for fetch and load). The speed/heat/power/price at which you can do that is (for the most part) a function of how big that lookup table is. If you can decode a single instruction in 4 steps instead of 1, you usually should because it means you can strobe 4x faster (or everything else will be cheaper, lower-power, cooler, etc). Microcoding is a technique to doing this, but it's also a choice because there are limits to how little-power you can get, or how cheap fabricating any amount of silicon is, or even how low-level you can be meaningfully thinking about solving business problems, otherwise we'd all be using massively-parallel SBNZ-computers that float in the air.
- skissane 4y ago
  > FPGAs are basically big fat lookup tables I never said anything about FPGAs though. If you are telling me how microcode might be useful in overcoming limitations of FPGAs, I’m not sure what relevance that has to most microprocessors, which aren’t implemented as FPGAs
  - geocar 4y ago
    No, but they're a useful target for Verilog, and this limitation is shared by any hardware compute/circuit (I had hoped that would be obvious from the description)
    - skissane 4y ago
      You can implement a CPU completely with random logic, zero microcode - it has been done before. Yes you do end up needing something like extra registers to hold control state - but that’s not microcode

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

geocar 4y ago

> Microcode is effectively just a program. Can't you just write the same program in Verilog or whatever? I think the answer is "yes" No. FPGAs are basically big fat lookup tables, some clever partitioning logic, and a boolean function. Inputs and outputs are (from the perspective of the "programmer") simultaneous, and if you want to do any state-keeping, it has to be done in response to some transition (such as a clock pin strobing). State like registers. So you want to implement program registers and make those inputs be address and data lines, decode the instruction, map it to the appropriate internal "registers", then write out the data back to memory (if any), you're talking two transitions (or four if you want to reuse the address/data likes for fetch and load). The speed/heat/power/price at which you can do that is (for the most part) a function of how big that lookup table is. If you can decode a single instruction in 4 steps instead of 1, you usually should because it means you can strobe 4x faster (or everything else will be cheaper, lower-power, cooler, etc). Microcoding is a technique to doing this, but it's also a choice because there are limits to how little-power you can get, or how cheap fabricating any amount of silicon is, or even how low-level you can be meaningfully thinking about solving business problems, otherwise we'd all be using massively-parallel SBNZ-computers that float in the air.

skissane 4y ago
> FPGAs are basically big fat lookup tables I never said anything about FPGAs though. If you are telling me how microcode might be useful in overcoming limitations of FPGAs, I’m not sure what relevance that has to most microprocessors, which aren’t implemented as FPGAs
- geocar 4y ago
  No, but they're a useful target for Verilog, and this limitation is shared by any hardware compute/circuit (I had hoped that would be obvious from the description)
  - skissane 4y ago
    You can implement a CPU completely with random logic, zero microcode - it has been done before. Yes you do end up needing something like extra registers to hold control state - but that’s not microcode