Re: Is Intel exceptionally unsuccessful as an architecture designer?

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 <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?

 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