Re: x86S Specification

On 10/22/2024 10:26 AM, Anton Ertl wrote:

John Levine <johnl@taugh.com> 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.
 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.
And, proposing an, "x86-64 but re-imagined as a RISC-style ISA" mode could have made sense...
Say:
   Instructions have a simpler and more consistent encoding;
     Probably still VLE, but less free-form.
   Maybe expand to 32 or 64 registers;
   3 register instructions;
   Maybe split ALU ops into CC-update and No-CC-update variants;
     Sorta like ARM.
     Most other ops become No-CC-Update only.
   This mode drops things like x87 and MMX and similar;
     Only SSE/AVX.
   Would make sense to keep the existing addressing modes (*1);
   Maybe keep LoadOP and OPStore, but limited in scope.
     Ironically, something like RISC-V AMO requires such a mechanism.
     If one implements something like AMO, may as well have LoadOP.
   ...
Maybe, as for AVX512:
   They can either make it usable "in general", or deprecate it.
*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
Some tweaks are possible, the above is mostly "if encoded in a similar way to XG2 or my RV+Jumbo-Prefix thing".
Though, in my case, the issue with the latter address modes had been less: "How to encode" so much as "Do they buy enough to justify the added cost of a 3-way adder in the AGU..."
But, for an "x86 successor", might be difficult to justify limiting things in a way that would require increasing the instruction count.
LoadOP would likely be allowed for basic ALU ops, but N/A for SSE/AVX (assembler could fake these though by breaking them into multiple ops).
Might make sense to offload a lot of the SSE/AVX stuff to 64-bit encodings, and essentially merge x86 into AVX (makes little sense to have separate encodings that do the same thing on the same registers).
One other likely goal would be to make it mostly backwards compatible with existing x86-64 ASM code, which would likely simplify getting a compiler for it.
In many cases, a JIT could potentially be pretty close to a 1:1 decode/re-encode process in this case (though, a bit more if trying to emulate legacy modes).
For translation or assembly, No-CC-Update forms could be inferred from default forms by looking forwards in the instruction stream (if a following instruction entirely masks any flags updates, can use the non-updating form instead).
Emulating x87 for legacy code could be harder though. Common case, x87 stack could be resolved statically, but there is a subset of cases where a non-static mapping could result. A JIT Would likely map x87 onto XMM registers, in any case.
Probable register spaces:
   R0 / RAX
   R1 / RCX
   R2 / RDX
   R3 / RBX
   R4 / RSP
   R5 / RBP
   R6 / RSI
   R7 / RDI
   R8..R15: Same as x86-64
   R16..R31: Extended, otherwise similar.
   XMM0 ..XMM15: Same
   XMM16..XMM31: Expanded
Would drop x87, MMX and x87/MMX registers.
Unlike RISC-V, I would assume keeping the base immediate values smaller (9 or 10 bits) and use VLE for larger immediate values.
Doing 12-bit immediate values as the default essentially eats a lot of encoding space for relatively little gain.
   Would have 17-bit constant-load and ADD as special cases.
My usual rationale for prioritizing 17 and 33 bit constants in some cases, over 16/32, or various other sizes, is that these sizes have "unusually good" hit rates IME (if you can cover both "signed short" and "unsigned short" ranges, the hit rate is significantly better than if it just covers "signed short", but adding a few additional bits gains relatively little; likewise for 33).
Pattern isn't so strong for 9s though, where both 9u and 10s are stronger than 9s (but 11 and 12 bits seem to see a rapid drop-off; at which point it is likely better to jump to a bigger encoding).
...

- anton