Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: Memory ordering
Date: Tue, 30 Jul 2024 12:47:42 +0300
Organization: A noiseless patient Spider
Lines: 49
Message-ID: <20240730124742.00001a1d@yahoo.com>
References: <b5d4a172469485e9799de44f5f120c73@www.novabbs.org>
	<v7ubd4$2e8dr$1@dont-email.me>
	<v7uc71$2ec3f$1@dont-email.me>
	<2024Jul26.190007@mips.complang.tuwien.ac.at>
	<2032da2f7a4c7c8c50d28cacfa26c9c7@www.novabbs.org>
	<2024Jul29.152110@mips.complang.tuwien.ac.at>
	<f8869fa1aadb85896d237179d46b20f8@www.novabbs.org>
	<v88srb$kdv2$5@dont-email.me>
	<ec5f62a06185b38d1624803a0d0adf29@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 30 Jul 2024 11:47:11 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="311f30790304f190c11c4af140bf0c99";
	logging-data="439647"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19G6kyIaRIiHkSPZyxNOzHqCt4JCV6kUQ0="
Cancel-Lock: sha1:2we9vQt30jKMA9yTII3KHYUgM7I=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 3347

On Mon, 29 Jul 2024 20:43:47 +0000
mitchalsup@aol.com (MitchAlsup1) wrote:

> On Mon, 29 Jul 2024 20:08:10 +0000, Chris M. Thomasson wrote:
> 
> > On 7/29/2024 10:49 AM, MitchAlsup1 wrote:
> > [...]
> >  
> >> A MEMBAR dropped into the pipeline, when nothing is speculative,
> >> takes no more time than an integer ADD. Only when there is
> >> speculation does it have to take time to relax the speculation.  
> >
> > I am wondering if you were ever aware of the "danger zone" wrt
> > putting a MEMBAR instruction in a memory delay slot over on the
> > SPARC? The docs explicitly said not to do it. I guess it can cause
> > some interesting memory order "issues" that might allow a running
> > system to last for say, five years before crashing at a random
> > time... Yikes!  
> 
> Which, btw, is why one should exhaustively test atomic codes before
> putting it production. You do not want to chase down a memory ordering
> issue that occurs, in production, less than once a month.
> 
> I did a lot of programming on SPARCs and never needed a MEMBAR....
> but the OS guys used them like they were "free".
> 

Did you do programming on SPARC in RMO mode?
According to my understanding, RMO mode existed only on a couple of
SPARC CPU models (UltraSparc and UltraSparc-II) and was activated only
by OSes others than Solaris. Possibly, only by Linux.

> All sorts of things were dangerous in the delay slot of a branch,
> not the least of which was another branch.
>

Chris M. Thomasson wrote "memory delay slot".
I wonder what's meant by that. According to my understanding, on SPARC,
unlike on early MIPS, load delay slot was always merely an
implementation detail rather than SW-visible architectural feature.

> Prior to the introduction of multi-threaded cores, the rounding
> modes of the FPU status register were hard wired to the FU.
> Afterwards, they became "just another piece of state" that got
> pipelined down instruction execution.
> >
> > [...]