4 ms·

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 i

by 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

by temac 4y ago

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