Nearly one year ago Intel published the X86S specification (formerly stylized as “X86-S”) for simplifying the Intel architecture by removing support for 16-bit and 32-bit operating systems. X86S is a big step forward with dropping legacy mode, 5-level paging improvements, and other modernization improvements for x86_64. With the Linux 6.9 kernel more x86S bits are in place for this ongoing effort.
↫ Michael Larabel
I doubt we’ll see much fallout from these changes.
They mention using virtualization to run legacy software, but without digging much deeper into intel’s documentation it isn’t clear to me on whether the removal of legacy CPU features impacts virtualized environments as well. The PDF has a lot of notes that suggest things may not be the same.
https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html
If so, it could be problematic for those of us who rely heavily on virtualization. Keep in mind that today’s operating systems, including the 64bit versions of linux and windows, still use 16bit and 32bit tables & modes & registers at least to boot up 16bit->32bit->64bit. A windows 10 VM may never support a fully 64bit boot process.
It’s possible that legacy modes could be emulated while only using hardware virtualization for long mode, but the virtualization software may need modifications to support this.
Alfman,
Yes, this is problematic. But the damage is already done, as both Mac and Windows are moving to ARM, and legacy code will need to go though various levels of virtualization and API emulation to get running.
If your legacy code can compile for native 64 bit Windows, it can also compile for ARM. And any emulation enhancements can also be ported to 64-bit ARM as 32-bit code will not have to be dynamically translated.
Meaning it will only make transition off of Intel easier.
Hence, this could be Intel shooting themselves in the foot in the long run.
Okay, it seems like I missed this part:
They will still support 32-bit user mode programs. Given almost all of them have moved away from segments, or direct I/O access, it should be okay for 99% of the cases.
Will compatibility with 32-bit apps running on 64-bit operating systems be retained? I am referring to WoW64. It’d be sad if Windows loses compatibility with most 2000/XP apps (and several Windows VIsta+ apps that never made the jump to 64-bit).
Article says something like “Using the simplified segmentation model of 64-bit for segmentation support for 32-bit applications, matching what modern operating systems already use.” but does this mean 32-bit apps will continue working as they do now?
kurkosdr,
Yes, running 32bit user mode software is still supported, 32bit operating system software is not.
You make a valid technical point about the segment registers, intel’s documentation suggests these limits will be ignored. However because neither windows nor linux use them anyways I don’t know where it would matter. As far as I know both these operating systems always use page tables to control memory access and not segments/selectors. 32bit protected mode software that existed in DOS might be affected, but that’s out of scope anyways.
x86s is legacy-reduced, not legacy free 😉
Basically real/virtual/protected 16-bit modes are pruned out. And the ia32 ring 0 is gone, so no 32-bit and 64-bit hybrid system software allowed. Ring 2/3 and up are fine. So the user level software part of ia32e is fully supported.
This is, 32bit ia32 user-level software/apps should work just fine on whatever 64-bit x86 OS.
Obviously, the whole BIOS and associated legacy board-level options go away. So UEFI type of firmware from there on.
Also, gotta love this:
No, since its introduction over 20 years ago, AMD64 became the dominant operating mode. Those Intel dudes just can’t stomach the fact that AMD was the company that took x86 to 64-bit (while Intel was busy pushing Itanium aka Itanic as the successor to x86). Even something company-neutral like x86-64 or x64 is not good enough for Intel, they just have to pretend x86-64 was their idea.
100%
100%
As you link to the site where a tempest in a teapot rages in the forums every time this is mentioned.
That is par for the Phoronix forums. There are some very knowledgeable people there, and then there are the dunces shouting at each other.
The name shall be simply X64 architecture as 8086 legacy is removed. But I guess it’s to alleviate potential compatibility fears.
These parts are still members of the x86 family even if all the 16 bit legacy cruft is removed completely.
Intel just sucks at branding.
x86, i86 (not to be confused with the i860), IA32, iIA32e, x86_64, i64 (not to be confused with IA64, aka itanium), and now full back in full circle to x86s. Yay!
I wonder if we’ll end up seeing Intel HMP processors with a 4 legacy core cluster and the rest legacy free. It’d be a neat solution to still be able to run really old software without using too much die space for ancient cruft.
The only 32bit OS i care about is BeOS, and i just got my 5.04+openglkit+mediakit+bone install onto my X7DCT-10G-B (2×4 cores 8 threads and i use the L5408 Xeons to avoid the 2147mhz bug in BeOS on smp machines) I installed 16tb of SSD’s and imported from taiwan some small ram sticks to use the quad channel ram speed (4x256mb) (max in 5.04 is 768+videoram.
My gpu is a Voodoo5 5500 PCI, upgraded to 256mb instead of the default 64 (32×2), an aureal vortex2 with gold plated in/outputs with a dreamblaster midi addon. Works like a dream.
Playing corum 3 as i am writing this.