Re: x86S Specification

Liste des GroupesRevenir à c arch 
Sujet : Re: x86S Specification
De : cr88192 (at) *nospam* gmail.com (BGB)
Groupes : comp.arch
Date : 22. Oct 2024, 06:53:09
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vf7ek9$1c5qd$1@dont-email.me>
References : 1 2 3
User-Agent : Mozilla Thunderbird
On 10/21/2024 7:21 PM, MitchAlsup1 wrote:
On Mon, 21 Oct 2024 22:02:27 +0000, BGB wrote:
 
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...
 This only works when the mative ISA has a direct path to emulating
the address modes of x86-64 which includes [Rbase+Rindex<<scale+DISP]
 
This is a bigger problem for unmodified RISC-V as I see it.
Though, in theory, RISC-V with Zba can do:
   SH2ADD  Xd, Xb, Xi
   LW      Xd, Disp(Xd)
Which arguably isn't too bad.
I think they underestimate the costs of needing a 2-op sequence vs, say:
   LW      Xd, (Xb, Xi)
But, yeah, if trying to design an x86 stand-in, might make sense to prioritize trying to be close to 1:1 for core x86 ops, or use fewer ops in cases where multiple x86 ops can be merged (say, 3R vs 2R, ...).
This does probably still mean a variable length encoding, but, say:
   32/64/96, or 16/32/64/96, or similar.
Not 1-15 bytes with a fairly ad-hoc set of encoding rules.
Also the official RISC-V strategy for larger encodings sucks...
IMO, jumbo prefixes or similar are preferable, as the extension scheme is more straightforward (and possible encodings can drop out of a predefined set of rules; not so much by needing people to go and define each possible extended encoding individually, with no real consistent layout guidelines for how the extended instruction spaces are to be structured, ...).

It is also a hopelessly frail path to self destruction:: Transmeta.
 
I am imagining not exactly taking the Transmeta path, but possibly more like a Rosetta path, with a Transmeta-like fallback if trying to boot an old OS (if the OS lacks the native ISA, so is booted in full emulation).
But, yeah, likely would be better to have the OS to be able to run the native ISA.

Granted, this is predicated on the assumption that one could get such a
jump by jumping to a different encoding scheme.
 It is not the encoding scheme that is kaput, it is the semantics
such a scheme provides the programmer via ISA.
--------------------------------
Possibly.
My ideas thus far end up looking sort of like:
Core ISA similar to BJX2 or RISC-V semantics, but with ability to express large immediate values and similar (a weak area for normal RISC-V). Should be able to efficiently express x86 address modes, ...
Should likely also have helpers for things like rFLAGS twiddling, ...

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).
 W11 has done enough to my day-to-day operations I am willing to
jump ship to Linux in order to avoid daily updates an the myriad
of technical issues that never seem to get solved in a way that
makes then "go away" forever. So, for me it is not that it will
be an x86 (or ARM, or ...) it is that it is not MS oriented.
I am still using Win10 on my PC, but parents have a PC Win11, and what little I have encountered it (and heard about it) doesn't really make me want to use it.
Well, and Win11 doesn't see my PC as being compatible.
But, this leaves stuff in a limbo state for now.
...
Most of the software I run is open source, so theoretically a jump is possible.
Usually, I would skip over Windows versions that kinda sucked, say, I stuck with XP-X64 until Win7, then went from Win7 to Win10.
Looks like MS is trying to push people into using Win11 though (while at the same time trying to push SecureBoot and TPMs, ...).
...
Ironically, I would almost assume getting one of the manycore ARM based systems and running Linux on it, except they are still expensive. And, on the other side, a RasPi or other similar SBC is not a viable replacement.
Would want something I would have a proper GPU on and plug in 6 or 8 SATA devices, etc.
So, my wishlist would include among other things:
   ATX family form-factor;
   PC-like or PC-superior performance;
   Can have, say, 128GB of RAM and 8+ SATA devices;
   ...
But, at least at the moment, x86-64 still owns this space...
But, may change in the future...

Date Sujet#  Auteur
22 Oct 24 * Re: x86S Specification30BGB
22 Oct 24 +* Re: x86S Specification27MitchAlsup1
22 Oct 24 i+* Re: x86S Specification12John Levine
22 Oct 24 ii+* Re: x86S Specification3BGB
22 Oct 24 iii+- Re: x86S Specification1John Dallman
23 Oct 24 iii`- Re: x86S Specification1Lawrence D'Oliveiro
22 Oct 24 ii`* Re: x86S Specification8Anton Ertl
22 Oct 24 ii +* Re: x86S Specification2John Dallman
23 Oct 24 ii i`- Re: x86S Specification1Lawrence D'Oliveiro
22 Oct 24 ii +* Re: x86S Specification3BGB
22 Oct 24 ii i`* Re: x86S Specification2MitchAlsup1
25 Oct 24 ii i `- Re: x86S Specification1BGB
22 Oct 24 ii `* Re: x86S Specification2BGB
23 Oct 24 ii  `- Re: x86S Specification1Lawrence D'Oliveiro
22 Oct 24 i+- Re: x86S Specification1BGB
22 Oct 24 i`* Re: x86S Specification13George Neuner
23 Oct 24 i `* Re: x86S Specification12MitchAlsup1
24 Oct 24 i  `* Re: x86S Specification11George Neuner
25 Oct 24 i   `* Re: old phones, x86S Specification10John Levine
25 Oct 24 i    +* Re: old phones, x86S Specification2MitchAlsup1
25 Oct 24 i    i`- Re: old phones, x86S Specification1BGB
25 Oct 24 i    +* Re: old phones, x86S Specification4Lawrence D'Oliveiro
25 Oct 24 i    i`* Re: old phones, x86S Specification3John Levine
25 Oct 24 i    i +- Re: old phones, x86S Specification1John Levine
26 Oct 24 i    i `- Re: old phones, x86S Specification1Michael S
25 Oct 24 i    +- Re: old phones, x86S Specification1George Neuner
25 Oct 24 i    `* Re: old phones, x86S Specification2yeti
25 Oct 24 i     `- Re: old phones, x86S Specification1Robert Finch
22 Oct 24 `* Re: x86S Specification2MitchAlsup1
22 Oct 24  `- Re: x86S Specification1BGB

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal