Re: Arm ldaxr / stxr loop question

aph@littlepinkcloud.invalid wrote:

Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

On 11/12/2024 4:14 AM, aph@littlepinkcloud.invalid wrote:

>
One other thing to be aware of is that the StoreLoad barrier needed
for sequential consistency is logically part of an LDAR, not part of a
STLR. This is an optimization, because the purpose of a StoreLoad in
that situation is to prevent you from seeing your own stores to a
location before everyone else sees them.

>
Fwiw, even x86/x64 needs StoreLoad when an algorithm depends on a
store followed by a load to another location to hold. LoadStore is
not strong enough. The SMR algorithm needs that. Iirc, Peterson's
algorithms needs it as well.

 That's right, but my point about LDAR on AArch64 is that you can get
sequential consistency without needing a StoreLoad. LDAR can peek
inside the store buffer and, much of the time, determine that it isn't
necessary to do a flush. I don't know if Arm were the first to do
this, but I don't recall seeing it before. It is a brilliant idea.

Isn't this just reusing the normal forwarding network?
If not found, you do as usual and start a regular load operation, but now you also know that you can skip the flushing of the same?
PS. I do agree that it is a good idea (even patent-worthy?), but not brilliant since it is so very obvious in hindsight.
To me brilliant is something that still isn't obvious after larning about it.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"