9 ms·

Envisioning a Simplified Intel Architecture

117 points by ruik 3y ago

ngneer 3y ago
The only thing growing faster than the number of transistors is the number of pages in the specification. Ditching legacy is a good thing.
- userbinator 3y ago
  You mean the number of pages in the specification for the newly added features.
- tedunangst 3y ago
  This would be an interesting claim to back up with real numbers.
wuming2 3y ago
Legacy code has still important real-life functions to drive. That is clear. That Intel has to thread carefully to dump in-hardware 16 bit compatibility mode in 2023 is just sad. I can also see why who does not have to deal with so much baggage on their shoulders is capable of being much more nimble and drive innovation. Finally I can now better understand why Apple dumps an ISA every decade or so.
loeg 3y ago
For those truly too lazy to click through to the article, x86-S stands for "simplified," with the idea being to boot directly into 64-bit mode instead of booting into 16-bit and bootstrapping to 64-bit mode. 16-bit mode would be removed entirely. It's not clear to me if 32-bit mode would be axed as well, or if it would be retained (maybe partially).
- KerrAvon 3y ago
  The PDF goes into detail on this. tl;dr: > 16-bit and 32-bit protected mode are not supported anymore and cannot be entered. The CPU always operates in long mode. The 32-bit submode of Intel64 (compatibility mode) still exists.
  - dathinab 3y ago
    Yes but there is a bit of a catcher due to some 32bit programs abusing certain instructions created for handling segmentation. And segmentation support will be partially removed. But no idea if the instruction in question will be gone.
    - anticensor 3y ago
      Removed instructions and pseudocode of changing instructions are explicitly documented.
- aforty 3y ago
  It seemed pretty obvious to me from one of the graphics that they would remove 32-bit mode as well.
  - loeg 3y ago
    > It seemed pretty obvious to me from one of the graphics that they would remove 32-bit mode as well. I don't believe it's that simple (or obvious, since you seem to be mistaken).
  - dathinab 3y ago
    If you mean the graphics relatively at the beginning then no, they refer to boot phases and OS level stuff but that's not fully the same as what you need to run 32bit applications in a 64bit OS.
- jcranmer 3y ago
  > It's not clear to me if 32-bit mode would be axed as well, or if it would be retained (maybe partially). I've been reading the detailed pdf to see more details. It looks to me like 32-bit mode, specifically in the sense of a 32-bit distribution of modern software, is being retained. Segments would be converted more towards their 64-bit extremely attenuated mode, rather than the more robust functionality they have right now. So most 32-bit software shouldn't be affected, unless you're getting really dirty with the segmentation features or trying to support something like Win16.
  - peterfirefly 3y ago
    > Segments would be converted more towards their 64-bit extremely attenuated mode, rather than the more robust functionality they have right now. Which, ten years down the line, should free up a bit more opcode space when they decide to no longer support CS/DS/ES/SS segment prefixes. The space could be used for instructions that are the same in 32-bit and 64-bit modes. The primary ("first byte") opcode space is quite busy in 32-bit mode. Intel and AMD figured out a way to "hide" extra instruction prefixes in illegal modes of certain 16/32-bit instructions. Intel did this with the VEX prefix and AMD did it with the XOP prefix. The instructions they chose were LES/LDS and POP. This is the reason why some of the bits in those multi-byte prefixes have to be inverted, btw. Having 4 clean bytes available with no need for such silly games should prove useful in the future. The 4 string I/O instructions they suggest removing will be useful immediately. Removing all ring 3 I/O instructions (also part of the plan) will free up 8 further bytes in the primary opcode map for user space code. This could perhaps be used to provide shorter aliases of certain existing encodings -- so the instructions in question would still be available for kernels but applications would see better encoding density. And then there is the 67h byte being freed as well due to removing address size overrides. If they are sensible, they will also remove the BOUND instruction from 32-bit mode, but that is not in the current version of the plan. So what are the benefits? Free space in the primary opcode map => better encoding density... and they might not be doing this to give us shorter programs. They might be doing this so the parallel instruction decoders can handle more instructions per cycle. Getting rid of 16-bit data will make the data flow engine in future CPUs simpler (no more partial register stalls). They also get to remove lots and lots of special cases that undoubtedly cost engineering time and validation time.
- muricula 3y ago
  Looks like you will still be able to run 32 bit user mode applications under a 64 bit kernel. I'm not sure, but I think 32 bit guest kernels get the ax as well. " 3.3 Removal of 16-Bit and 32-Bit Protected Mode 16-bit and 32-bit protected mode are not supported anymore and cannot be entered. The CPU always operates in long mode. The 32-bit submode of Intel64 (compatibility mode) still exists. ... "
  - jcranmer 3y ago
    > I'm not sure, but I think 32 bit guest kernels get the ax as well. This is somewhat beyond my knowledge of system programming, but my read is that it's just possible to support 32-bit guest kernels in the VM with some more emulation of the de-supported instructions. I don't know how many of those instructions already cause VM exits.
- xorcist 3y ago
  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.
- AtlasBarfed 3y ago
  Ok, so maybe you do that in boot order or some boot motdes. But ... remove it? There is SO MUCH silicon these days, honestly I think CPUs should start putting instruction set compatibility cores in, so you still dedicate .5% to a 16 bit compatibility core, 1% to the 32 bit mode, and maybe even an ARM mode. Honestly, since all CPUs are basically fronted by microcode, why can't modern CPU microcode be compatible with multiple instruction sets? Or provide some sort of programmable microcode section so emulators aren't done in software? While I'm bitching, what happened to actually running multiple OSes at once? I have like 16 cores, gigabytes of RAM, multiple display outputs ... why can't I actually run both Linux and Windows and OSX all at once without some bad virtualization container inside one overarching OS? Like, can't Intel manage that with chipset and CPU logic? Intel (and AMD) are DESPERATE to figure out things to get people to use all their extra cores and silicon for. Well, how about making multiple OS on the same machine an actually pleasant experience? Hell, I would love to run a smartphone OS as well.
  - circuit10 3y ago
    > why can't modern CPU microcode be compatible with multiple instruction sets? Nvidia did something sort of similar to this, but couldn't get licensing to use x86. https://en.wikipedia.org/wiki/Project_Denver https://en.wikipedia.org/wiki/Project_Denver
  - StillBored 3y ago
    why can't I actually run both Linux and Windows and OSX all at once without some bad virtualization container inside one overarching OS? Like, can't Intel manage that with chipset and CPU logic? Sounds like what you want is a LPAR or proper type 1 hypervisor, which despite everyone claiming to be type 1 none of them really are. And this is largely caused by the various device HW standards on the PC not natively supporting virtualization (or like nvidia charging extra for SRIOV functionality on their GPUs). So what happens is that all these hypervisors need something like VirtIo or hypervisor emulation of devices (ex e1000/ne2000, sb16, etc) to provide generic storage/networking/display/input devices on top of devices which don't themselves provide any virtualization support. Which in PC land is pretty much everything that doesn't support SRIOV. Which in turn means that a heavyweight OS +driver stack is required to manage the HW. So, you could build a PC based LPAR hypervisor. It would just be limited to the SRIOV capable devices, or plugging in piles of adapters, each one uniquely bound to a single partition. Ex: https://www.hitachi.com/rev/pdf/2012/r2012_02_104.pdf https://www.hitachi.com/rev/pdf/2012/r2012_02_104.pdf
jhallenworld 3y ago
This makes no sense to me. Backward compatibility is a huge competitive advantage for Intel, and IMHO, it's royally messed up that vm86 mode doesn't work in 64-bit mode. One DOS application I use was hurt by this: "old DOS OrCAD". It works well in Windows-XP on a 32-bit machine, but does not work at all in 64-bit Windows. (It's actually a 32-bit DPMI program and has drivers to use Windows GDI so you don't have to mess around with drivers). More evidence: IBM 360 mainframe software still works in Z/OS. It might be worth it for non-generic computing devices like cell phones, but Intel missed the boat there already.
- manuelabeledo 3y ago
  Legacy systems and architectures can’t be around forever. How many people in the PC market still use 16-bit applications?
  - jhallenworld 3y ago
    >Legacy systems and architectures can’t be around forever. Why not? The bits don't decay.. Yes, this leads to an architectural mess, but I'm talking about a competitive business advantage.
    - manuelabeledo 3y ago
      > Why not? > Yes, this leads to an architectural mess Right there. There's no notable advantage in supporting a very small minority of the applications out there, at the cost of keeping units useless for the 99%.
      - bear8642 3y ago
        > There's no notable advantage... Potentially one if a large customer's paying you for it. At work, I'm helping a client upgrade from a decade old version (v12) of our product and having to copy over the switches to keep the even older (v11 and previous) behaviours
formerly_proven 3y ago
> Since its introduction over 20 years ago, the Intel® 64 architecture became the dominant operating mode. Okay that's a bit heavy on the retcon, don't you think?
- r00fus 3y ago
  Why? Because it's really just AMD-64?
  - dathinab 3y ago
    probably but also it's a stretch in general as for personal computers arm is the dominant platform since years (there are way more phones, tablets, etc. then x86 laptops/desktops by now, all of which fit the original definition of personal computer)
    - epylar 3y ago
      It's saying that the 64-bit mode became dominant over other Intel modes.
  - kevin_thibedeau 3y ago
    "Intel Architecture 64" is Itanium. Calling x64 "Intel 64 Architecture" is like MS trying to steal the thunder of Open Office ODF with OOXML.
AdamH12113 3y ago
> Since its introduction over 20 years ago, the Intel® 64 architecture became the dominant operating mode. *cough*[1] [1] https://en.wikipedia.org/wiki/X86-64#History https://en.wikipedia.org/wiki/X86-64#History
- mananaysiempre 3y ago
  I guess we should be thankful they aren’t still calling it EM64T :) I’ve also heard that the term AMD64 also originated from marketing—the internal name during development was x86-64 (which everybody but Microsoft ended up calling it anyway).
  - deaddodo 3y ago
    "amd64" is the official name, per AMD; just as "ia32" is the official name of x86-32, per Intel. The fact that ia32 (and it's sub-classifiers: i386, i486, etc) is still somewhat used, while amd64 has almost completely disappeared is 100% due to Intel's marketing shenanigans in the 00s.
    - circuit10 3y ago
      I see amd64 more often than I see ia32
  - kinghajj 3y ago
    `amd64` is still what Debian and Kubernetes use.
    - IntelMiner 3y ago
      Good fun when my dyslexia misreads "arm64" as "amd64" or vice-versa when going to grab software these days :(
      - post-it 3y ago
        It's happened to me at least twice.
dathinab 3y ago
64Bit (OS) only and kicking out legacy cruft which doesn't just add complexity but also can in some edge cases can make security harder sound like a very sane idea, just maybe kinda late. I mean they probably could have started pushing this in some areas, like server and high-end CPUS, like 5-10years ago.
userbinator 3y ago
Do not want. Did they not learn from the https://en.wikipedia.org/wiki/Intel_80376 https://en.wikipedia.org/wiki/Intel_80376 or the infamous Itanic? The almost 50 years of backwards compatibility (along with the accompanying creation of a huge amount of documentation) is one of the strongest reasons for choosing the x86/PC. With each feature removal, they weaken that argument and push their (prospective) customers towards reconsidering all the other competitive CPUs out there like ARM, MIPS, RISC-V, etc. that are not distant in performance. Intel has made SoCs for phones, tablets, and other miscellaneous devices, but they weren't PC-compatible. Not surprisingly, they were not well-received. Related: https://news.ycombinator.com/item?id=8091290 https://news.ycombinator.com/item?id=8091290 Maybe it's time for a CISC-V...? Edit: apparently respecting history is not a popular opinion.
- snvzz 3y ago
  >Maybe it's time for a CISC-V...? I believe the only path forward for x86 is to be a "x86 accelerator", a x86 mode in some future AMD/Intel RISC-V processors, perhaps limited to unprivileged "usermode". Easing the transition until x86 can be relegated to emulation.
  - userbinator 3y ago
    Easing the transition until x86 can be relegated to emulation. The devil reveals itself. Competitors have infected Intel and are trying to destroy it from within. x86 without the legacy is just another ISA, and Intel is going to lose if it tries to go down that path.
    - mepian 3y ago
      Intel is going to lose because it ditched Ring 1 and 2, sure.
      - userbinator 3y ago
        ...and everything else that made the PC great.
karmakaze 3y ago
I can certainly see how this is beneficial. At the same time it seems like it's a local optimum, to be eclipsed by other architectures. How much software really depends on 64-bit x86 architecture? And for how long? A large amount of server software can be reasonably ported to a new architecture. New platforms can adopt new architectures (phone/tablet, AR/VR). General purpose software like a web browser abstracts hardware, as does very popular software (as Facebook had, and WeChat does). Apple hasn't been tied to architectures and transitioned a number of times, always optimizing the whole rather than optimizing intermediate/stationary fixed points. If Intel is to make it to the next phase, it needs more than incremental improvements to compete. I hope that there's a path/future for AMD and Intel to evolve x86 and thrive but it won't be a given or easy.
ksec 3y ago
> Intel is currently investigating for a 64-bit mode-only architecture referred to as x86S I wish AMD had started this instead of Intel so they could call it AE86.
ksec 3y ago
I wonder if Intel could open up x86s ISA. They need to transition to Foundry and there is no going back. Might as well open up x86s.
RecycledEle 3y ago
I said in 1994 that when Moore's Law finally stopped, we could go back and clean up all our hasty patches. Maybe Moore's Law really is dead. /tears for the end of Moore's Law, just shortly after that great man passed away.

117 points by ruik 3y ago

The only thing growing faster than the number of transistors is the number of pages in the specification. Ditching legacy is a good thing.

userbinator 3y ago
You mean the number of pages in the specification for the newly added features.
tedunangst 3y ago
This would be an interesting claim to back up with real numbers.

wuming2 3y ago

Legacy code has still important real-life functions to drive. That is clear. That Intel has to thread carefully to dump in-hardware 16 bit compatibility mode in 2023 is just sad. I can also see why who does not have to deal with so much baggage on their shoulders is capable of being much more nimble and drive innovation. Finally I can now better understand why Apple dumps an ISA every decade or so.

loeg 3y ago

For those truly too lazy to click through to the article, x86-S stands for "simplified," with the idea being to boot directly into 64-bit mode instead of booting into 16-bit and bootstrapping to 64-bit mode. 16-bit mode would be removed entirely. It's not clear to me if 32-bit mode would be axed as well, or if it would be retained (maybe partially).

KerrAvon 3y ago
The PDF goes into detail on this. tl;dr: > 16-bit and 32-bit protected mode are not supported anymore and cannot be entered. The CPU always operates in long mode. The 32-bit submode of Intel64 (compatibility mode) still exists.
- dathinab 3y ago
  Yes but there is a bit of a catcher due to some 32bit programs abusing certain instructions created for handling segmentation. And segmentation support will be partially removed. But no idea if the instruction in question will be gone.
  - anticensor 3y ago
    Removed instructions and pseudocode of changing instructions are explicitly documented.
aforty 3y ago
It seemed pretty obvious to me from one of the graphics that they would remove 32-bit mode as well.
- loeg 3y ago
  > It seemed pretty obvious to me from one of the graphics that they would remove 32-bit mode as well. I don't believe it's that simple (or obvious, since you seem to be mistaken).
- dathinab 3y ago
  If you mean the graphics relatively at the beginning then no, they refer to boot phases and OS level stuff but that's not fully the same as what you need to run 32bit applications in a 64bit OS.
jcranmer 3y ago
> It's not clear to me if 32-bit mode would be axed as well, or if it would be retained (maybe partially). I've been reading the detailed pdf to see more details. It looks to me like 32-bit mode, specifically in the sense of a 32-bit distribution of modern software, is being retained. Segments would be converted more towards their 64-bit extremely attenuated mode, rather than the more robust functionality they have right now. So most 32-bit software shouldn't be affected, unless you're getting really dirty with the segmentation features or trying to support something like Win16.
- peterfirefly 3y ago
  > Segments would be converted more towards their 64-bit extremely attenuated mode, rather than the more robust functionality they have right now. Which, ten years down the line, should free up a bit more opcode space when they decide to no longer support CS/DS/ES/SS segment prefixes. The space could be used for instructions that are the same in 32-bit and 64-bit modes. The primary ("first byte") opcode space is quite busy in 32-bit mode. Intel and AMD figured out a way to "hide" extra instruction prefixes in illegal modes of certain 16/32-bit instructions. Intel did this with the VEX prefix and AMD did it with the XOP prefix. The instructions they chose were LES/LDS and POP. This is the reason why some of the bits in those multi-byte prefixes have to be inverted, btw. Having 4 clean bytes available with no need for such silly games should prove useful in the future. The 4 string I/O instructions they suggest removing will be useful immediately. Removing all ring 3 I/O instructions (also part of the plan) will free up 8 further bytes in the primary opcode map for user space code. This could perhaps be used to provide shorter aliases of certain existing encodings -- so the instructions in question would still be available for kernels but applications would see better encoding density. And then there is the 67h byte being freed as well due to removing address size overrides. If they are sensible, they will also remove the BOUND instruction from 32-bit mode, but that is not in the current version of the plan. So what are the benefits? Free space in the primary opcode map => better encoding density... and they might not be doing this to give us shorter programs. They might be doing this so the parallel instruction decoders can handle more instructions per cycle. Getting rid of 16-bit data will make the data flow engine in future CPUs simpler (no more partial register stalls). They also get to remove lots and lots of special cases that undoubtedly cost engineering time and validation time.
muricula 3y ago
Looks like you will still be able to run 32 bit user mode applications under a 64 bit kernel. I'm not sure, but I think 32 bit guest kernels get the ax as well. " 3.3 Removal of 16-Bit and 32-Bit Protected Mode 16-bit and 32-bit protected mode are not supported anymore and cannot be entered. The CPU always operates in long mode. The 32-bit submode of Intel64 (compatibility mode) still exists. ... "
- jcranmer 3y ago
  > I'm not sure, but I think 32 bit guest kernels get the ax as well. This is somewhat beyond my knowledge of system programming, but my read is that it's just possible to support 32-bit guest kernels in the VM with some more emulation of the de-supported instructions. I don't know how many of those instructions already cause VM exits.
xorcist 3y ago
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.
AtlasBarfed 3y ago
Ok, so maybe you do that in boot order or some boot motdes. But ... remove it? There is SO MUCH silicon these days, honestly I think CPUs should start putting instruction set compatibility cores in, so you still dedicate .5% to a 16 bit compatibility core, 1% to the 32 bit mode, and maybe even an ARM mode. Honestly, since all CPUs are basically fronted by microcode, why can't modern CPU microcode be compatible with multiple instruction sets? Or provide some sort of programmable microcode section so emulators aren't done in software? While I'm bitching, what happened to actually running multiple OSes at once? I have like 16 cores, gigabytes of RAM, multiple display outputs ... why can't I actually run both Linux and Windows and OSX all at once without some bad virtualization container inside one overarching OS? Like, can't Intel manage that with chipset and CPU logic? Intel (and AMD) are DESPERATE to figure out things to get people to use all their extra cores and silicon for. Well, how about making multiple OS on the same machine an actually pleasant experience? Hell, I would love to run a smartphone OS as well.
- circuit10 3y ago
  > why can't modern CPU microcode be compatible with multiple instruction sets? Nvidia did something sort of similar to this, but couldn't get licensing to use x86. https://en.wikipedia.org/wiki/Project_Denver https://en.wikipedia.org/wiki/Project_Denver
- StillBored 3y ago
  why can't I actually run both Linux and Windows and OSX all at once without some bad virtualization container inside one overarching OS? Like, can't Intel manage that with chipset and CPU logic? Sounds like what you want is a LPAR or proper type 1 hypervisor, which despite everyone claiming to be type 1 none of them really are. And this is largely caused by the various device HW standards on the PC not natively supporting virtualization (or like nvidia charging extra for SRIOV functionality on their GPUs). So what happens is that all these hypervisors need something like VirtIo or hypervisor emulation of devices (ex e1000/ne2000, sb16, etc) to provide generic storage/networking/display/input devices on top of devices which don't themselves provide any virtualization support. Which in PC land is pretty much everything that doesn't support SRIOV. Which in turn means that a heavyweight OS +driver stack is required to manage the HW. So, you could build a PC based LPAR hypervisor. It would just be limited to the SRIOV capable devices, or plugging in piles of adapters, each one uniquely bound to a single partition. Ex: https://www.hitachi.com/rev/pdf/2012/r2012_02_104.pdf https://www.hitachi.com/rev/pdf/2012/r2012_02_104.pdf

jhallenworld 3y ago

This makes no sense to me. Backward compatibility is a huge competitive advantage for Intel, and IMHO, it's royally messed up that vm86 mode doesn't work in 64-bit mode. One DOS application I use was hurt by this: "old DOS OrCAD". It works well in Windows-XP on a 32-bit machine, but does not work at all in 64-bit Windows. (It's actually a 32-bit DPMI program and has drivers to use Windows GDI so you don't have to mess around with drivers). More evidence: IBM 360 mainframe software still works in Z/OS. It might be worth it for non-generic computing devices like cell phones, but Intel missed the boat there already.

manuelabeledo 3y ago
Legacy systems and architectures can’t be around forever. How many people in the PC market still use 16-bit applications?
- jhallenworld 3y ago
  >Legacy systems and architectures can’t be around forever. Why not? The bits don't decay.. Yes, this leads to an architectural mess, but I'm talking about a competitive business advantage.
  - manuelabeledo 3y ago
    > Why not? > Yes, this leads to an architectural mess Right there. There's no notable advantage in supporting a very small minority of the applications out there, at the cost of keeping units useless for the 99%.
    - bear8642 3y ago
      > There's no notable advantage... Potentially one if a large customer's paying you for it. At work, I'm helping a client upgrade from a decade old version (v12) of our product and having to copy over the switches to keep the even older (v11 and previous) behaviours

formerly_proven 3y ago

> Since its introduction over 20 years ago, the Intel® 64 architecture became the dominant operating mode. Okay that's a bit heavy on the retcon, don't you think?

r00fus 3y ago
Why? Because it's really just AMD-64?
- dathinab 3y ago
  probably but also it's a stretch in general as for personal computers arm is the dominant platform since years (there are way more phones, tablets, etc. then x86 laptops/desktops by now, all of which fit the original definition of personal computer)
  - epylar 3y ago
    It's saying that the 64-bit mode became dominant over other Intel modes.
- kevin_thibedeau 3y ago
  "Intel Architecture 64" is Itanium. Calling x64 "Intel 64 Architecture" is like MS trying to steal the thunder of Open Office ODF with OOXML.

AdamH12113 3y ago

> Since its introduction over 20 years ago, the Intel® 64 architecture became the dominant operating mode. *cough*[1] [1] https://en.wikipedia.org/wiki/X86-64#History https://en.wikipedia.org/wiki/X86-64#History

mananaysiempre 3y ago
I guess we should be thankful they aren’t still calling it EM64T :) I’ve also heard that the term AMD64 also originated from marketing—the internal name during development was x86-64 (which everybody but Microsoft ended up calling it anyway).
- deaddodo 3y ago
  "amd64" is the official name, per AMD; just as "ia32" is the official name of x86-32, per Intel. The fact that ia32 (and it's sub-classifiers: i386, i486, etc) is still somewhat used, while amd64 has almost completely disappeared is 100% due to Intel's marketing shenanigans in the 00s.
  - circuit10 3y ago
    I see amd64 more often than I see ia32
- kinghajj 3y ago
  `amd64` is still what Debian and Kubernetes use.
  - IntelMiner 3y ago
    Good fun when my dyslexia misreads "arm64" as "amd64" or vice-versa when going to grab software these days :(
    - post-it 3y ago
      It's happened to me at least twice.

dathinab 3y ago

64Bit (OS) only and kicking out legacy cruft which doesn't just add complexity but also can in some edge cases can make security harder sound like a very sane idea, just maybe kinda late. I mean they probably could have started pushing this in some areas, like server and high-end CPUS, like 5-10years ago.

userbinator 3y ago

Do not want. Did they not learn from the https://en.wikipedia.org/wiki/Intel_80376 https://en.wikipedia.org/wiki/Intel_80376 or the infamous Itanic? The almost 50 years of backwards compatibility (along with the accompanying creation of a huge amount of documentation) is one of the strongest reasons for choosing the x86/PC. With each feature removal, they weaken that argument and push their (prospective) customers towards reconsidering all the other competitive CPUs out there like ARM, MIPS, RISC-V, etc. that are not distant in performance. Intel has made SoCs for phones, tablets, and other miscellaneous devices, but they weren't PC-compatible. Not surprisingly, they were not well-received. Related: https://news.ycombinator.com/item?id=8091290 https://news.ycombinator.com/item?id=8091290 Maybe it's time for a CISC-V...? Edit: apparently respecting history is not a popular opinion.

snvzz 3y ago
>Maybe it's time for a CISC-V...? I believe the only path forward for x86 is to be a "x86 accelerator", a x86 mode in some future AMD/Intel RISC-V processors, perhaps limited to unprivileged "usermode". Easing the transition until x86 can be relegated to emulation.
- userbinator 3y ago
  Easing the transition until x86 can be relegated to emulation. The devil reveals itself. Competitors have infected Intel and are trying to destroy it from within. x86 without the legacy is just another ISA, and Intel is going to lose if it tries to go down that path.
  - mepian 3y ago
    Intel is going to lose because it ditched Ring 1 and 2, sure.
    - userbinator 3y ago
      ...and everything else that made the PC great.

karmakaze 3y ago

I can certainly see how this is beneficial. At the same time it seems like it's a local optimum, to be eclipsed by other architectures. How much software really depends on 64-bit x86 architecture? And for how long? A large amount of server software can be reasonably ported to a new architecture. New platforms can adopt new architectures (phone/tablet, AR/VR). General purpose software like a web browser abstracts hardware, as does very popular software (as Facebook had, and WeChat does). Apple hasn't been tied to architectures and transitioned a number of times, always optimizing the whole rather than optimizing intermediate/stationary fixed points. If Intel is to make it to the next phase, it needs more than incremental improvements to compete. I hope that there's a path/future for AMD and Intel to evolve x86 and thrive but it won't be a given or easy.

ksec 3y ago

> Intel is currently investigating for a 64-bit mode-only architecture referred to as x86S I wish AMD had started this instead of Intel so they could call it AE86.

ksec 3y ago

I wonder if Intel could open up x86s ISA. They need to transition to Foundry and there is no going back. Might as well open up x86s.

RecycledEle 3y ago

I said in 1994 that when Moore's Law finally stopped, we could go back and clean up all our hasty patches. Maybe Moore's Law really is dead. /tears for the end of Moore's Law, just shortly after that great man passed away.