Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: jseigh Newsgroups: comp.arch Subject: Re: Is Intel exceptionally unsuccessful as an architecture designer? Date: Sun, 22 Sep 2024 20:53:35 -0400 Organization: A noiseless patient Spider Lines: 70 Message-ID: References:

<21028ed32d20f0eea9a754fafdb64e45@www.novabbs.org> <20240918190027.00003e4e@yahoo.com>

<920c561c4e39e91d3730b6aab103459b@www.novabbs.org> <%dAHO.54667$S9Vb.39628@fx45.iad>

MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Mon, 23 Sep 2024 02:53:35 +0200 (CEST) Injection-Info: dont-email.me; posting-host="469a7820058845a3b597fefa81415f01"; logging-data="2532106"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18qWWQABJvJBtdaEsTlgz87" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:XEKiGBxBWmlaQfJLM2Nza1A5bC4= Content-Language: en-US In-Reply-To: Bytes: 4602 On 9/22/2024 5:39 PM, MitchAlsup1 wrote: > On Sun, 22 Sep 2024 19:37:02 +0000, Paul A. Clayton wrote: > >> 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 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? > > Probably--but in the realm of ATOMICs it is FAR better to be > a bit slower than to ever allow the illusion of atomicity to > be lost. This criterion is significantly harder when doing > multi-location ATOMIC stuff than single location ATOMIC stuff. > >> 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.) > > The R in RISC stands for Reduced. An ISA devoid of MemBar is > more reduced than one with MemBars. Programmers are rarely > in a position to understand all the cases where MemBar are > needed or not needed {{excepting our own Chris M. Thomasson}} > Not quite sure what we are talking about here but I won't let that stop me from commenting. :) As far as loads and stores go, if they are atomic then a load will not see a value that was not from some store. Regarding memory barriers, that depends on the hardware memory model and the program logic assuming one knows how to do concurrent algorithms. Speaking of memory models, remember when x86 didn't have a formal memory model. They didn't put one in until after itanium. Before that it was a sort of processor consistency type 2 which was a real impedance mismatch with what most concurrent software used a a memory model. Joe Seigh