Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!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: Re: Memory ordering
Date: Sun, 17 Nov 2024 15:17:52 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 22
Message-ID: <2024Nov17.161752@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> <2024Nov15.082512@mips.complang.tuwien.ac.at> <vh7ak1$3cm56$1@dont-email.me> <20241115152459.00004c86@yahoo.com> <vh8bn7$3j6ql$1@dont-email.me> <vhb2dc$73fe$1@dont-email.me> <vhct2q$lk1b$2@dont-email.me>
Injection-Date: Sun, 17 Nov 2024 16:29:48 +0100 (CET)
Injection-Info: dont-email.me; posting-host="7bb429d81c53ecf7011d4dcadd63107a";
	logging-data="730220"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18j77ip/PS9aw1DPOb3ooXP"
Cancel-Lock: sha1:JV3P/TyybxU+I1tIBof8MImM1Og=
X-newsreader: xrn 10.11
Bytes: 2222

jseigh <jseigh_es00@xemaps.com> writes:
>Even if the hardware memory
>memory model is strongly ordered, compilers can reorder stuff,
>so you still have to program as if a weak memory model was in
>effect.

That's something between the user of a programming language and the
compiler.  If you use a programming language or compiler that gives
weaker memory ordering guarantees than the architecture it compiles
to, that's your choice.  Nothing forces compilers to behave that way,
and it's actually easier to write compilers that do not do such
reordering.

>Or maybe disable reordering or optimization altogether
>for those target architectures.

So you want to throw out the baby with the bathwater.

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