Path: ...!feeds.phibee-telecom.net!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: comp.arch
Subject: Re: Memory ordering
Date: Wed, 31 Jul 2024 00:57:15 -0700
Organization: A noiseless patient Spider
Lines: 57
Message-ID: <v8cqor$1g8jb$1@dont-email.me>
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>
 <20240730124742.00001a1d@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 31 Jul 2024 09:57:16 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="74e95562e9d30488492612fbf917977f";
	logging-data="1581675"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19QYWOzLQksSnaT28zdRmHhXl/os3aweIc="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:a5XqqRJqXu1uaS2IoMqK8l+Xkm4=
In-Reply-To: <20240730124742.00001a1d@yahoo.com>
Content-Language: en-US
Bytes: 3636

On 7/30/2024 2:47 AM, Michael S wrote:
> 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 was not good to put a MEMBAR instruction in any branch delay slot, or 
any 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.
>>>
>>> [...]
> 
>