Re: Memory ordering

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.

>
[...]