3 ms·

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 ext

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.

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.