(no commit message)
[libreriscv.git] / openpower / atomics / discussion.mdwn
1 # discussion moved here
3 moved here because the spec page itself must contain certainty
4 rather than "undecided potential ideas"
6 the operations it has that I was going to propose:
8 * fetch_add
9 * fetch_xor
10 * fetch_or
11 * fetch_and
12 * fetch_umax
13 * fetch_smax
14 * fetch_umin
15 * fetch_smin
16 * exchange
18 as well as a few I wasn't going to propose (they seem less useful to me):
20 * compare-and-swap-not-equal
21 * fetch-and-increment-bounded
22 * fetch-and-increment-equal
23 * fetch-and-decrement-bounded
24 * store-twin
26 The spec also basically says that the atomic memory operations are only
27 intended for when you want to do atomic operations on memory, but don't
28 want that memory to be loaded into your L1 cache.
30 imho that restriction is specifically *not* wanted, because there are
31 plenty of cases where atomic operations should happen in your L1 cache.
33 I'd guess that part of why those atomic operations weren't included in
34 gcc or clang as the default implementation of atomic operations (when
35 the appropriate ISA feature is enabled) is because of that restriction.
37 imho the cpu should be able to (but not required to) predict whether to
38 send an atomic operation to L2-cache/L3-cache/etc./memory or to execute
39 it directly in the L1 cache. The prediction could be based on how often
40 that cache block was accessed from different cpus, e.g. by having a
41 small saturating counter and a last-accessing-cpu field, where it would
42 count how many times the same cpu accessed it in a row, sending it to the
43 L1 cache if that's more than some limit, otherwise doing the operation
44 in the L2/L3/etc.-cache if the limit wasn't reached or a different cpu
45 tried to access it.