Re: Is Intel exceptionally unsuccessful as an architecture designer?

On Mon, 23 Sep 2024 0:53:35 +0000, jseigh wrote:

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. :)

Its a free forum

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.

When you include stores from devices into memory, we agree.
A LD should return the last written value.
When you include device control registers; all bets are off.

Regarding memory barriers, that depends on the hardware
memory model and the program logic assuming one knows
how to do concurrent algorithms.

In particular, we are talking about a sequence of instructions
with the properties:: a) an external observer can see only
the previous or new values of a concurrent data structure
and none of the intermediate changes, and b) should the
event fail somewhere in the middle, no-one saw any of
the intermediate state, either.
The event is bigger than the memory reference instruction.
And finally, getting the MemBarIzation correct seems to
be beyond many-most programmers leading to error prone
applications.

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.

When only 1 x86 would fit on a die, it really did not mater
much. I was at AMD when they were designing their memory
model.

Joe Seigh