Christmas Quiz...

[Chris M. Thomasson]

Imagine you are on a SPARC in RMO mode, you are programming in assembly
language. What memory barrier instruction is the most efficient _and_
correct for use _after_ using an atomic RMW instruction to take
exclusive access? Think about locking a mutex...

A: MEMBAR #LoadLoad

B: MEMBAR #LoadStore | #LoadLoad

C: MEMBAR #StoreLoad | #LoadLoad

D: MEMBAR #StoreLoad | #StoreStore


What about the membar we have to use before atomically unlocking this mutex?


A: MEMBAR #LoadLoad

B: MEMBAR #StoreLoad | #LoadLoad

C: MEMBAR #LoadStore | #StoreStore

D: MEMBAR #StoreLoad | #StoreStore

[Alf P. Steinbach]

I really don't have the foggiest idea, but I wish I had! :-o

Google tells me that "RMO mode" is relaxed memory order, and I remember
that's been mentioned in what I've read about C++ threading.

I can understand that being relevant, but "a SPARC"?

Anyway, best wishes for the coming new year.

Hopefully at the end there will be less war, less crisis, everything
better except the climate (which is FUBAR), and with everything better
we can be happy no matter what the climate does. Except my old fav idea
of saving the polar bears by transporting them to Antarctica, because
the penguins -- possible Antarctica food source -- are now an endangered
species. But, better.

- Alf

[Bonita Montero]

1. I use proper C++ barriers so I won't have to care for that.
2. SPARC is dead.

[Michael S]

[Michael S]

On Monday, December 26, 2022 at 11:23:06 PM UTC+2, Chris M. Thomasson wrote:

> Imagine you are on a SPARC in RMO mode, you are programming in assembly
> language.

If I am not mistaken, SPARC RMO is paper spec that was never implemented
in hardware. Which does not mean that it is impossible to imagine that I am
programming it in assembler, but it takes stronger imagination than I posses.

[Chris M. Thomasson]

Well, suppose you were tasked with creating the guts for C++ membars for
the SPARC. Imvvho, the SPARC in RMO mode is a good place to learn. The
MEMBAR instruction is pretty damn diverse! :^)

[Chris M. Thomasson]

On 12/27/2022 3:42 AM, Michael S wrote:
> On Monday, December 26, 2022 at 11:23:06 PM UTC+2, Chris M. Thomasson wrote:
>> Imagine you are on a SPARC in RMO mode, you are programming in assembly
>> language.
>
> If I am not mistaken, SPARC RMO is paper spec that was never implemented
> in hardware. Which does not mean that it is impossible to imagine that I am
> programming it in assembler, but it takes stronger imagination than I posses.

SPARC RMO is a real thing.

https://www.linuxjournal.com/article/8212

"Solaris on SPARC uses total-store order (TSO); however, Linux runs
SPARC in relaxed-memory order (RMO) mode."

[Michael S]

On Tuesday, December 27, 2022 at 11:31:33 PM UTC+2, Chris M. Thomasson wrote:
> On 12/27/2022 3:42 AM, Michael S wrote:
> > On Monday, December 26, 2022 at 11:23:06 PM UTC+2, Chris M. Thomasson wrote:
> >> Imagine you are on a SPARC in RMO mode, you are programming in assembly
> >> language.
> >
> > If I am not mistaken, SPARC RMO is paper spec that was never implemented
> > in hardware. Which does not mean that it is impossible to imagine that I am
> > programming it in assembler, but it takes stronger imagination than I posses.
> SPARC RMO is a real thing.
>
> https://www.linuxjournal.com/article/8212
>
> "Solaris on SPARC uses total-store order (TSO); however, Linux runs
> SPARC in relaxed-memory order (RMO) mode."

I am pretty sure that the article got it wrong.
OS can set control bits in register to any value it wishes, but the underlying
hardware will still behave as TSO.
At least, if the hardware is made by Sun/Oracle or Fujitsu, but all other SPARC
CPU vendors became irrelevant since ~1996, anyway.

[Chris M. Thomasson]

On 12/27/2022 2:09 PM, Michael S wrote:
> On Tuesday, December 27, 2022 at 11:31:33 PM UTC+2, Chris M. Thomasson wrote:
>> On 12/27/2022 3:42 AM, Michael S wrote:
>>> On Monday, December 26, 2022 at 11:23:06 PM UTC+2, Chris M. Thomasson wrote:
>>>> Imagine you are on a SPARC in RMO mode, you are programming in assembly
>>>> language.
>>>
>>> If I am not mistaken, SPARC RMO is paper spec that was never implemented
>>> in hardware. Which does not mean that it is impossible to imagine that I am
>>> programming it in assembler, but it takes stronger imagination than I posses.
>> SPARC RMO is a real thing.
>>
>> https://www.linuxjournal.com/article/8212
>>
>> "Solaris on SPARC uses total-store order (TSO); however, Linux runs
>> SPARC in relaxed-memory order (RMO) mode."
>
> I am pretty sure that the article got it wrong.
> OS can set control bits in register to any value it wishes, but the underlying
> hardware will still behave as TSO.
> At least, if the hardware is made by Sun/Oracle or Fujitsu, but all other SPARC
> CPU vendors became irrelevant since ~1996, anyway.

[...]

Are you telling me that SPARC RMO mode was run as if it was TSO in the
hardware? I need to ask Paul.

[Chris M. Thomasson]

This is a big deal because an atomic store in TSO implies release
barrier semanitcs, just like x86. One can release a spinlock in x86 with
an atomic store, no explicit membar needed. sparc in rmo mode does not
have implied release wrt atomic stores.

[Chris M. Thomasson]

A hint. A mutex does not need #StoreLoad ordering.

[Chris M. Thomasson]

On 12/26/2022 7:59 PM, Bonita Montero wrote:

What are the proper C++ barriers then?

[Chris M. Thomasson]

Too easy? Well, how to you implement them on a weakly ordered system? A
SPARC in RMO mode is a good place to start.

[Chris M. Thomasson]

On 12/26/2022 1:22 PM, Chris M. Thomasson wrote:

Get the answer by clicking on the following link. The password is membar:

http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=b77c814baf6376631199bcdf0a0e763136fceb0f56dd238dba943d05e54a47451c63e2fe25ca4b6b8b9dfaba2fd22dccf20261ad63a409ce2384cb734804bcbb068edcd3a7ae6bf91ba7d88e8c27a82b4c973f7421020e43

Just a test of my HMAC cipher... ;^)