4 ms·

> One thing they could do - legacy features (real mode, 16-bit protected mode, V86 mode, etc) are now an optional feature for which you have to pay a premium. T

> One thing they could do - legacy features (real mode, 16-bit protected mode, V86 mode, etc) are now an optional feature for which you have to pay a premium. They could just have a mode which disables them, and fuse that mode on in the factory. With Microsoft’s cooperation, Windows 11 could be made to run on such a CPU without much work. Customers who need them could just emulate them. Almost everyone already does anyway (DOSBox, etc.) Though, honestly, I highly suspect the die space spent to support those features is pretty small, and power dissipation concerns mean that it's quite possible there aren't much better uses for that silicon area.

skissane 4y ago
It inevitably has a cost though, even if at design-time than runtime. Consider a code base filled with numerous legacy features which almost nobody ever uses. Their presence in the code and documentation means it takes longer for people to understand. Adding new features takes more time, because you have to consider how they interact with the legacy ones, and the risk of introducing regressions or security vulnerabilities through those obscure interactions. You need tests for all these legacy features, which makes testing take more time and be more expensive, and people working on newer features break the legacy tests and have to deal with that. Technical debt has a real cost - and why would that be any less true for a CPU defined in Verilog/VHDL than for a programming language? And a feature flag is a good way to get rid of legacy features. First add the flag but leave it on. Then start turning it off by default but let people turn it back on for free. Then start charging people money to have it on. Then remove it entirely, and all the legacy features it gates. It works for software-I can’t see why it couldn’t work for hardware too.
- rep_lodsb 4y ago
  Why charge money for leaving the legacy features enabled (other than "because they can" / cyberpunk dystopia)? If they really are such a security risk, surely enterprise customers would rather pay for the ability to turn them off.
  - skissane 4y ago
    Realistically, they probably won’t charge more money just for this feature. Just limit it to higher priced SKUs. There must be dies being thrown away right now because they work perfectly except for one of these legacy features. If they had SKUs with legacy features fused off, suddenly those dies might become usable. Having lower-end SKUs with some features fused off allows you to use dies in which those features are broken. But, it means you have to fuse them off even on the dies in which they work. Buying a low end CPU and finding that some of them randomly have higher-end features would just be too confusing for everyone.
    - rep_lodsb 4y ago
      Most of a modern x86 die is cache, same as for every other architecture. It's unlikely that there are many dies that have some defect in the legacy microcode and nowhere else. Fundamentally changing the instruction format might save a little bit of space, but then it wouldn't be compatible with x86-64 anymore either.
      - skissane 4y ago
        Are all these legacy features pure microcode? I'm sure they mostly are exactly that, but I would not be surprised if some of the hardwired circuitry's behaviour is influenced by mode bits for legacy features. It seems conceivable that a hardwired circuit could have a flaw which caused it to malfunction when it gets some "legacy mode enabled" signal but otherwise work correctly. You may well be right, that a die being damaged in exactly that way, is rare enough, that the additional yield from being able to use such dies is rather marginal. But I think it would be hard for anyone to know for sure without non-public info. > Fundamentally changing the instruction format might save a little bit of space, but then it wouldn't be compatible with x86-64 anymore either. I wasn't talking about that. A CPU which didn't support real mode, 16-bit segments, etc, would still have the same instruction format, so instruction decode would be largely unchanged. I wonder if we'll ever see a CPU which supports executing both x86 and ARM code, through separate instruction decoders but with a shared execution engine. Of course, there are lots of differences between the two architectures beyond just the instruction decoding, yet in some ways those differences are shrinking (when you look at features like Apple Silicon TSO mode, and Windows 11 ARM64EC architecture).

skissane 4y ago

It inevitably has a cost though, even if at design-time than runtime. Consider a code base filled with numerous legacy features which almost nobody ever uses. Their presence in the code and documentation means it takes longer for people to understand. Adding new features takes more time, because you have to consider how they interact with the legacy ones, and the risk of introducing regressions or security vulnerabilities through those obscure interactions. You need tests for all these legacy features, which makes testing take more time and be more expensive, and people working on newer features break the legacy tests and have to deal with that. Technical debt has a real cost - and why would that be any less true for a CPU defined in Verilog/VHDL than for a programming language? And a feature flag is a good way to get rid of legacy features. First add the flag but leave it on. Then start turning it off by default but let people turn it back on for free. Then start charging people money to have it on. Then remove it entirely, and all the legacy features it gates. It works for software-I can’t see why it couldn’t work for hardware too.

rep_lodsb 4y ago
Why charge money for leaving the legacy features enabled (other than "because they can" / cyberpunk dystopia)? If they really are such a security risk, surely enterprise customers would rather pay for the ability to turn them off.
- skissane 4y ago
  Realistically, they probably won’t charge more money just for this feature. Just limit it to higher priced SKUs. There must be dies being thrown away right now because they work perfectly except for one of these legacy features. If they had SKUs with legacy features fused off, suddenly those dies might become usable. Having lower-end SKUs with some features fused off allows you to use dies in which those features are broken. But, it means you have to fuse them off even on the dies in which they work. Buying a low end CPU and finding that some of them randomly have higher-end features would just be too confusing for everyone.
  - rep_lodsb 4y ago
    Most of a modern x86 die is cache, same as for every other architecture. It's unlikely that there are many dies that have some defect in the legacy microcode and nowhere else. Fundamentally changing the instruction format might save a little bit of space, but then it wouldn't be compatible with x86-64 anymore either.
    - skissane 4y ago
      Are all these legacy features pure microcode? I'm sure they mostly are exactly that, but I would not be surprised if some of the hardwired circuitry's behaviour is influenced by mode bits for legacy features. It seems conceivable that a hardwired circuit could have a flaw which caused it to malfunction when it gets some "legacy mode enabled" signal but otherwise work correctly. You may well be right, that a die being damaged in exactly that way, is rare enough, that the additional yield from being able to use such dies is rather marginal. But I think it would be hard for anyone to know for sure without non-public info. > Fundamentally changing the instruction format might save a little bit of space, but then it wouldn't be compatible with x86-64 anymore either. I wasn't talking about that. A CPU which didn't support real mode, 16-bit segments, etc, would still have the same instruction format, so instruction decode would be largely unchanged. I wonder if we'll ever see a CPU which supports executing both x86 and ARM code, through separate instruction decoders but with a shared execution engine. Of course, there are lots of differences between the two architectures beyond just the instruction decoding, yet in some ways those differences are shrinking (when you look at features like Apple Silicon TSO mode, and Windows 11 ARM64EC architecture).