6 ms·

Since cloud servers are a bigger market than users who want to run an old copy of VisiCalc, why doesn't either Intel or AMD produce a processor line that has no

Since cloud servers are a bigger market than users who want to run an old copy of VisiCalc, why doesn't either Intel or AMD produce a processor line that has none of the old 16 and 32 bit architectures (and long-forgotten vector extensions), implemented in silicon? Why not just make a clean (or as clean as possible) 64 bit x86 processor?

th3typh00n 5y ago
Because the number of transistors used for that functionality is absolutely negligible, so removing it has virtually no benefit.
- Symmetry 5y ago
  The number of transistors sure. The engineer time to design new features that don't interfere with old features is high. The verification time to make sure every combination of features plays sensibly together is extremely high. To the extent that Intel and AMD are limited by the costs of employing and organizing large numbers of engineers it's a big deal. Though that's also the reason they'll never make a second, simplified, core.
  - failwhaleshark 5y ago
    It's never going to happen. The ISA is a hardware contract.
    - PopePompus 5y ago
      When things get to the point where AMD is considering making nonmaskable interrupts maskable (as the article states), maybe it's time to invoke "force majeure".
- PopePompus 5y ago
  Even so, doesn't having a more complex instruction set, festooned with archaic features needed by very few users, increase the attack surface for hacking exploits and increase the likelyhood of bugs being present? Isn't it a bad thing that the full boot process is understood in depth by only a tiny fraction of the persons programming for x86 systems (I'm certainly not one of them)?
  - jcranmer 5y ago
    Not really. Basically none of these features can be used outside of the kernel anyways, which means that the attacker already has far more powerful capabilities they can employ.
  - toast0 5y ago
    As a sibling said, if you can get the cpu into real mode, you can probably do whatever else you want, so it being there isn't a real security worry. Dropping real and virtual mode wouldn't save a whole lot anyway; for the most part, the instruction set is the same, regardless of mode, just register selection is a bit different, and fiddling with segment registers is significantly different. Mostly, the full boot process isn't understood in depth by many people because very few people need to know about it in depth. Really full boot process includes detecting and enabling ram and all that, and there's a handful of companies that provide most of the firmware images for everyone ... OSes usually start from the BIOS boot convention or UEFI, so they don't need to know all that early boot stuff. Well, really, bootloaders start there, OSes can start at multiboot or UEFI if they want to save some work. An SMP OS will still need to know a little bit about real mode though, because application processors (non-boot processors) start in real mode, complete with segmented addresses, and need to get into protected mode themselves.
- failwhaleshark 5y ago
  Yep. Benefit = The cost of minimalism at every expense - the cost of incompatibility (in zillions): breaking things that cannot be rebuilt, breaking every compiler, breaking every debugger, breaking every disassembler, adding more feature flags, and it's no longer the Intel 64 / EMT-32 ISA. Hardware != software.
lizknope 5y ago
You mean like the Intel i860? https://en.wikipedia.org/wiki/Intel_i860 https://en.wikipedia.org/wiki/Intel_i860 Or the Intel Itanium? https://en.wikipedia.org/wiki/Itanium https://en.wikipedia.org/wiki/Itanium Or the AMD Am29000? https://en.wikipedia.org/wiki/AMD_Am29000 https://en.wikipedia.org/wiki/AMD_Am29000 Or the AMD K12 which was a 64-bit ARM? https://www.anandtech.com/show/7990/amd-announces-k12-core-custom-64bit-arm-design-in-2016 https://www.anandtech.com/show/7990/amd-announces-k12-core-c... All of these things were either rejected by the market or didn't even make it to the market. Binary compatibility is one of the major if not the major reason that x86 has hung around so long. In the 1980's and 90's x86 was slower than the RISC workstation competitors but Intel and AMD really took the performance crown around 2000.
- monocasa 5y ago
  No, there's a lot of PCisms that that can be removed and still allow for x86 cores. User code doesn't care about PC compat really anymore (see the PS4 Linux port for the specifics of a non PC x86 platform that runs regular x86 user code like Steam, albeit one arguably worse designed than the PC somehow). Cleaning up ring 0 in a way that ring 3 code can't tell the difference with a vaguely modern kernel could be a huge win.
- fredoralive 5y ago
  I think he's suggesting something more like the 80376, an obscure embedded 386 that booted straight into protected mode. So you'd have an x86-64 CPU that boots straight into Long Mode and thus could remove stuff like real mode and virtual 8086 mode. AFAIK with UEFI it's the boot firmware that handles switching to 32/ 64 bit mode, not the OS loader or kernel, so it would be transparent to the OS and programs. But in order to not break a lot of stuff on desktop Windows (and ancient unmaintained custom software on corprate servers) you'd still have to implement the "32 bit software on 64 bit OS" support. That probably means you don't actually simplfy the CPU much. Of course some x86 extensions do get dropped occasionally, but only things like AMD 3DNow (I guess AMD market share meant few used it anyway) and that Intel transactional memory thing that was just broken.
  - 5y ago
jandrewrogers 5y ago
Intel did this with the cores for the Xeon Phi. While it was x86 compatible, they removed a bunch of the legacy modes.
userbinator 5y ago
Since cloud servers are a bigger market than users who want to run an old copy of VisiCalc Imagine if your VMs, which are being used to run old software, can't be used on cloud servers due to this feature absence. Virtualisation is used extensively for this purpose. The cloud providers certainly wouldn't like that.

th3typh00n 5y ago

Because the number of transistors used for that functionality is absolutely negligible, so removing it has virtually no benefit.

Symmetry 5y ago
The number of transistors sure. The engineer time to design new features that don't interfere with old features is high. The verification time to make sure every combination of features plays sensibly together is extremely high. To the extent that Intel and AMD are limited by the costs of employing and organizing large numbers of engineers it's a big deal. Though that's also the reason they'll never make a second, simplified, core.
- failwhaleshark 5y ago
  It's never going to happen. The ISA is a hardware contract.
  - PopePompus 5y ago
    When things get to the point where AMD is considering making nonmaskable interrupts maskable (as the article states), maybe it's time to invoke "force majeure".
PopePompus 5y ago
Even so, doesn't having a more complex instruction set, festooned with archaic features needed by very few users, increase the attack surface for hacking exploits and increase the likelyhood of bugs being present? Isn't it a bad thing that the full boot process is understood in depth by only a tiny fraction of the persons programming for x86 systems (I'm certainly not one of them)?
- jcranmer 5y ago
  Not really. Basically none of these features can be used outside of the kernel anyways, which means that the attacker already has far more powerful capabilities they can employ.
- toast0 5y ago
  As a sibling said, if you can get the cpu into real mode, you can probably do whatever else you want, so it being there isn't a real security worry. Dropping real and virtual mode wouldn't save a whole lot anyway; for the most part, the instruction set is the same, regardless of mode, just register selection is a bit different, and fiddling with segment registers is significantly different. Mostly, the full boot process isn't understood in depth by many people because very few people need to know about it in depth. Really full boot process includes detecting and enabling ram and all that, and there's a handful of companies that provide most of the firmware images for everyone ... OSes usually start from the BIOS boot convention or UEFI, so they don't need to know all that early boot stuff. Well, really, bootloaders start there, OSes can start at multiboot or UEFI if they want to save some work. An SMP OS will still need to know a little bit about real mode though, because application processors (non-boot processors) start in real mode, complete with segmented addresses, and need to get into protected mode themselves.
failwhaleshark 5y ago
Yep. Benefit = The cost of minimalism at every expense - the cost of incompatibility (in zillions): breaking things that cannot be rebuilt, breaking every compiler, breaking every debugger, breaking every disassembler, adding more feature flags, and it's no longer the Intel 64 / EMT-32 ISA. Hardware != software.

lizknope 5y ago

You mean like the Intel i860? https://en.wikipedia.org/wiki/Intel_i860 https://en.wikipedia.org/wiki/Intel_i860 Or the Intel Itanium? https://en.wikipedia.org/wiki/Itanium https://en.wikipedia.org/wiki/Itanium Or the AMD Am29000? https://en.wikipedia.org/wiki/AMD_Am29000 https://en.wikipedia.org/wiki/AMD_Am29000 Or the AMD K12 which was a 64-bit ARM? https://www.anandtech.com/show/7990/amd-announces-k12-core-custom-64bit-arm-design-in-2016 https://www.anandtech.com/show/7990/amd-announces-k12-core-c... All of these things were either rejected by the market or didn't even make it to the market. Binary compatibility is one of the major if not the major reason that x86 has hung around so long. In the 1980's and 90's x86 was slower than the RISC workstation competitors but Intel and AMD really took the performance crown around 2000.

monocasa 5y ago
No, there's a lot of PCisms that that can be removed and still allow for x86 cores. User code doesn't care about PC compat really anymore (see the PS4 Linux port for the specifics of a non PC x86 platform that runs regular x86 user code like Steam, albeit one arguably worse designed than the PC somehow). Cleaning up ring 0 in a way that ring 3 code can't tell the difference with a vaguely modern kernel could be a huge win.
fredoralive 5y ago
I think he's suggesting something more like the 80376, an obscure embedded 386 that booted straight into protected mode. So you'd have an x86-64 CPU that boots straight into Long Mode and thus could remove stuff like real mode and virtual 8086 mode. AFAIK with UEFI it's the boot firmware that handles switching to 32/ 64 bit mode, not the OS loader or kernel, so it would be transparent to the OS and programs. But in order to not break a lot of stuff on desktop Windows (and ancient unmaintained custom software on corprate servers) you'd still have to implement the "32 bit software on 64 bit OS" support. That probably means you don't actually simplfy the CPU much. Of course some x86 extensions do get dropped occasionally, but only things like AMD 3DNow (I guess AMD market share meant few used it anyway) and that Intel transactional memory thing that was just broken.
- 5y ago

jandrewrogers 5y ago

Intel did this with the cores for the Xeon Phi. While it was x86 compatible, they removed a bunch of the legacy modes.

userbinator 5y ago

Since cloud servers are a bigger market than users who want to run an old copy of VisiCalc Imagine if your VMs, which are being used to run old software, can't be used on cloud servers due to this feature absence. Virtualisation is used extensively for this purpose. The cloud providers certainly wouldn't like that.