Path: ...!feeds.phibee-telecom.net!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Chris M. Thomasson" Newsgroups: comp.arch Subject: Re: is Vax addressing sane today Date: Sat, 5 Oct 2024 14:56:34 -0700 Organization: A noiseless patient Spider Lines: 57 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-Date: Sat, 05 Oct 2024 23:56:36 +0200 (CEST) Injection-Info: dont-email.me; posting-host="6c93b5071404f6ae798ac7d5b4815c57"; logging-data="961977"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/5mmDIkF+0sWyVITnGrGLk15/eH0iUTb0=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:IpUpXTNg5cyj3MtGIoZAFwvNocw= Content-Language: en-US In-Reply-To: Bytes: 3750 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. 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