Wednesday, September 25th 2024
Intel Updates 64-Bit Only "X86S" Instruction Set Architecture Specification to Version 1.2
Intel has released version 1.2 of its X86S architecture specification. The X86S project, first announced last year, aims to modernize the x86 architecture that has been the heart of PCs since the late 1970s. Over the decades, Intel and AMD have continually expanded x86's capabilities, resulting in a complex instruction set that Intel now sees as partially outdated. The latest specification primarily focuses on removing legacy features, particularly 16-bit and 32-bit support. This radical departure from x86's long-standing commitment to backward compatibility aligns with the simplification of x86. While the specification does mention a "32-bit compatibility mode," we are yet to how would 32-bit apps run. This ambiguity raises questions about how X86S might handle existing 32-bit applications, which, despite declining relevance, still play a role in many computing environments.
The potential transition to X86S comes at a time when the industry is already moving away from 32-bit support. However, the proposed changes are subject to controversy. The x86 architecture's strength has long been its extensive legacy support, allowing older software to run on modern hardware. A move to X86S could disrupt this ecosystem, particularly for users relying on older applications. Furthermore, introducing X86S raises questions about the future relationship between Intel and AMD, the two primary x86 CPU designers. While Intel leads the initiative, AMD's role in the potential transition remains uncertain, given its significant contributions to the current x86-64 standard.
Sources:
InstLatX64, via Tom's Hardware
The potential transition to X86S comes at a time when the industry is already moving away from 32-bit support. However, the proposed changes are subject to controversy. The x86 architecture's strength has long been its extensive legacy support, allowing older software to run on modern hardware. A move to X86S could disrupt this ecosystem, particularly for users relying on older applications. Furthermore, introducing X86S raises questions about the future relationship between Intel and AMD, the two primary x86 CPU designers. While Intel leads the initiative, AMD's role in the potential transition remains uncertain, given its significant contributions to the current x86-64 standard.
32 Comments on Intel Updates 64-Bit Only "X86S" Instruction Set Architecture Specification to Version 1.2
And what's faster about it? Shorter code executes faster what's with that idiotic banner, stupid artists.
(source)
The original 32-bit x86 had 8 general purpose registers which were 32-bits wide. AMD64/x86-64 increased the number of registers to 16 and their width to 64-bit.
x86 instructions don't have to operate on full 64-bits at a time as they can still use different argument widths. This combined with modern CPUs not having separate, dedicated registers for each core but a register file that gets allocated dynamically means that there's almost no waste or "empty processing".
64-bit processing also enabled usage of more than 4GB of memory, so it was a natural step when hardware sufficiently improved.
It's only a fast and dirty explanation, but the gist of it is that AMD64/x86-64 was needed and turned out to be a success.
X86S is mainly about removing legacy features that aren't needed in modern operating systems. I'd expect that 99% of users won't even notice since 16-bit applications aren't even supported on 64-bit Windows versions. Nor are 32-bit drivers on 64-bit Windows.
Intel APX on the other hand aims to extend x86-64 further by adding 16 more registers and new instructions. Whether it will be successful depends on the market reaction since programs will have to be modified and/or recompiled to take advantage of it.
The question of AMD's support is a very interesting one due to Intel being basically bullied by the market into adopting AMD64. After much litigation both companies now have a licensing deal, but we'll have to see if it applies to X86S and APX.
Another thought: Legacy applications, those that will remain 32-bit forever, were designed many years ago and ran on much slower CPUs. Sandy Bridge at best, not Arrow Lake. They will never need more than Sandy Bridge-class performance. Intel could save some more space by removing or simplifying 32-bit-specific optimisations (such as branch prediction etc), if those exist, and nothing of value would be lost.
There are so many other things that should be changed in the x86 architecture... Even today, for exemple, to copy a file from one HD to another, the data is read from the 1st HD, goes to RAM and only then it is sent to the 2nd HD. Many years ago, Intel, AMD, Microsoft, the Linux Foundation (and other big institutions) should have come together to do away with these old and inefficient data flows in the x86 architecture.I imagine that a current x86 CPU is made based on thousands of patents from Intel and AMD. One needs the other's patents to develop its CPUs. I think that every microscopic part of a current x86 CPU is made based on hundreds or thousands of patents from AMD, Intel and other companies as well, patents that protect the intellectual property of the companies that created them...
I imagine that there is no way for Intel to manufacture a "pure" X86S CPU without any AMD patents.
EDIT: actually division might be slower on 64 bit operands since it doesn't take a fixed number of cycles, but most everything else won't be.This has nothing to do with unifying CPU and GPU memory nor would that be a very good idea. CPU memory prefers lower latency while GPU memory prefers high bandwidth. It's not a hard rule (consoles do it) but it gives best performance overall. What's more GPU memory moves data so fast that connectors ruin data integrity so there's no way to make it upgradable or replaceable without soldering. This is starting to become a problem for CPU memory too and is why laptops with soldered RAM tend to have higher RAM speeds than when they're on SODIMMs.
As for copying HDDs, buffering to RAM is pretty much required even today. When one device has data, the other often isn't immediately able to receive it. This is especially true with HDDs due to files being in different places and split up into different fragments on disk. I don't know if this is still true but it used to be faster to read and write data near the edge of a disk than the center because the tracks near the edge are moving faster.
Unless we get some unofficial low-level emulators alike dgVoodoo.
Does anyone still trust intel in whatever they say? Even Nvidia is more trustworthy these days. :D
"we are yet to see how you would run 32-bit apps"
Clean sheet design please... stop patching the dead body, it is too late. x86 is pretty much end of the road, why even bother altering and make things even more complicated. It is not Intel who will decide it, but Microsoft and other hardware makers with their driver stack, where the original core code guy is already in the casket. They will smell another Itanium moment here.
Also... how 2^32 is two times 2^64? That's frustrating.Old games already run like shit on modern hardware due to latency issues, modern hardware is shit for latency. DAW people have headaches for years and sit on their X58 often still. It is because of modern timers and power saving measures and PCIe. You can get better results emulating than run native on modern hardware... but still nothing beats the original.
This is all beside the point anyway. X86s has to do with getting rid of the old cruft that is important to system developers. Fully ditching memory segmentation, Real Mode (and it's unholy variants few know about), execution rings that were hardly ever used. This won't affect 32 or 64 bit programs running in an OS, it affects the OS itself.
EDIT: I remembered incorrectly about instruction prefixes and Virtual 8086 mode. Prefixes are used to distinguish 32 from 64 bit instructions but not 16-bit and Virtual 8086 Mode isn't available in 64-bit Long Mode
Heck they even renamed x86 to IA32 and Itanium to IA64 and the main purpose was to get AMD and the others x86 license holders out of the market.
Sadly now, we dont go against lock-in tech and on the contrary, we praise them and call them "must have features".
Just look at every single review that includes or mentions DLSS and CUDA.
UEFI will continue on pretty much as it has since Intel made CSM not mandatory in 2020, so there are current devices that can't even run 16/32-bit OSes unless bootstrapped by a 64-bit UEFI shim bootloader.
This x86S actually is plaster and does nothing. It really just disables booting older code. It should run on the CPU natively afterwards. I mocked the drawing as my first comment, being utter factual bullshit, and it is.
For compiler developers, I believe they do a pretty good job at register allocation. And this point of yours about "more registers" is also really non-sense, are you aware that a CPU has way more registers inside of it that are switched all the time on its register bank? Register renaming is a thing.
Your raspberry pi comparison also don't make much sense since using it in aarch64 leads to quite a perf jump:
www.phoronix.com/review/raspberrypi-os-64bit/2
40% faster, to be clear.
In most ISAs, 64-bit "modes" also lead to dense code overall, so cache thrasing is not that bad compared to 32-bit code. If you really want dense code, just do all your stuff in ARM Thumb and enjoy your way bigger instruction streams.
>>...allowing older software to run on modern hardware.
I didn't use Microsoft Windows Vista and Windows 8.x 64-bit OSs at all but I know that 16-bit software support is Not available in Windows 7, Windows 10 and Windows 11 64-bit OSs.
For example, this is an error message if you try to execute a legacy 16-bit Turbo C++ compiler version 3.0 on Windows 7 64-bit :
...
This version of C:\WorkLib\TC30\Bin\TCC.EXE is not compatible with the version of Windows you're running.
Check your computer's system information to see whether you need a x86 (32-bit) or x64 (64-bit) version of
the program, and then contact the software publisher.
...
So, in reality Microsoft disabled 16-bit software support on 64-bit OSs a long time ago ( possibly around 2007 year ).
Edit: they run in 32-bit Windows 10 too. Apparently you need to enable NTVDM.