Deutsch   English   Français   Italiano  
<8c12c9a542abad2e2768162e39ea40a5@www.novabbs.org>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Arm ldaxr / stxr loop question
Date: Wed, 13 Nov 2024 00:29:42 +0000
Organization: Rocksolid Light
Message-ID: <8c12c9a542abad2e2768162e39ea40a5@www.novabbs.org>
References: <vfono1$14l9r$1@dont-email.me> <YROdnVIXfKmwYrn6nZ2dnZfqn_GdnZ2d@supernews.com> <vg5tf7$3tqmi$2@dont-email.me> <vgm0g1$3c2t2$3@dont-email.me> <zwwXO.842112$_o_3.379966@fx17.iad> <vgm4vj$3d2as$1@dont-email.me> <vgm5cb$3d2as$3@dont-email.me> <OnzXO.657386$1m96.281665@fx15.iad> <TfKXO.658488$1m96.146506@fx15.iad> <T99YO.79275$MoU3.7336@fx36.iad> <3lGdnVvGQIAq2676nZ2dnZfqnPGdnZ2d@supernews.com> <vh0jo6$1q1hl$3@dont-email.me> <0TmdnaP6ecXoQ676nZ2dnZfqn_adnZ2d@supernews.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="2194336"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
X-Rslight-Site: $2y$10$GpfPgAtZ9ZJtS.Av.xGyNefOM04k0daZb9.F0CHwjaCfuqFtZflr.
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 2832
Lines: 28

On Tue, 12 Nov 2024 23:02:13 +0000, 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.

1990-1992: I was working on Mc88120. It had a conditional cache--a
place to store store-data until the store instruction became consistent.
After becoming consistent, the store data would migrate to L1 or on
to DRAM, ... This structure could be probed for memory order rather
similar to what ARM is doing.
>
> Andrew.