DIP20: Volatile read/write intrinsics

[Alex Rønne Petersen]

On 10-10-2012 20:57, Adam D. Ruppe wrote:
> On Wednesday, 10 October 2012 at 19:09:34 UTC, deadalnix wrote:
>> We discussed it quite a lot already, but I still think volatile must
>> be a qualifier of the memory, and not of the statement.
>
> I barely know anything about this, but couldn't that be done as a
> library type? Something like a smart pointer.
>
> This does bring me to a question though. What if you had:
>
> void foo() {
>     volatile_read();
> }
>
> foo();
> bar();
> foo();
>
> Is the call to foo allowed to be reordered? I imagine it has to mark the
> whole call chain upwards as internally volatile too.

Good observation!

So here's the thing: The compiler is only allowed to reorder calls to 
functions where it knows the source of the function and can thus figure 
out what it does.

So, for functions that it does not have the source code for, it must 
*never* reorder, *ever*. This is one reason volatileLoad and 
volatileWrite should not be pure: They directly affect code that 
surrounds calls to them.

For functions where the compiler does have the source code, it can 
trivially figure out if reordering is OK, based on whether there are any 
calls to volatileLoad and volatileStore somewhere down the call graph. 
It gets even easier to do these checks when inlining is involved (since 
then the volatileLoad/volatileStore calls are readily visible in context).

-- 
Alex Rønne Petersen
alex at lycus.org
http://lycus.org