4 ms·

Does this mean they're also looking to rip out 16bit real mode support entirely from their x86/x86_64 CPUs?

by 0x0 9y ago

maxharris 9y ago
I would happily pay more for a computer that lacks support for this mode.
- 0x0 9y ago
  Why?
  - raverbashing 9y ago
    Because it's a piece of hw that's only used for 1s before your OS boots. Wonder why ARM consumes much less than x86? That's one (small) reason why.
    - monocasa 9y ago
      I'd be surprised if 16bit support uses a noticeable amount of power in a running system.
      - wolfgke 9y ago
        > I'd be surprised if 16bit support uses a noticeable amount of power in a running system. For 16 bit you have to strongly distinguish between 16 bit real mode (what DOS ran on by default), 16 bit protected mode (what Windows 3.x and partly Windows 95 ran on) and Virtual 8086 mode (which was for example used under Windows 95 to run DOS applications). Also I think SMM (System Management Mode) also runs 16 bit code. Next: In 32 bit mode, nearly every instruction can be prefixed by 0x67 (I am aware that some instructions use an 0x66 prefix instead - I just want to keep things simple here) that allows one to use 16 bit (protected mode) addressing to be used in 32 bit mode. Except for some very obscure applications that surely does not make sense, but shows how deeply ingrained 16 bit support is in the x86 instruction set. Also: If you prepend an 0x66 prefix to many classic x86 instructions in 32 bit mode, they will do what the instruction would do in 16 bit mode (except for using 32 bit adressing if suitable; but I just explained how this can be changed, too). This is exactly how instructions that use 16 bit registers are encoded. So 16 bit support is deeply ingrained into x86 and cannot be simply removed. And I would bet there exist customers who would be really enraged if Intel or AMD did just remove some of the 16 bit modes, because they have some exotic application that depends on them.
    - jcranmer 9y ago
      The power consumption of the real-address 8086 mode in x86 is probably less than the difference between, say, Cannon Lake and Skylake. What you would end up simplifying is mostly caught up as a few bit-sense lines in the decoder to control some sign-extend/zero-extend units, and these lines aren't being switched. There's no impact outside of the instruction decode/fetch and the load/store units, and these are only minor impacts to what's not really a major power draw in the first place. I will also point out that ARM also has similar 16-bit/32-bit control logic in its ISA: Thumb. So ARM is duplicating this bit of power draw anyways.
      - raverbashing 9y ago
        > There's no impact outside of the instruction decode/fetch and the load/store units But the issue is not only in the processor, it's in having an entire PC-XT available on the hardware so that the bios and boot loader can boot up like it's 30 years ago. (A20 emulation anyone? - ok Haswell removed it. daisy-chained interrupt controllers? DMA controllers from the time ISA buses were all the rage?) Thumb does not deal with 16-bit "mode" it's just an instruction set with 16-bit instructions, but each one corresponds to a 32-bit one. It's really not comparable to 16-bit mode on x86
    - kllrnohj 9y ago
      > Wonder why ARM consumes much less than x86? That's one (small) reason why. Consumes much less what than x86? Power? Quad A57s @ 1.9ghz hits the 7 watt mark. You want performance you pay for it in power. At the end of the day the ISA doesn't actually change any of that. Die size? Sure, but "high end" ARM chips are still pathetic 512kb or 1mb L2 caches with no L3. Pretty much the same as above - you want performance, you pay for it in transistors. ISA doesn't change the end result much. If you want a real fight of ARM vs. X86 just look at the server market where ARM has attempted to challenge Intel. But Xeons have not just better overall performance, but also better performance/watt. It's all about who can make the best transistor, not which ISA is the most elegant or simplest or any of that. Those days are long, long gone. The complexity cost of legacy or "bloated" instructions/features is such an insignificant amount of the total transistors it just doesn't matter to perf or power.
      - lorenzhs 9y ago
        I don’t know the exact numbers off the top of my head, but Apple‘s A-series chips have a lot of cache, something around 8MB in the last generations iirc.
        kllrnohj 9y ago
        Apple's A-series chips aren't small, though. The A10 (14nm) was 125 mm2, about the same size as the mobile quad core Intel 14nm parts.
        lorenzhs 9y ago
        True, the Apple A-series chips are large, but the A10 was built on TSMC's 16nm process, not 14nm. Even TSMC's 10nm process (used for the A11) is barely smaller than Intel's 14nm, these numbers contain a lot of marketing as you surely know: https://en.wikipedia.org/wiki/14_nanometer#Comparison_of_process_nodes https://en.wikipedia.org/wiki/14_nanometer#Comparison_of_pro... and https://en.wikipedia.org/wiki/10_nanometer#10_nm_process_nodes https://en.wikipedia.org/wiki/10_nanometer#10_nm_process_nod... The A11 is only 88mm², with 8MB of cache, compared to the Skylake quad-core i7 CPUs with 122mm² and the same amount of cache (using Intel's 14nm process). The Snapdragon 820 (Samsung 14nm process) also clocked in at 144mm² with only 1.5 MB of cache. Apple's chips aren't the only large ARM chips.
  - maxharris 9y ago
    I want fewer knobs, switches, modes. Focusing on the future and breaking sharply with the past is a feature to me.
  - maxharris 9y ago
    The real advantage to cutting legacy is that it frees up engineers to work on the right problems - current and future needs - instead of verifying that the long tail of ancient stuff still works on every new thing built. What reason is there for legacy support in the hardware and OS when we have all sorts of emulation options already?
    - userbinator 9y ago
      is that it frees up engineers to work on the right problems - current and future needs ...you mean the problems that they themselves introduced by, for example, trying to create this ridiculous complexity of UEFI? That sounds like a make-work situation to me. What reason is there for legacy support in the hardware and OS when we have all sorts of emulation options already? "emulation" is never 100%.
      - maxharris 9y ago
        Nothing lasts forever. Intel architecture will die someday. Hopefully cleaning up a bit will help it live a little longer.
0xcde4c3db 9y ago
I think they'd get pushback on that from users running legacy DOS/Win3.x/Win9x stuff in VMs. Most of those aren't so performance-critical that they really need to run as VT-x guests, but Intel has had multiple run-ins with the perils of "buy our new chip because it will make your applications... uh... slower".
dfox 9y ago
There isn't much reason to do so. Additional resources needed to support 16bit modes probably does not exceed few hundred transistors of logic and bunch of words of microcode. The data path is completely same, there are only few control differences (loads to selector registers set offset=value<<4; limit=0xffff; size=16bit instead of consulting descriptor tables). On the other x86_64 CPU can be significantly simplified by riping out both 16bit and 32bit modes and thus all the selector/descriptor segmentation logic and replacing IDT with something simpler and less general.
- 21 9y ago
  According to Wikipedia Windows 64 bit runs 32 bit apps by switching back to 32 bit mode. > which switches the processor hardware from its 64-bit mode to compatibility mode when it becomes necessary to execute a 32-bit thread, and then handles the switch back to 64-bit mode. https://en.wikipedia.org/wiki/WoW64 https://en.wikipedia.org/wiki/WoW64
  - kobeya 9y ago
    I don’t honk this is correct. Iirc moving to 64 but more is a one way street. Rather, there is a virtual 32 but compatibility mode provided in the 64 bot environment, and that is probably what is being referred to here.
  - 0x0 9y ago
    Isn't it more about just loading cs/ds/es segments with 32bit selectors? For example there's the "heaven's gate" trick on windows to sneak through the wow64 layer directly into the other modes - http://rce.co/knockin-on-heavens-gate-dynamic-processor-mode-switching/ http://rce.co/knockin-on-heavens-gate-dynamic-processor-mode...
  - dfox 9y ago
    "Compatibility mode" is sub-mode of long mode which has limited support for 16/32b i386-style memory segmentation (notably there is no support for vm86 code segments and gate descriptors have different format and can only reference 64bit "segments"). It is clear that AMD's intention for this was to implement just enough of segmentation in long mode to allow compatibility with segment-aware user-space code (eg. mixed 16/32b Windows userspace) but there does not seem to be any OS that actually uses 16bit descriptors in long mode (probably due to the mechanism being significantly different than i386's 16/32 compatibility). For compatibility with "normal" flat address space user space code the whole mechanism could be significantly simpler and have same "segmantation" behavior as 64b mode, have 32b EIP pushed on stack by CALL/RET and trap on anything that tries to load new selector anywhere (ie JMP/CALL/RET FAR, MOV whatever, ?S), even REX prefix could be supported in such an "limited compatibility mode" and we would not have to invent things like x32_abi (which is to some extent the same idea, although with different motivations, ie. run new ABI-incompatible 32b code in 64b mode to gain access to new registers and instructions while having 32b pointers and thus reduced memory footprint).

Does this mean they're also looking to rip out 16bit real mode support entirely from their x86/x86_64 CPUs?

by 0x0 9y ago

Does this mean they're also looking to rip out 16bit real mode support entirely from their x86/x86_64 CPUs?

maxharris 9y ago

I would happily pay more for a computer that lacks support for this mode.

0x0 9y ago
Why?
- raverbashing 9y ago
  Because it's a piece of hw that's only used for 1s before your OS boots. Wonder why ARM consumes much less than x86? That's one (small) reason why.
  - monocasa 9y ago
    I'd be surprised if 16bit support uses a noticeable amount of power in a running system.
    - wolfgke 9y ago
      > I'd be surprised if 16bit support uses a noticeable amount of power in a running system. For 16 bit you have to strongly distinguish between 16 bit real mode (what DOS ran on by default), 16 bit protected mode (what Windows 3.x and partly Windows 95 ran on) and Virtual 8086 mode (which was for example used under Windows 95 to run DOS applications). Also I think SMM (System Management Mode) also runs 16 bit code. Next: In 32 bit mode, nearly every instruction can be prefixed by 0x67 (I am aware that some instructions use an 0x66 prefix instead - I just want to keep things simple here) that allows one to use 16 bit (protected mode) addressing to be used in 32 bit mode. Except for some very obscure applications that surely does not make sense, but shows how deeply ingrained 16 bit support is in the x86 instruction set. Also: If you prepend an 0x66 prefix to many classic x86 instructions in 32 bit mode, they will do what the instruction would do in 16 bit mode (except for using 32 bit adressing if suitable; but I just explained how this can be changed, too). This is exactly how instructions that use 16 bit registers are encoded. So 16 bit support is deeply ingrained into x86 and cannot be simply removed. And I would bet there exist customers who would be really enraged if Intel or AMD did just remove some of the 16 bit modes, because they have some exotic application that depends on them.
  - jcranmer 9y ago
    The power consumption of the real-address 8086 mode in x86 is probably less than the difference between, say, Cannon Lake and Skylake. What you would end up simplifying is mostly caught up as a few bit-sense lines in the decoder to control some sign-extend/zero-extend units, and these lines aren't being switched. There's no impact outside of the instruction decode/fetch and the load/store units, and these are only minor impacts to what's not really a major power draw in the first place. I will also point out that ARM also has similar 16-bit/32-bit control logic in its ISA: Thumb. So ARM is duplicating this bit of power draw anyways.
    - raverbashing 9y ago
      > There's no impact outside of the instruction decode/fetch and the load/store units But the issue is not only in the processor, it's in having an entire PC-XT available on the hardware so that the bios and boot loader can boot up like it's 30 years ago. (A20 emulation anyone? - ok Haswell removed it. daisy-chained interrupt controllers? DMA controllers from the time ISA buses were all the rage?) Thumb does not deal with 16-bit "mode" it's just an instruction set with 16-bit instructions, but each one corresponds to a 32-bit one. It's really not comparable to 16-bit mode on x86
  - kllrnohj 9y ago
    > Wonder why ARM consumes much less than x86? That's one (small) reason why. Consumes much less what than x86? Power? Quad A57s @ 1.9ghz hits the 7 watt mark. You want performance you pay for it in power. At the end of the day the ISA doesn't actually change any of that. Die size? Sure, but "high end" ARM chips are still pathetic 512kb or 1mb L2 caches with no L3. Pretty much the same as above - you want performance, you pay for it in transistors. ISA doesn't change the end result much. If you want a real fight of ARM vs. X86 just look at the server market where ARM has attempted to challenge Intel. But Xeons have not just better overall performance, but also better performance/watt. It's all about who can make the best transistor, not which ISA is the most elegant or simplest or any of that. Those days are long, long gone. The complexity cost of legacy or "bloated" instructions/features is such an insignificant amount of the total transistors it just doesn't matter to perf or power.
    - lorenzhs 9y ago
      I don’t know the exact numbers off the top of my head, but Apple‘s A-series chips have a lot of cache, something around 8MB in the last generations iirc.
      - kllrnohj 9y ago
        Apple's A-series chips aren't small, though. The A10 (14nm) was 125 mm2, about the same size as the mobile quad core Intel 14nm parts.
        lorenzhs 9y ago
        True, the Apple A-series chips are large, but the A10 was built on TSMC's 16nm process, not 14nm. Even TSMC's 10nm process (used for the A11) is barely smaller than Intel's 14nm, these numbers contain a lot of marketing as you surely know: https://en.wikipedia.org/wiki/14_nanometer#Comparison_of_process_nodes https://en.wikipedia.org/wiki/14_nanometer#Comparison_of_pro... and https://en.wikipedia.org/wiki/10_nanometer#10_nm_process_nodes https://en.wikipedia.org/wiki/10_nanometer#10_nm_process_nod... The A11 is only 88mm², with 8MB of cache, compared to the Skylake quad-core i7 CPUs with 122mm² and the same amount of cache (using Intel's 14nm process). The Snapdragon 820 (Samsung 14nm process) also clocked in at 144mm² with only 1.5 MB of cache. Apple's chips aren't the only large ARM chips.
- maxharris 9y ago
  I want fewer knobs, switches, modes. Focusing on the future and breaking sharply with the past is a feature to me.
- maxharris 9y ago
  The real advantage to cutting legacy is that it frees up engineers to work on the right problems - current and future needs - instead of verifying that the long tail of ancient stuff still works on every new thing built. What reason is there for legacy support in the hardware and OS when we have all sorts of emulation options already?
  - userbinator 9y ago
    is that it frees up engineers to work on the right problems - current and future needs ...you mean the problems that they themselves introduced by, for example, trying to create this ridiculous complexity of UEFI? That sounds like a make-work situation to me. What reason is there for legacy support in the hardware and OS when we have all sorts of emulation options already? "emulation" is never 100%.
    - maxharris 9y ago
      Nothing lasts forever. Intel architecture will die someday. Hopefully cleaning up a bit will help it live a little longer.

0xcde4c3db 9y ago

I think they'd get pushback on that from users running legacy DOS/Win3.x/Win9x stuff in VMs. Most of those aren't so performance-critical that they really need to run as VT-x guests, but Intel has had multiple run-ins with the perils of "buy our new chip because it will make your applications... uh... slower".

dfox 9y ago

There isn't much reason to do so. Additional resources needed to support 16bit modes probably does not exceed few hundred transistors of logic and bunch of words of microcode. The data path is completely same, there are only few control differences (loads to selector registers set offset=value<<4; limit=0xffff; size=16bit instead of consulting descriptor tables). On the other x86_64 CPU can be significantly simplified by riping out both 16bit and 32bit modes and thus all the selector/descriptor segmentation logic and replacing IDT with something simpler and less general.

21 9y ago
According to Wikipedia Windows 64 bit runs 32 bit apps by switching back to 32 bit mode. > which switches the processor hardware from its 64-bit mode to compatibility mode when it becomes necessary to execute a 32-bit thread, and then handles the switch back to 64-bit mode. https://en.wikipedia.org/wiki/WoW64 https://en.wikipedia.org/wiki/WoW64
- kobeya 9y ago
  I don’t honk this is correct. Iirc moving to 64 but more is a one way street. Rather, there is a virtual 32 but compatibility mode provided in the 64 bot environment, and that is probably what is being referred to here.
- 0x0 9y ago
  Isn't it more about just loading cs/ds/es segments with 32bit selectors? For example there's the "heaven's gate" trick on windows to sneak through the wow64 layer directly into the other modes - http://rce.co/knockin-on-heavens-gate-dynamic-processor-mode-switching/ http://rce.co/knockin-on-heavens-gate-dynamic-processor-mode...
- dfox 9y ago
  "Compatibility mode" is sub-mode of long mode which has limited support for 16/32b i386-style memory segmentation (notably there is no support for vm86 code segments and gate descriptors have different format and can only reference 64bit "segments"). It is clear that AMD's intention for this was to implement just enough of segmentation in long mode to allow compatibility with segment-aware user-space code (eg. mixed 16/32b Windows userspace) but there does not seem to be any OS that actually uses 16bit descriptors in long mode (probably due to the mechanism being significantly different than i386's 16/32 compatibility). For compatibility with "normal" flat address space user space code the whole mechanism could be significantly simpler and have same "segmantation" behavior as 64b mode, have 32b EIP pushed on stack by CALL/RET and trap on anything that tries to load new selector anywhere (ie JMP/CALL/RET FAR, MOV whatever, ?S), even REX prefix could be supported in such an "limited compatibility mode" and we would not have to invent things like x32_abi (which is to some extent the same idea, although with different motivations, ie. run new ABI-incompatible 32b code in 64b mode to gain access to new registers and instructions while having 32b pointers and thus reduced memory footprint).