Intel Updates 64-Bit Only "X86S" Instruction Set Architecture Specification to Version 1.2

[AleksandarK]

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.



View at TechPowerUp Main Site | Source

 

[Ferrum Master]

Not sure how 32 bit vs 64 bit translates processing TWO MORE times data.

And what's faster about it? Shorter code executes faster what's with that idiotic banner, stupid artists.

 

[ncrs]

While the specification does mention a "32-bit compatibility mode," its exact functionality remains unclear. 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.

It means that 32-bit applications will be able to be run under a 64-bit operating system, and only fully 64-bit operating systems will be able to boot on X86S:

(source)

 

[Dragokar]

It means that 32-bit applications will be able to be run under a 64-bit operating system, and only fully 64-bit operating systems will be able to boot on X86S:

(source)

Thank you^^

 

[AusWolf]

The industry has been moving away from 32-bit for the last 20 years, and will probably continue to do so for at least 10 more. So I think 32-bit support is still needed, at least through a translation layer or something.

 

[ncrs]

Not sure how 32 bit vs 64 bit translates processing TWO MORE times data.

And what's faster about it? Shorter code executes faster what's with that idiotic banner, stupid artists.

Computation in a CPU happen in CPU registers. Instructions operate on registers, and registers can load and save their contents from/to RAM.
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.

 

[chrcoluk]

The industry has been moving away from 32-bit for the last 20 years, and will probably continue to do so for at least 10 more. So I think 32-bit support is still needed, at least through a translation layer or something.

For sure, there is devs today still compiling 32bit as well as many 32bit games. Preventing 32bit OS whilst allowing 32bit binaries on a 64bit OS I think is sensible. As it should encourage more devs to move to 64bit. I think even steam client is still 32bit.

 

[Wirko]

It means that 32-bit applications will be able to be run under a 64-bit operating system, and only fully 64-bit operating systems will be able to boot on X86S:

(source)

Exactly. Maybe this part from the specification can clarify things a bit more:

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.

 

[Geofrancis]

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.

My understanding of the cross licence agreement is both companies will get access to any extensions t x86, including 64 and any extensions like SSE and AVX, so i would think this would just be a modification to the existing architecture.

 

[Nhonho]

Do you know if this X86S specification brings other new technologies, such as the unified CPU and GPU memory technology? (to no longer exist the current need for duplicating data in main RAM and VRAM, when using an iGPU or a x86 SoC)

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.

While Intel leads the initiative, AMD's role in the potential transition remains uncertain, given its significant contributions to the current x86-64 standard.

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.

 

[Timbaloo]

I'd rather see x86/x64 die... Stop the money printing machines for intel and AMD...

 

[OSdevr]

Not sure how 32 bit vs 64 bit translates processing TWO MORE times data.

And what's faster about it? Shorter code executes faster what's with that idiotic banner, stupid artists.

This is... spectacularly incorrect. 64 bit is not significantly slower than 32 bit operations on any CPU with full native support. The same ALUs are used for both operations. I don't know about 32 bit but 16 bit data on modern CPUs suffers a performance penalty due to things like partial register stalls. And "shorter code" isn't usually an issue as code bandwidth is rarely a limiting factor.

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.

Do you know if this X86S specification brings other new technologies, such as the unified CPU and GPU memory technology? (to no longer exist the current need for duplicating data in main RAM and VRAM, when using an iGPU or a x86 SoC)

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.

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.

 

[kawice]

For sure, there is devs today still compiling 32bit as well as many 32bit games. Preventing 32bit OS whilst allowing 32bit binaries on a 64bit OS I think is sensible. As it should encourage more devs to move to 64bit. I think even steam client is still 32bit.

I suspect some older classic and retro games might stop working.
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.

 

[Makaveli]

While the specification does mention a "32-bit compatibility mode," we are yet to how would 32-bit apps run.

"we are yet to see how you would run 32-bit apps"

 

[OSdevr]

This is only removing 16 and 32 bit system operation. 32 bit user mode programs would still run fine. RIP FreeDOS and many other smaller OS'es though (including my own work from back in the day). Wondering how this will affect virtualization and UEFI devs as well.

 

[tsunami2311]

So i not gona be able to play my games of old anymore dos games or first window based games? on newer systems?>

 

[Nhonho]

So i not gona be able to play my games of old anymore dos games or first window based games? on newer systems?>

 

[OSdevr]

Emulation may work fine for games, other things not so much. The military among others still uses DOS for a lot of stuff. It's simple, well tested, and there's a lot less that can go wrong. You don't want missile targeting software running emulated on Windows 11.

 

[Ferrum Master]

This is... spectacularly incorrect.

You are looking it from the wrong side. Because people code like dementia monkeys these days. More registers or from monkey perspective - pointers, mean you fill your precious cache faster with unneeded variables in reality, look at shit games recently, they should be sent to a remote internet less oil rig and code for playstation1 for few years for food, the get the understanding at last. And here you wonder why AMD Ryzen 3D cache CPU are so good at gaming? This was very obvious in Raspberry Pi ARM builds that shitty 64bit code actually stalled the CPU faster and resulted in worse performance, yet bloody everyone says MORE RAM is better go for 64, then you can do more crap code, because how immature is the ARM state, it turned like that. Embedded devices and architectures will never cease to be due to power constraints, proper coding culture must still remain, but hey... this is where X86 sucks, I wonder why.... not... but hey, let's do more AVX iterations and make the compilers even more retarded and apps more heavy, fragmentation is the key !!@! 32bit mode constraint is perfect to benchmark your app for proper behavior and performance.

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.

So i not gona be able to play my games of old anymore dos games or first window based games? on newer systems?>

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.

 

[OSdevr]

You are looking it from the wrong side. Because people code like dementia monkeys these days. More registers or from monkey perspective - pointers, mean you fill your precious cache faster with unneeded variables in reality, look at shit games recently, they should be sent to a remote internet less oil rig and code for playstation1 for few years for food, the get the understanding at last. And here you wonder why AMD Ryzen 3D cache CPU are so good at gaming? This was very obvious in Raspberry Pi ARM builds that shitty 64bit code actually stalled the CPU faster and resulted in worse performance, yet bloody everyone says MORE RAM is better go for 64, then you can do more crap code, because how immature is the ARM state, it turned like that. Embedded devices and architectures will never cease to be due to power constraints, proper coding culture must still remain, but hey... this is where X86 sucks, I wonder why.... not... but hey, let's do more AVX iterations and make the compilers even more retarded and apps more heavy, fragmentation is the key !!@! 32bit mode constraint is perfect to benchmark your app for proper behavior and performance.

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.

If I'm understanding correctly, your concern is programmers using too many 64 bit datatypes when 32 bit would do? Poor programming practices has little to do with the CPU "bit width." 64 bit versions of x86 programs are slightly larger than 32 bit ones but not twice the size, and they can still operate just fine using 32 bit data. The "64 bit" is the size of the registers and virtual memory address space. Technically the address space is closer to 48 or 52 bit (I forget which) last I checked but I digress. The opcodes themselves are variable length in x86, and nearly identical between x86 and x64. IIRC they are distinguished from each other by a prefix which "switches" how the processor interprets them, the same prefix that was used to distinguish between 16 and 32 bit instructions before. That's why 16 bit programs couldn't run properly under a 64 bit OS (though Virtual 8086 Mode was introduced to counter this).

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

 

[Neo_Morpheus]

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.

Considering that AMD created the current X64 extensions, I will like to think that they have more saying at this point that even Intel.

The question of AMD's support is a very interesting one due to Intel being basically bullied by the market into adopting AMD64.

Industry (back when they would smell lock-in tech BS) observed that Intel wanted to kill x86 with a proprietary ISA when they released the Itanium.

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.

 

[ncrs]

This is only removing 16 and 32 bit system operation. 32 bit user mode programs would still run fine. RIP FreeDOS and many other smaller OS'es though (including my own work from back in the day). Wondering how this will affect virtualization and UEFI devs as well.

Virtualization guests will have the same restrictions as the host in X86S. You'll have to run partial or full emulation in order to run software requiring removed features.
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.

 

[Ferrum Master]

If I'm understanding correctly, your concern is programmers using too many 64 bit datatypes when 32 bit would do?

Basically CPU performance lies in cache efficiency... it has always been... if you spam it, it stalls. This will only force bad behavior for uneducated software creators encouraging do native 64bit code, that would cause disaster.

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.

 

[igormp]

such as the unified CPU and GPU memory technology? (to no longer exist the current need for duplicating data in main RAM and VRAM, when using an iGPU or a x86 SoC)

That has nothing to do with the ISA, and is solely a software thing. On linux this is already possible, and folks use this all the time for stuff like running LLMs on Ryzen APUs.

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.

That also has nothing to do with the ISA, but rather software (again) and bus limitations. I'm not sure if it's possible to do P2P transfers with Sata, but with NVMes you can use PCIe P2P (and not only NVMes) without going through RAM at all. It works in exact the same way in both ARM and x86.

You are looking it from the wrong side. Because people code like dementia monkeys these days. More registers or from monkey perspective - pointers, mean you fill your precious cache faster with unneeded variables in reality, look at shit games recently, they should be sent to a remote internet less oil rig and code for playstation1 for few years for food, the get the understanding at last. And here you wonder why AMD Ryzen 3D cache CPU are so good at gaming? This was very obvious in Raspberry Pi ARM builds that shitty 64bit code actually stalled the CPU faster and resulted in worse performance, yet bloody everyone says MORE RAM is better go for 64, then you can do more crap code, because how immature is the ARM state, it turned like that. Embedded devices and architectures will never cease to be due to power constraints, proper coding culture must still remain, but hey... this is where X86 sucks, I wonder why.... not... but hey, let's do more AVX iterations and make the compilers even more retarded and apps more heavy, fragmentation is the key !!@! 32bit mode constraint is perfect to benchmark your app for proper behavior and performance.

It's not even clear what you're complaining about. The recent shit games folks don't touch compilers at all, so your complaint about pointers and register is moot since it's all transparent to them.

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:

Further Investigating The Raspberry Pi 32-bit vs. 64-bit Performance Review - Phoronix

www.phoronix.com

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.

 

[ScaLibBDP]

>>...The x86 architecture's strength has long been its extensive legacy support,
>>...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 ).