Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Memory ordering (was: Arm ldaxr / stxr loop question)
Date: Fri, 15 Nov 2024 07:25:12 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 57
Message-ID: <2024Nov15.082512@mips.complang.tuwien.ac.at>
References: <vfono1$14l9r$1@dont-email.me> <vgm4vj$3d2as$1@dont-email.me> <vgm5cb$3d2as$3@dont-email.me> <YfxXO.384093$EEm7.56154@fx16.iad> <vh4530$2mar5$1@dont-email.me> <-rKdnTO4LdoWXKj6nZ2dnZfqnPWdnZ2d@supernews.com> <vh5t5b$312cl$2@dont-email.me> <5yqdnU9eL_Y_GKv6nZ2dnZfqn_GdnZ2d@supernews.com>
Injection-Date: Fri, 15 Nov 2024 08:48:15 +0100 (CET)
Injection-Info: dont-email.me; posting-host="d078d746a4a6ddf3bbd175c365db7e4e";
	logging-data="3478014"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19crhKUIKNCC4smFwfIKUQe"
Cancel-Lock: sha1:bBN6ZrlIGriRTIH6VGC19nEv3fw=
X-newsreader: xrn 10.11
Bytes: 4236

aph@littlepinkcloud.invalid writes:
>Yes. That Alpha behaviour was a historic error. No one wants to do
>that again.

Was it an actual behaviour of any Alpha for public sale, or was it
just the Alpha specification?  I certainly think that Alpha's lack of
guarantees in memory ordering is a bad idea, and so is ARM's: "It's
only 32 pages" <YfxXO.384093$EEm7.56154@fx16.iad>.  Seriously?
Sequential consistency can be specified in one sentence: "The result
of any execution is the same as if the operations of all the
processors were executed in some sequential order, and the operations
of each individual processor appear in this sequence in the order
specified by its program."

However, I don't think that the Alpha architects considered the Alpha
memory ordering to be an error, and probably still don't, just like
the ARM architects don't consider their memory model to be an error.
I am pretty sure that no Alpha implementation ever made use of the
lack of causality in the Alpha memory model, so they could have added
causality without outlawing existing implementations.  That they did
not indicates that they thought that their memory model was right.  An
advocacy paper for weak memory models [adve&gharachorloo95] came from
the same place as Alpha, so it's no surprise that Alpha specifies weak
consistency.  

@TechReport{adve&gharachorloo95,
  author =       {Sarita V. Adve and Kourosh Gharachorloo},
  title =        {Shared Memory Consistency Models: A Tutorial},
  institution =  {Digital Western Research Lab},
  year =         {1995},
  type =         {WRL Research Report},
  number =       {95/7},
  annote =       {Gives an overview of architectural features of
                  shared-memory computers such as independent memory
                  banks and per-CPU caches, and how they make the (for
                  programmers) most natural consistency model hard to
                  implement, giving examples of programs that can fail
                  with weaker consistency models.  It then discusses
                  several categories of weaker consistency models and
                  actual consistency models in these categories, and
                  which ``safety net'' (e.g., memory barrier
                  instructions) programmers need to use to work around
                  the deficiencies of these models.  While the authors
                  recognize that programmers find it difficult to use
                  these safety nets correctly and efficiently, it
                  still advocates weaker consistency models, claiming
                  that sequential consistency is too inefficient, by
                  outlining an inefficient implementation (which is of
                  course no proof that no efficient implementation
                  exists).  Still the paper is a good introduction to
                  the issues involved.}
}

- anton
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>