Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: mitchalsup@aol.com (MitchAlsup1) Newsgroups: comp.arch Subject: Re: is Vax addressing sane today Date: Sun, 6 Oct 2024 23:33:38 +0000 Organization: Rocksolid Light Message-ID: References: <20241001123426.000066c1@yahoo.com> <2024Oct1.182625@mips.complang.tuwien.ac.at> <2024Oct3.085754@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="887116"; mail-complaints-to="usenet@i2pn2.org"; posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU"; User-Agent: Rocksolid Light X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71 X-Spam-Checker-Version: SpamAssassin 4.0.0 X-Rslight-Site: $2y$10$2D8iFI5cmJndCbmB5n9noOoFHcO8MYbjXQekNwhkhoIkradwP.qRO Bytes: 3777 Lines: 58 On Sat, 5 Oct 2024 21:56:34 +0000, Chris M. Thomasson wrote: > On 10/4/2024 3:54 PM, MitchAlsup1 wrote: >> On Fri, 4 Oct 2024 19:36:41 +0000, Chris M. Thomasson wrote: >> >>> On 10/3/2024 11:36 PM, Chris M. Thomasson wrote: >>>> On 10/3/2024 9:23 PM, George Neuner wrote: >>>>> On Fri, 4 Oct 2024 00:48:43 -0000 (UTC), Lawrence D'Oliveiro >>>>> wrote: >>>>> >>>>>> On Thu, 03 Oct 2024 06:57:54 GMT, Anton Ertl wrote: >>>>>> >>>>>>> If the RISC companies failed to keep up, they only have themselves to >>>>>>> blame. >>>>>> >>>>>> That’s all past history, anyway. RISC very much rules today, and it >>>>>> is x86 >>>>>> that is struggling to keep up. >>>>> >>>>> You are, of course, aware that the complex "x86" instruction set is an >>>>> illusion and that the hardware essentially has been a load-store RISC >>>>> with a complex decoder on the front end since the Pentium Pro landed >>>>> in 1995. >>>> >>>> Yeah. Wrt memory barriers, one is allowed to release a spinlock on "x86" >>>> with a simple store. >>> >>> The fact that one can release a spinlock using a simple store means that >>> its basically load-acquire release-store. >>> >>> So a load will do a load then have an implied acquire barrier. >>> >>> A store will do an implied release barrier then perform the store. >> >> How does the store know it needs to do this when the locking >> instruction is more than a pipeline depth away from the >> store release ?? So, Locked LD (or something) happens at >> 1,000,000 cycles, and the corresponding store happens at >> 10,000,000 cycles (9,000,000 locked). >> >>> This release behavior is okay for releasing a spinlock with a simple >>> store, MOV. >> >> It may be OK to SW but it causes all kinds of grief to HW. > > I thought that x86 has an implied #LoadStore | #StoreStore before the > store, basically to give it release semantics. This means that one can > release a spinlock without using any explicit membars. Iirc, there are > Intel manuals that show this for spinlocks. Cannot exactly remember > right now. I wonder if this actually works with my scenario above. > > On x86 an atomic load has acquire and atomic stores have release > semantics. Well, I think that is for WB memory only. Humm... Cannot > remember if its for WC or WB memory right now. Then there are the > L/S/MFENCE instructions... > > https://www.felixcloutier.com/x86/sfence