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: <3c6510cc947a1b59b62753de4cf98293@www.novabbs.org> <2024Oct22.172620@mips.complang.tuwien.ac.at> 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< 11 [Rb+Ri< 33