On 10/17/2024 4:34 PM, EricP wrote:
Pros:
Technically makes sense for PCs as they are.
Cons:
Looses some of the major aspects of what makes x86 unique;
Doesn't really solve issues for x86-64's longer term survival.
Absent changing to a more sensible encoding scheme and limiting or
removing condition-codes, x86-64 still has this major boat anchor. But,
these can't be changed without breaking backwards compatibility (at
least, assuming hardware that continues running x86-64 as the native
hardware ISA).
Though, ironically, most "legacy x86" stuff could probably be served acceptably with emulators.
If it can't maintain a performance advantage (say, if ARM and RISC-V
catch up or exceed the performance possible on higher end x86 chips), it
is effectively done.
On 10/17/2024 4:34 PM, EricP wrote:
Say, if one could make the CPU itself have 35% more perf/W by jumping to
a different encoding scheme, this could easily offset if they needed to
pay a 20% cost by JIT compiling everything when running legacy
software...
Granted, this is predicated on the assumption that one could get such a
jump by jumping to a different encoding scheme.
The major selling point of x86 has been its backwards compatibility, but
this advantage may be weakening with the rise of the ability to emulate
stuff at near native performance. If Windows could jump ship and provide
an experience that "doesn't suck" (fast/reliable/transparent emulation
of existing software), the main advantages of the x86-64 legacy may go
away (and is already mostly moot in Linux since the distros typically recompile everything from source, with little real/significant ties to
the x86 legacy).
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.
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,
...).
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.
x86S eliminates a part of the compatibility path from systems
of yesteryear, but not that many people use these parts nowadays
anyway. It's unclear to me what benefits these changes are
supposed to buy
John Levine <[email protected]> writes:
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.
Several things in this paragraph makes no sense.
In particular, x86S is a proposal for a reduced version of the stuff
that current Intel and AMD CPUs support: There is full 64-bit support,
and 32-bit user-level support. x86S eliminates a part of the
compatibility path from systems of yesteryear, but not that many
people use these parts nowadays anyway. It's unclear to me what
benefits these changes are supposed to buy (unlike the elimination of
A32/T32 from some ARM chips, which obviously eliminates the whole
A32/T32 decoding path). It seems to me that most of the complexity of >current CPUs would still be there.
On 10/22/2024 10:26 AM, Anton Ertl wrote:
Several things in this paragraph makes no sense.
In particular, x86S is a proposal for a reduced version of the stuff
that current Intel and AMD CPUs support: There is full 64-bit support,
and 32-bit user-level support. x86S eliminates a part of the
compatibility path from systems of yesteryear, but not that many
people use these parts nowadays anyway. It's unclear to me what
benefits these changes are supposed to buy (unlike the elimination of
A32/T32 from some ARM chips, which obviously eliminates the whole
A32/T32 decoding path). It seems to me that most of the complexity of
current CPUs would still be there.
And I certainly prefer a CPU that has more capabilities to one that
has less capabilities. Sometimes I want to run old binaries.
So what would be my incentive as a user to buy an x86S CPU? Will they
sell them for less? I doubt it.
Yeah, basically my thoughts as well.
Business as usual...
Main effect it achieves is breaking legacy boot, doesn't seem like it
would either save all that much nor "solve" x86's longstanding issues.
*1: Probably, say (if I were designing the encoding):
{Rb+Disp10s] //32-bit encoding
{Rb+Ri*FixSc] //32-bit encoding
{Rb+Ri*Sc] //64-bit encoding
[Rb+Disp33s] //64-bit encoding
[Rb+Ri*Sc+Disp11s] //64-bit encoding
[Rb+Ri*Sc+Disp33s] //96-bit encoding
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.
On Tue, 22 Oct 2024 00:03:43 +0000, [email protected] (MitchAlsup1)
wrote:
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.
Only because the average cell phone gets broken or flooded within a
year. If people were not so careless, I doubt most would be replaced
so often.
My current phone is over 4 years old and it continues to serve all of
my needs. Sans damage, the only reason I would choose to replace it
would be when critical apps no longer support the OS version.
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".
Like, little point in trying to run Win98 on a newest-generation
platform (and, apparently, getting Win98 working natively on anything
much newer than the mid 2000s is pain ...
Microsoft would probably like machines where media playing was harder to intercept, because that would earn them more trust from the media conglomerates.
On Tue, 22 Oct 2024 21:59:46 +0000, George Neuner wrote:
On Tue, 22 Oct 2024 00:03:43 +0000, [email protected] (MitchAlsup1)
wrote:
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.
Only because the average cell phone gets broken or flooded within a
year. If people were not so careless, I doubt most would be replaced
so often.
My current phone is over 4 years old and it continues to serve all of
my needs. Sans damage, the only reason I would choose to replace it
would be when critical apps no longer support the OS version.
My first cell phone (Galaxy 3) I got in 2012 and used it until 2022
when the service provider offered a zero cost upgrade because they
were loosing access to the 4G-LTE antennae. I did put in 2 new
batteries, and nothing was scratched or dented after 11 years of use.
I still liked it better than the Galaxy 12 I have now. ...
Oh and BTW:: I do not carry my cell phone unless I am traveling
or expecting a call. It lives in my office--probably why it is
not being damaged by being sat upon or dropped into water, and
other causes of cell phone death.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 09:30:25 |
| Calls: | 12,100 |
| Files: | 15,003 |
| Messages: | 6,517,968 |