5 ms·

This may be an unpopular opinion, but making ancient x86 features unreliable strikes me as a good thing. Virtual 8086 mode is an awful virtualization solution,

This may be an unpopular opinion, but making ancient x86 features unreliable strikes me as a good thing. Virtual 8086 mode is an awful virtualization solution, as you can't enter protected mode from within it. This makes it only good for running a subset of DOS apps: either real-mode-only apps or those written to an unspecified subset of DPMI [1]. Ryzen CPUs are easily fast enough to emulate them. And if that's not enough, x86 has had real virtualization for years now, with a functioning protected mode (and long mode!) in addition to real mode. We're long overdue for a simplification of the PC platform. Having CPUs out there with broken legacy features accelerates the migration away from those features. Hopefully this leads to dropping them outright at some point. [1]: https://en.wikipedia.org/wiki/DOS_Protected_Mode_Interface#History https://en.wikipedia.org/wiki/DOS_Protected_Mode_Interface#H...

yuhong 10y ago
I think this is just a bug though. But yes, I have been thinking of creating a new version of x86 that drops things like segmentation, real mode, virtual 8086 mode, and 16-bit protected mode.
- pcwalton 10y ago
  Right, I know it's not intentional. My point is that this bug has unintended benefits. :)
- yjftsjthsd-h 10y ago
  Keep in mind that if you drop the old stuff, you'll have to provide a bootloader and even then it'll be weird; modern systems still boot in 16 bits, bootstrap in 32 bit mode, then configure 64 bit. Unless UEFI fixed that madness?
  - yuhong 10y ago
    Yes it did.
  - pcwalton 10y ago
    UEFI starts you off in protected mode or long mode with identity paging. It even lets you package up your loader as a PE file.
  - throwaway91111 10y ago
    If by "modern" you mean "EFI" you are incorrect. A traditional BIOS is hardly suitable for describing a "modern" firmware; for chrissake it doesn't even use 32 bits!
  - JoshTriplett 10y ago
    The processor itself still boots up in 16-bit mode. UEFI does switch into 64-bit mode before booting an OS loader, but that doesn't mean the processor itself starts in 64-bit mode.
  - valarauca1 10y ago
    UEFI can drop you directly in 64bit mode. The problem is it uses a different memory map than 32bit mode so a lot of write your own os manuals are just flat wrong.
  - mkup 10y ago
    BIOS itself can be implemented as 32-bit code, which contains software emulator of 16-bit code. This emulator runs until CPU is switched to 32-bit protected mode by OS bootloader.
- userbinator 10y ago
  Coincidentally I've also thought about creating a "better x86", but in the opposite direction: on the basis that segmentation is extremely powerful and useful, I think it would've been better for all the various virtualisation extensions to be based on the same model that V86 and protected mode started: segment descriptors of different types. That would allow V86, 16, 32, and 64-bit (using "double-wide" descriptors, to allow a 64-bit base and limit to fit) protected mode "tasks" or VMs to coexist completely, and the OS to switch between them easily. There are enough reserved spaces in the existing specification to allow these to fit nicely (in fact, what I came up with fits so neatly that I wonder if Intel had originally envisioned them for this purpose, if AMD hadn't beaten them with AMD64.) Instead, now we have partially-backwards-compatible (and even slightly different) AMD64/Intel64 and at least two non-interoperable virtualisation extensions (AMD-V, VT-x).
  - pcwalton 10y ago
    If you're going to create a wildly incompatible "better x86", just start with a RISC design and be done with it. Compatibility with modern x86 OS's is the reason for x86's existence (note that v8086 mode is not required for this). Drop that and you might as well just fix all the other problems with the ISA while you're at it.
    - andy_ppp 10y ago
      I'd be interested to know how much ARM have an advantage here in terms of their ISA? Presumably if more resources were dedicated to it, ARM cpus could be quite a lot faster than x86?
      - pcwalton 10y ago
        I doubt it. For one, 32-bit ARM is pretty complex too (though 64-bit ARM is a very nice simplification). More importantly, though, you can overcome the x86 complexity by simply throwing enormous manpower at the problem, and that is what Intel has done over the years. (That doesn't mean the complexity is justified, just that it can be overcome. I think that people often assume that x86's dominance means that there's something inherently amazing about x86 from a microarchitectural point of view. That isn't true; rather it's simply that x86/Windows has historically earned Intel so much revenue that they've been able to fund the manpower needed to keep it alive and on top.)
theparanoid 10y ago
VME is an optional feature indicated by a CPUID flag. AMD could have simple not supported the feature flag.
- mastax 10y ago
  Perhaps they'll submit a microcode update which does that. (assuming they can do that with microcode, but can't fix the problem with it)
rdmsr 10y ago
One of the big selling points of x86 is backwards compatibility. If you have some OS from 1990 you can still run it (without emulation or virtualization, so long as it doesn't depend on clock speed), which is pretty crazy. Slight aside, there are a lot of reasons that Itanium failed, but certainly one of them was lack of backwards compatibility.
- dom0 10y ago
  > Slight aside, there are a lot of reasons that Itanium failed, but certainly one of them was lack of backwards compatibility. Itanium did not aim at the x86 market. The x86 translation layer was retrospectively seen as a mistake as well, because it wasn't relevant, but required transistors that limited the design's performance overall, which was relevant.
  - cwyers 10y ago
    > Itanium did not aim at the x86 market. Maybe not. But x86 certainly took over the market Itanium was aiming for.
    - nine_k 10y ago
      x86 did not. x64 did.
      - cwyers 10y ago
        All 16 and 32 bit x86 code is valid on x64. It's an extension, not a new ISA.
        geezerjay 10y ago
        You got it all backwards. AMD64 is a complete revamp which happens to support x86 in its legacy mode. Server people care for 64-bit address spaces, and that's a feature introduced by AMD64 which is not available in x86.
- 10y ago
johncolanduoni 10y ago
Is there any decent estimate as to how much silicon you could expect to save by dropping stuff that was long ago shunted to microcode?
- pcwalton 10y ago
  It's not so much silicon as engineering and maintenance time keeping all that stuff working.
cratermoon 10y ago
I find it somewhat ironic (apropos?) that this article is on OS/2 Museum.
gciruelos 10y ago
This a thousand times. Also, its usually Intel's policy to have a (very) strong backwards compatiblity. See the A20 line for a ridiculous example. But AMD has always been less strict on this issues, and I'm glad they aren't. This is good news. And despite all that, as you say, a new architecture is badly needed.

yuhong 10y ago

I think this is just a bug though. But yes, I have been thinking of creating a new version of x86 that drops things like segmentation, real mode, virtual 8086 mode, and 16-bit protected mode.

pcwalton 10y ago
Right, I know it's not intentional. My point is that this bug has unintended benefits. :)
yjftsjthsd-h 10y ago
Keep in mind that if you drop the old stuff, you'll have to provide a bootloader and even then it'll be weird; modern systems still boot in 16 bits, bootstrap in 32 bit mode, then configure 64 bit. Unless UEFI fixed that madness?
- yuhong 10y ago
  Yes it did.
- pcwalton 10y ago
  UEFI starts you off in protected mode or long mode with identity paging. It even lets you package up your loader as a PE file.
- throwaway91111 10y ago
  If by "modern" you mean "EFI" you are incorrect. A traditional BIOS is hardly suitable for describing a "modern" firmware; for chrissake it doesn't even use 32 bits!
- JoshTriplett 10y ago
  The processor itself still boots up in 16-bit mode. UEFI does switch into 64-bit mode before booting an OS loader, but that doesn't mean the processor itself starts in 64-bit mode.
- valarauca1 10y ago
  UEFI can drop you directly in 64bit mode. The problem is it uses a different memory map than 32bit mode so a lot of write your own os manuals are just flat wrong.
- mkup 10y ago
  BIOS itself can be implemented as 32-bit code, which contains software emulator of 16-bit code. This emulator runs until CPU is switched to 32-bit protected mode by OS bootloader.
userbinator 10y ago
Coincidentally I've also thought about creating a "better x86", but in the opposite direction: on the basis that segmentation is extremely powerful and useful, I think it would've been better for all the various virtualisation extensions to be based on the same model that V86 and protected mode started: segment descriptors of different types. That would allow V86, 16, 32, and 64-bit (using "double-wide" descriptors, to allow a 64-bit base and limit to fit) protected mode "tasks" or VMs to coexist completely, and the OS to switch between them easily. There are enough reserved spaces in the existing specification to allow these to fit nicely (in fact, what I came up with fits so neatly that I wonder if Intel had originally envisioned them for this purpose, if AMD hadn't beaten them with AMD64.) Instead, now we have partially-backwards-compatible (and even slightly different) AMD64/Intel64 and at least two non-interoperable virtualisation extensions (AMD-V, VT-x).
- pcwalton 10y ago
  If you're going to create a wildly incompatible "better x86", just start with a RISC design and be done with it. Compatibility with modern x86 OS's is the reason for x86's existence (note that v8086 mode is not required for this). Drop that and you might as well just fix all the other problems with the ISA while you're at it.
  - andy_ppp 10y ago
    I'd be interested to know how much ARM have an advantage here in terms of their ISA? Presumably if more resources were dedicated to it, ARM cpus could be quite a lot faster than x86?
    - pcwalton 10y ago
      I doubt it. For one, 32-bit ARM is pretty complex too (though 64-bit ARM is a very nice simplification). More importantly, though, you can overcome the x86 complexity by simply throwing enormous manpower at the problem, and that is what Intel has done over the years. (That doesn't mean the complexity is justified, just that it can be overcome. I think that people often assume that x86's dominance means that there's something inherently amazing about x86 from a microarchitectural point of view. That isn't true; rather it's simply that x86/Windows has historically earned Intel so much revenue that they've been able to fund the manpower needed to keep it alive and on top.)

theparanoid 10y ago

VME is an optional feature indicated by a CPUID flag. AMD could have simple not supported the feature flag.

mastax 10y ago
Perhaps they'll submit a microcode update which does that. (assuming they can do that with microcode, but can't fix the problem with it)

rdmsr 10y ago

One of the big selling points of x86 is backwards compatibility. If you have some OS from 1990 you can still run it (without emulation or virtualization, so long as it doesn't depend on clock speed), which is pretty crazy. Slight aside, there are a lot of reasons that Itanium failed, but certainly one of them was lack of backwards compatibility.

dom0 10y ago
> Slight aside, there are a lot of reasons that Itanium failed, but certainly one of them was lack of backwards compatibility. Itanium did not aim at the x86 market. The x86 translation layer was retrospectively seen as a mistake as well, because it wasn't relevant, but required transistors that limited the design's performance overall, which was relevant.
- cwyers 10y ago
  > Itanium did not aim at the x86 market. Maybe not. But x86 certainly took over the market Itanium was aiming for.
  - nine_k 10y ago
    x86 did not. x64 did.
    - cwyers 10y ago
      All 16 and 32 bit x86 code is valid on x64. It's an extension, not a new ISA.
      - geezerjay 10y ago
        You got it all backwards. AMD64 is a complete revamp which happens to support x86 in its legacy mode. Server people care for 64-bit address spaces, and that's a feature introduced by AMD64 which is not available in x86.
10y ago

johncolanduoni 10y ago

Is there any decent estimate as to how much silicon you could expect to save by dropping stuff that was long ago shunted to microcode?

pcwalton 10y ago
It's not so much silicon as engineering and maintenance time keeping all that stuff working.

cratermoon 10y ago

I find it somewhat ironic (apropos?) that this article is on OS/2 Museum.

gciruelos 10y ago

This a thousand times. Also, its usually Intel's policy to have a (very) strong backwards compatiblity. See the A20 line for a ridiculous example. But AMD has always been less strict on this issues, and I'm glad they aren't. This is good news. And despite all that, as you say, a new architecture is badly needed.