Path: ...!feeds.phibee-telecom.net!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Paul A. Clayton" <paaronclayton@gmail.com>
Newsgroups: comp.arch
Subject: Re: Is Intel exceptionally unsuccessful as an architecture designer?
Date: Sun, 22 Sep 2024 15:37:02 -0400
Organization: A noiseless patient Spider
Lines: 37
Message-ID: <vcprkv$2asrd$1@dont-email.me>
References: <memo.20240913205156.19028s@jgd.cix.co.uk>
 <vcda96$3p3a7$2@dont-email.me>
 <21028ed32d20f0eea9a754fafdb64e45@www.novabbs.org>
 <RECGO.45463$xO0f.22925@fx48.iad> <20240918190027.00003e4e@yahoo.com>
 <vcfp2q$8glq$5@dont-email.me> <jwv34lumjz7.fsf-monnier+comp.arch@gnu.org>
 <vckpkg$18k7r$2@dont-email.me> <vckqus$18j12$2@dont-email.me>
 <920c561c4e39e91d3730b6aab103459b@www.novabbs.org>
 <vcl6i6$1ad9e$1@dont-email.me>
 <d3b9fc944f708546e4fbe5909c748ba3@www.novabbs.org>
 <%dAHO.54667$S9Vb.39628@fx45.iad> <vcna56$1nlod$2@dont-email.me>
 <a7708487530552a53732070fe08d9458@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 22 Sep 2024 21:37:04 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5645eae8204df80f973f25404ee2db0b";
	logging-data="2454381"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+kwBRT4D9OOrh1OFU5yCY92VHjHUi6IfI="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.0
Cancel-Lock: sha1:1w9++qwnS1/n4edJotgDYqlG0sw=
In-Reply-To: <a7708487530552a53732070fe08d9458@www.novabbs.org>
Bytes: 3304

On 9/21/24 4:45 PM, MitchAlsup1 wrote:
> On Sat, 21 Sep 2024 20:26:13 +0000, Chris M. Thomasson wrote:
> 
>> On 9/21/2024 6:54 AM, Scott Lurndal wrote:
>>> mitchalsup@aol.com (MitchAlsup1) writes:
>>> https://www.marvell.com/products/cxl.html
>>
>> What about a weak coherency where a programmer has to use the 
>> correct
>> membars to get the coherency required for their specific needs? 
>> Along
>> the lines of UltraSPARC in RMO mode?
> 
> In my case, I suffered through enough of these to implement a
> memory hierarchy free from the need of any MemBars yet provide
> the performance of <mostly> relaxed memory order, except when
> certain kinds of addresses are touched {MMI/O, configuration
> space, ATOMIC accesses,...} In these cases, the core becomes
> {sequentially consistent, or strongly ordered} depending on the
> touched address.

If I understand correctly, atomic accesses (Enhances
Synchronization Facility) effective use a complete memory barrier;
software could effectively provide a memory barrier "instruction"
by performing an otherwise pointless atomic/ESF operation.

Are there no cases where an atomic operation is desired but
sequential consistency is not required? Or is this a tradeoff of
frequency/criticality and the expected overhead of the implicit
memory barrier? (Memory barriers may be similar to context
switches, not needing to be as expensive as they are in most
implementations.)

> As far as PCIe device to device data routing, this will all be
> based no the chosen virtual channel. Same channel=in order,
> different channel=who knows.