🚀 go-pugleaf

You are correct in stating that not many people understand COMPARE AND
SWAP (or, more generally, the Sequence of Storage References and
Serialization secrions at the end of Chapter 5 in PrincOps).

If the routine which is zeroing the counter cares about the exact value
that the counter had before it gets zeroed, then you must use the CS
instruction (although your loop is two instructions too long, it
*should* be coded:

             XR    0,0
             L     1,COUNTER
    LABEL    CS    1,0,COUNTER
             BNZ   LABEL

since R0 doesn't need to be re-zeroed and, if the CS instruction fails,
it will load R1 with the *new* value of COUNTER, so you are ready to do
the CS again).  Presumably, after this loop you will then do something
with the "old" value that is now in R1.

However, if you DON'T CARE about the old value of the counter and your
only interest is in zeroing it, then a simple STORE will suffice:

             XR    R0,R0
             ST    R0,COUNTER

(but DON'T use an XC instruction to zero the counter, as this will not
necessarily work all the times on all machines!).

If another CPU is simultaneously trying to increment the counter, it
will either get there first (in which case you will stomp the
incremented value), you will get there first (in which case it will
increment the 0 to a 1), or the other CPU's CS instruction will fail,
and on the next time around it will see your 0 and increment it to a 1.

Note that fullword-aligned STOREs are "block concurrent", meaning that
all 32 bits of the word in storage will be updated "concurrently" as
observed by other CPUs, so you don't have to worry about half-stored
results.  Likewise, a double-word aligned STORE MULTIPLE of two
registers (one doubleword) is also block concurrent as observed by
other CPUs.

      John Pershing
      IBM Research, Yorktown Heights, NY