5 ms·

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

by maxharris 9y ago

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.

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.