Sujet : Re: x86S Specification
De : cr88192 (at) *nospam* gmail.com (BGB)
Groupes : comp.archDate : 22. Oct 2024, 07:16:34
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vf7g04$1c5qd$2@dont-email.me>
References : 1 2 3 4
User-Agent : Mozilla Thunderbird
On 10/21/2024 8:16 PM, John Levine wrote:
According to MitchAlsup1 <mitchalsup@aol.com>:
x86's long term survival depends on things out of AMD's and Intel's
hands. It depends on high volume access to devices people will buy
new every year or every other year. A PC is not such a thing, while
a cell phone seems to be.
Intel's never going to catch up in the phone market but they're still
significant in the server and cloud market.
Think about the way that current Intel chips have a native 64 bit architecture
but can still have a 32 bit user mode that can run existing 32 bit application
binaries. So how about if the next generation is native x86S, but can also run
existing 64 bit binaries, even if not as fast as native x86S. They get the usual
cloud operating systems ported to x86S while leaving a path for people to migrate
their existing applications gradually.
As I understand it, as-is x86S would mostly effect OS level code, leaving the userland basically intact (still able to run existing software).
If your goal is "Run an OS like Win 11, Business as usual", this makes sense. Modern Windows doesn't really use the stuff that x86S removes.
Longer term, this may be insufficient. If Moore's Law grinds entirely to a halt, running x86-64 in hardware may not be a win.
Then again, I guess both Itanium and Transmeta can be taken as examples of ways to shoot oneself in the foot as well.
In this case, the Apple situation makes more sense. They have jumped MacOS from x86 to ARM, without loosing all of their existing software base, by running a userland emulator that "doesn't suck".
Granted, can't necessarily trust MS here, as much of the time MS has done stuff like using emulation strategies that are awkward and suck. Like, say, running Windows inside an emulator, in Windows, and just sort of crudely gluing the desktops together between programs in the native and VM Windows instance (without giving programs in the VM transparent access to the host OS's filesystem, ...).
So, it is more a thing of "What if the emulation layer, doesn't suck?...". One where there are no obvious seams, the VM program instances looking and behaving just like native ones, able to see all the same files, ...