3 ms·

If I had to list one hundred ways x86 could be improved, not booting in 16-bit mode wouldn't be on it. It's just an incantation. There's no fallout from it. If

If I had to list one hundred ways x86 could be improved, not booting in 16-bit mode wouldn't be on it. It's just an incantation. There's no fallout from it. If we're talking firmware, the gigantic mess that used to be called ACPI, still leave users suffering every day for example.

hinkley 3y ago
I think that depends on if the existence of 16 bit mode has effects on IPC rates of the processor. If it's 2% of instruction cost, then kill it with fire. If it's raising the development cost by 1%, kill it with fire. If it's a fixed cost and isn't hurting anything, then meh.
- userbinator 3y ago
  Unless they want to complete eliminate 16-bit operations, it won't matter. ...and eliminating 16-bit operations would be pure ideologically-driven stupidity, given how many classic RISCs with word-width-operations-only suffered greatly and the ones that survived (like ARM) evolved to add them back in.
  - jcranmer 3y ago
    What they're getting rid of is all of the extra fun memory management modes the x86 processor has, condensing everything down into just the paging mode with extremely gimped segment support that's all that's available in x86-64. That suggests to me that someone within Intel is thinking about basically rewriting the memory subsystem, where having to support all the fun things like real mode or virtual 8086 mode is much more painful. The 16-bit data operations are still around, with the 0x66 prefix, and even the ability to default a segment to not needing the 0x66 prefix to get 16-bit registers may still be around, though I'm not savvy enough on the retained features to say for certain. To be honest, there are two legacy x86 features which I suspect do have a noticeable tax on the support in the execution units: the x87 FPU stuff (due to the 80-bit floating-point types, and a variety of hardware-implemented transcendental instructions that need to be supported), and the legacy addressing modes.
    - userbinator 3y ago
      where having to support all the fun things like real mode or virtual 8086 mode is much more painful If they're going to still support virtualisation to run legacy code, which is what the article is implying, they'll still need the logic to deal with all the existing modes being used inside a VM. ...and those modes are honestly not hard to support. (Protected mode) segmentation is far simpler than paging, and realmode is even easier given that the original 8086 with its 29k transistors could implement it.
      - hinkley 3y ago
        Clock cycles are dictated by the gate timing of the slowest fractional instruction. If they’re getting rid of conditional logic, that could just reduce heat a bit, or if this is now the tall tent pole, it could allow them to clock the chip a little higher at the same gate pitch. Or, they are adding something new that puts them over that budget, and cleaning up the conditional branching lets them stay under it.
      - jcranmer 3y ago
        From what I can tell, they're not supporting them in virtualization. Instead, they're set up to cause processor traps, which the hypervisor could catch and use to emulate those instructions if necessary. > ...and those modes are honestly not hard to support. I have to imagine that there's a decent amount of extra logic in the load/store units to use the current processor mode to work out memory semantics, and now I'm thinking about questions like "what would happen if one thread is in virtual 8086 mode while the hyperthread partner isn't". That's a noticeable burden in things like validation. And even if the implementation of segmentation is simpler than paging, that's not the issue; the issue is that it's a different pathway, and potentially one that cuts deep into the execution unit. If it's the sort of thing where eliminating support for anything other than paging means getting an L1 cache hit back one cycle faster... then sign me up.
NullPrefix 3y ago
You're judging it from the user's perspective (OS developer). Getting rid of 16-bit mode would probably simplify something for the chip manufacturer.
StillBored 3y ago
If we're talking firmware, the gigantic mess that used to be called ACPI, still leave users suffering every day for example. And replace it with what? APM? I'm completely unaware of another power management abstraction that has even a fraction of the capabilities and proven track record. Sure if your apple or IBM you can build a machine with a custom tightly bound firmware/OS/hardware interface that works well. But, if you look at for example the Arm ecosystems attempts to use DT in the linux kernel and manage everything from a heavyweight kernel it is a fools errand. It has successfully been failing for fully 1/2 the lifetime of ACPI. Never mind no one in their right mind designs a system these days where the big cores try to manage their own power/perf curves, nor even modeling the system power/cooling without using a small low power core continuously monitoring and adjusting the hundreds of fine grained power domains on even smaller machines needed to achieve modern perf/power parity. So please explain.

hinkley 3y ago

I think that depends on if the existence of 16 bit mode has effects on IPC rates of the processor. If it's 2% of instruction cost, then kill it with fire. If it's raising the development cost by 1%, kill it with fire. If it's a fixed cost and isn't hurting anything, then meh.

userbinator 3y ago
Unless they want to complete eliminate 16-bit operations, it won't matter. ...and eliminating 16-bit operations would be pure ideologically-driven stupidity, given how many classic RISCs with word-width-operations-only suffered greatly and the ones that survived (like ARM) evolved to add them back in.
- jcranmer 3y ago
  What they're getting rid of is all of the extra fun memory management modes the x86 processor has, condensing everything down into just the paging mode with extremely gimped segment support that's all that's available in x86-64. That suggests to me that someone within Intel is thinking about basically rewriting the memory subsystem, where having to support all the fun things like real mode or virtual 8086 mode is much more painful. The 16-bit data operations are still around, with the 0x66 prefix, and even the ability to default a segment to not needing the 0x66 prefix to get 16-bit registers may still be around, though I'm not savvy enough on the retained features to say for certain. To be honest, there are two legacy x86 features which I suspect do have a noticeable tax on the support in the execution units: the x87 FPU stuff (due to the 80-bit floating-point types, and a variety of hardware-implemented transcendental instructions that need to be supported), and the legacy addressing modes.
  - userbinator 3y ago
    where having to support all the fun things like real mode or virtual 8086 mode is much more painful If they're going to still support virtualisation to run legacy code, which is what the article is implying, they'll still need the logic to deal with all the existing modes being used inside a VM. ...and those modes are honestly not hard to support. (Protected mode) segmentation is far simpler than paging, and realmode is even easier given that the original 8086 with its 29k transistors could implement it.
    - hinkley 3y ago
      Clock cycles are dictated by the gate timing of the slowest fractional instruction. If they’re getting rid of conditional logic, that could just reduce heat a bit, or if this is now the tall tent pole, it could allow them to clock the chip a little higher at the same gate pitch. Or, they are adding something new that puts them over that budget, and cleaning up the conditional branching lets them stay under it.
    - jcranmer 3y ago
      From what I can tell, they're not supporting them in virtualization. Instead, they're set up to cause processor traps, which the hypervisor could catch and use to emulate those instructions if necessary. > ...and those modes are honestly not hard to support. I have to imagine that there's a decent amount of extra logic in the load/store units to use the current processor mode to work out memory semantics, and now I'm thinking about questions like "what would happen if one thread is in virtual 8086 mode while the hyperthread partner isn't". That's a noticeable burden in things like validation. And even if the implementation of segmentation is simpler than paging, that's not the issue; the issue is that it's a different pathway, and potentially one that cuts deep into the execution unit. If it's the sort of thing where eliminating support for anything other than paging means getting an L1 cache hit back one cycle faster... then sign me up.

NullPrefix 3y ago

You're judging it from the user's perspective (OS developer). Getting rid of 16-bit mode would probably simplify something for the chip manufacturer.

StillBored 3y ago

If we're talking firmware, the gigantic mess that used to be called ACPI, still leave users suffering every day for example. And replace it with what? APM? I'm completely unaware of another power management abstraction that has even a fraction of the capabilities and proven track record. Sure if your apple or IBM you can build a machine with a custom tightly bound firmware/OS/hardware interface that works well. But, if you look at for example the Arm ecosystems attempts to use DT in the linux kernel and manage everything from a heavyweight kernel it is a fools errand. It has successfully been failing for fully 1/2 the lifetime of ACPI. Never mind no one in their right mind designs a system these days where the big cores try to manage their own power/perf curves, nor even modeling the system power/cooling without using a small low power core continuously monitoring and adjusting the hundreds of fine grained power domains on even smaller machines needed to achieve modern perf/power parity. So please explain.