SoylentNews is people
SoylentNews
Intel Publishes "X86-S" Specification For 64-bit Only Architecture
Intel quietly released a new whitepaper and specification for their proposal on "X86-S" as a 64-bit only x86 architecture. If their plans workout, in the years ahead we could see a revised 64-bit only x86 architecture.
Entitled "Envisioning a Simplified Intel Architecture", Intel engineers lay the case for a 64-bit mode-only architecture. Intel is still said to be investigating the 64-bit mode-only architecture that they also refer to as "x86S". Intel is hoping to solicit industry feedback while they continue to explore a 64-bit mode only ISA.
[...] 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.
Also at Tom's Hardware.
(Score: 4, Informative) by turgid on Monday May 22, @09:07PM (1 child)
I know you're not supposed to but I had a quick look at the linked article.
Obviously, for backwards compatibility it will still run 32-bit binaries in user-land. The way x86-64 was designed was rather simple and clever to allow this to work with no performance penalty.
I don't suppose many of us now will shed tears about not being able to run 16-bit applications in hardware. Software emulation is way more than adequate, and there really is no problem with performance.
I see that this new architecture supports five levels in the page tables. When AMD extended x86 to 64-bits they added an extra layer in the page tables (making it up to four). This is a logical progression from there, presumably to address a lot more physical memory.
Booting straight into 64-bit mode is quite sensible. However, from a programmers point of view, when a current x86-64 boots, don't you just need two or three instructions to go into 64-bit mode (one to go to 32-bits and then the one to go from 32 to 64)? I can't quite remember. It has been 20 years since I went to that talk.
It will make boot ROM code simpler and probably rid us of some ancient hardware limitations on the board.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by Immerman on Tuesday May 23, @02:33PM
I believe it's pretty simple, but honestly I haven't messed with mode changes since writing DOS software on the 486.
The advantages aren't really in saving the OS writer effort changing modes, they're in saving the CPU designer the *much* greater effort of implementing those modes so that you could do things other than switch out of them. And there's probably some security gains to be had as well by just completely removing legacy modes that malware might exploit. Every bit of attack surface you can remove is a win - *especially* if that surface is something there's approximately zero legitimate users of, so that it doesn't normally get the maintenance attention it requires.
Presumably there's some silicon space saved as well - but I suspect you could tuck a full 32-bit CPU into the corner of a modern processor as an Easter egg and not appreciably increase the production cost.