Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Memory ordering
Date: Wed, 4 Dec 2024 19:42:11 +0000
Organization: Rocksolid Light
Message-ID: <84b507bf21ed59bc56ef5391df65e951@www.novabbs.org>
References: <vfono1$14l9r$1@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> <2024Nov17.161752@mips.complang.tuwien.ac.at> <vhh16e$1lp5h$1@dont-email.me> <2024Dec3.100144@mips.complang.tuwien.ac.at> <vin2rp$3ofc$1@dont-email.me> <3aa9f0a3d3dde86193abb1c01e52d03a@www.novabbs.org> <pz%3P.63771$vLg2.34039@fx17.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="1283835"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$f5bSzZrXO0YrqTb09rLUyON54XEiz.dZJKrKl3xeMdje1uNcSMleW
Bytes: 2430
Lines: 31

On Wed, 4 Dec 2024 16:37:41 +0000, Scott Lurndal wrote:

> mitchalsup@aol.com (MitchAlsup1) writes:
>>On Tue, 3 Dec 2024 13:59:18 +0000, jseigh wrote:
>>
>>> The compiler is allow to reorder code as long as it knows the
>>> reordering can't be observed or detected.
>>
>>With exceptions enabled, this would allow for almost no code
>>movement at all.
>>
>>>                                           If there are places
>>> in the code it doesn't know this can't happen it won't optimize
>>> across it, more or less.
>>
>>The problem is HOW to TELL the COMPILER that these memory references
>>are "more special" than normal--when languages give few mechanisms.
>
> C and C++ have the 'volatile' keyword for this purpose.

What if you want the volatile attribute only to hold
on an inner block::

     {
          int i = ...;
          ...      // I is not volitile here
          {
               ... // I is     volitile in here
          }
          ...      // I is not volitile here
          ...
     }