Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: x86S Specification
Date: Tue, 22 Oct 2024 21:13:41 +0000
Organization: Rocksolid Light
Message-ID: <5d79e4ceda7bf46346a80da098645adc@www.novabbs.org>
References: <dqfQO.411015$WOde.295848@fx09.iad> <vf6j1l$144cr$1@dont-email.me> <3c6510cc947a1b59b62753de4cf98293@www.novabbs.org> <vf6ucr$g6j$1@gal.iecc.com> <2024Oct22.172620@mips.complang.tuwien.ac.at> <vf8rov$1jsqv$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="3232420"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$H22QCWiJ4Vjd/SPz3IhCv.f04M2LcvC6Df1zyNOt.kDWzpzwFioRq
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
Bytes: 3034
Lines: 45

On Tue, 22 Oct 2024 18:43:40 +0000, BGB wrote:

> 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.

Intel needs a better way to exit reset--and that means the MMU/TLBs
are already up and working at the time reset is exited. This cannot
be made backwards compatible.
-------------------------------
>
> *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

     [Rb+DISP16]         // 32-bit   16 > 10
     [Rb+Ri<<sc]         // 32-bit
     [Rb+Ri<<sc+DISP32]  // 64-bit   32 > 11
     [Rb+Ri<<sc+DISP64]  // 96-bit   64 > 33