2 ms·

This is true for a lot of historical cruft (c.f. segment registers wired to zero in 64 bit mode, likewise there's no reason that calculation shouldn't work sinc

by ajross 4y ago

This is true for a lot of historical cruft (c.f. segment registers wired to zero in 64 bit mode, likewise there's no reason that calculation shouldn't work since you have to have it present in 32 bit protected mode anyway). Presumably AMD wanted to specify only the future-useful subset of the architecture to be usable in long mode so that in the future when people started shipping long mode only CPUs[1] they wouldn't have to bother with the junk. [1] Which never happened, presumably because the transistor overhead of supporting real and 32 bit mode on the monster cores of the modern world was negligible. But you could totally ship a successful processor today that booted in long mode and lacked the ability to transition to real mode.

userbinator 4y ago
64-bit mode could've just been an extension of regular protected mode, using double-wide descriptors of the reserved types that may even have been reserved for that purpose. That would've been the ultimate in backwards compatibility and a logical step. But you could totally ship a successful processor today that booted in long mode and lacked the ability to transition to real mode I don't think so. I certainly wouldn't want one, and neither would a lot of other people. Intel learned that lesson twice --- once with the 80376, and again when it started making x86 smartphone SoCs. No one really wants x86 without the rest of the PC architecture, since then they might as well use something like ARM or even RISC-V instead.
- ajross 4y ago
  Out of curiosity: 1. What software would you want to run that used 286-style segmentation in a 64 bit space? That model had been abandoned long before AMD wrote the x86_64 spec. 2. What 386 protected mode (or unreal mode too, I guess) software are you needing to run such that you wouldn't buy a 64-bit-only CPU? Again, this has been entirely abandoned (with the sole exception of the SMP boot mechanism, which is defined to start in real mode) on modern systems, even at the firmware level.

by ajross 4y ago

userbinator 4y ago

64-bit mode could've just been an extension of regular protected mode, using double-wide descriptors of the reserved types that may even have been reserved for that purpose. That would've been the ultimate in backwards compatibility and a logical step. But you could totally ship a successful processor today that booted in long mode and lacked the ability to transition to real mode I don't think so. I certainly wouldn't want one, and neither would a lot of other people. Intel learned that lesson twice --- once with the 80376, and again when it started making x86 smartphone SoCs. No one really wants x86 without the rest of the PC architecture, since then they might as well use something like ARM or even RISC-V instead.

ajross 4y ago
Out of curiosity: 1. What software would you want to run that used 286-style segmentation in a 64 bit space? That model had been abandoned long before AMD wrote the x86_64 spec. 2. What 386 protected mode (or unreal mode too, I guess) software are you needing to run such that you wouldn't buy a 64-bit-only CPU? Again, this has been entirely abandoned (with the sole exception of the SMP boot mechanism, which is defined to start in real mode) on modern systems, even at the firmware level.