[Libre-soc-bugs] [Bug 236] Atomics Standard writeup needed

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=236

--- Comment #24 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #20)
> (In reply to Jacob Lifshay from comment #19)
> > (In reply to Luke Kenneth Casson Leighton from comment #17)
> > > conclusion: oops.  it's ok for amo* but not ok for amo_rw, that would
> > > require a drastic (multi-million-dollar impact) redesign of OpenCAPI.
> > 
> > well, all that needs to happen is 8/16-bit atomics have to transfer a cache
> > block to the cache (if not already there) instead of using opencapi
> > atomics...
> 
> you're missing the point.

i got your point, imho your point is just partially incorrect.
> 
> there is no "all that needs to happen" here.  i had not realised
> how tightly coupled lwat/stwat are into opencapi (i was half expecting
> it)
> 
> IBM will not think in terms of "instead of using opencapi".

I was never advocating for "instead of using opencapi", it would just use a
different part of opencapi: the part that allows a cpu to obtain exclusive
access to a cache block (M/E states in the MESI cache coherence model).

> aq and rl (acquire and release) will need to be additional opcodes in
> opencapi.

no they won't, memory ordering is handled by the cpu deciding when to issue
memory operations:
acquire -- all following memory ops are delayed till after the atomic op is
executed.
release -- the atomic op is delayed till after all preceding memory ops are
executed.
acq_rel -- do both the above
seq_cst -- do both the above, as well as synchronize across the whole
system...essentially what the `sync` instruction already mostly does.

as an example, tilelink has no memory fence operations, and all amo operations
have no aq/rl bits in tilelink -- they're all handled by the cpu.

-- 
You are receiving this mail because:
You are on the CC list for the bug.