Intel proposes X86-S instruction set with partial removal of 16 and 32bit features
-
Intel might as well remove the 32-bit instructions to save more die area and give us more processor cores. 64-bit Linux does not allow running of 32-bit applications.
-
[Phoronix](https://www.phoronix.com/news/Intel-X86-S-64-bit-Only):
Among Intel's expressed benefits for a 64-bit mode-only architecture is removing ring 1 and 2, dropping 16-bit addressing support, eliminating ring 3 I/O port accesses and the string port I/O, simplified segmentation model, and removing some unused operating system bits. Under this proposal, those wanting to run legacy 32-bit operating systems would have to rely on virtualization. To further clarify, 32-bit x86 user-space software would continue to work on modern 64-bit operating systems with X86-S.
The biggest question I have at this point is how much die area and microcode space would this actually save.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius
I read Intel's white paper on this change. The impacts are as follows: - No more starting the processor in real mode and then shifting to protected mode before OS loading. Instead, the processor starts in protected mode. - Elimination of original X86 level machine instructions. To my knowledge no 64-bit OS supports 16-bit applications. - Elimination/streamlining of some exceptions, including stack overflow and underflow. These will still be checked for but won't be separate exceptions. - 32-bit code will still be supported via virtualization. This will be hardware level support, including the IA32 instruction set, so there is minimal performance impact. - Improved processor level security by eliminating attack surface and simplifying the hardware design. - Near complete elimination of the segment:offset addressing scheme. This scheme will still be there but will require OS level calls to change the segment register. For applications this will result in a flat address space. - Will require a 64-bit OS.
-
[Phoronix](https://www.phoronix.com/news/Intel-X86-S-64-bit-Only):
Among Intel's expressed benefits for a 64-bit mode-only architecture is removing ring 1 and 2, dropping 16-bit addressing support, eliminating ring 3 I/O port accesses and the string port I/O, simplified segmentation model, and removing some unused operating system bits. Under this proposal, those wanting to run legacy 32-bit operating systems would have to rely on virtualization. To further clarify, 32-bit x86 user-space software would continue to work on modern 64-bit operating systems with X86-S.
The biggest question I have at this point is how much die area and microcode space would this actually save.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius
"When they came for the 16-bitness I said nothing, for I did not use 16-bit code..."
-
64-bit Windows does allow 32-bit applications. There are a lot of 32-bit applications still running on Windows desktops. What there aren't running is 16-bit applications.
Is that why Turbo BASIC won't run on Win 10? ;P
-
[Phoronix](https://www.phoronix.com/news/Intel-X86-S-64-bit-Only):
Among Intel's expressed benefits for a 64-bit mode-only architecture is removing ring 1 and 2, dropping 16-bit addressing support, eliminating ring 3 I/O port accesses and the string port I/O, simplified segmentation model, and removing some unused operating system bits. Under this proposal, those wanting to run legacy 32-bit operating systems would have to rely on virtualization. To further clarify, 32-bit x86 user-space software would continue to work on modern 64-bit operating systems with X86-S.
The biggest question I have at this point is how much die area and microcode space would this actually save.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius
Wondering how that might affect the effort to port OpenVMS to X86...
-
I read Intel's white paper on this change. The impacts are as follows: - No more starting the processor in real mode and then shifting to protected mode before OS loading. Instead, the processor starts in protected mode. - Elimination of original X86 level machine instructions. To my knowledge no 64-bit OS supports 16-bit applications. - Elimination/streamlining of some exceptions, including stack overflow and underflow. These will still be checked for but won't be separate exceptions. - 32-bit code will still be supported via virtualization. This will be hardware level support, including the IA32 instruction set, so there is minimal performance impact. - Improved processor level security by eliminating attack surface and simplifying the hardware design. - Near complete elimination of the segment:offset addressing scheme. This scheme will still be there but will require OS level calls to change the segment register. For applications this will result in a flat address space. - Will require a 64-bit OS.
I wonder how frequently used the IA-32 instruction set is. It seems that removing it would save even more silicon real estate.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
I wonder how frequently used the IA-32 instruction set is. It seems that removing it would save even more silicon real estate.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
There are still plenty of 32-bit applications out there (at least in the Windows world).
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
There are still plenty of 32-bit applications out there (at least in the Windows world).
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
I was mistaken. I thought IA-32 referred to the Itanium's instruction set but it is their term for the thirty-bit version of X86 instructions.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
Is that why Turbo BASIC won't run on Win 10? ;P
-
I wonder how frequently used the IA-32 instruction set is. It seems that removing it would save even more silicon real estate.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
Wondering how that might affect the effort to port OpenVMS to X86...
-
On workstations, there is a lot of legacy IA-32 code, including all versions of Visual Studio prior to VS 2022. Not so much on the server side anymore.
As I wrote,
Quote:
I was mistaken. I thought IA-32 referred to the Itanium's instruction set but it is their term for the thirty-bit version of X86 instructions.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
I think it would simplify the VMS port since the OS won't have to deal with 32 bit code. Remember, VMS is a 64 bit OS.
Well, most likely this version will be of course, but I have this MicroVAX... :cool:
-
Well, most likely this version will be of course, but I have this MicroVAX... :cool:
-
I just received an E-mail announcing that the X86-64 port of OpenVMS is ready for people to try it out. I may have to look into the system requirements.