DIP62: Volatile type qualifier for unoptimizable variables in embedded programming

[John Colvin via Digitalmars-d]

On Thursday, 17 July 2014 at 19:56:23 UTC, Johannes Pfau wrote:
> Am Thu, 17 Jul 2014 11:43:04 -0700
> schrieb Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:
>
>> On 7/17/14, 9:06 AM, John Colvin wrote:
>> > On Thursday, 17 July 2014 at 15:58:05 UTC, Andrei 
>> > Alexandrescu
>> > wrote:
>> >> I think an approach based on functions peek/poke is a lot 
>> >> more
>> >> promising. D programs must define sequences of std calls 
>> >> anyway,
>> >> otherwise even the simplest programs that use 
>> >> writeln("What's your
>> >> name?") followed by a readln() are incorrect. So in a way 
>> >> peek/poke
>> >> come for "free".
>> >
>> > Could you expand on this "sequences of calls"? What exactly 
>> > do you
>> > mean by defining it?
>> 
>> For example if you run this C program:
>> 
>> printf("ur name: ");
>> fflush(stdout);
>> scanf("%s", &name);
>> printf("Hello, %s!", name);
>> 
>> it's guaranteed the order of calls is preserved.

only because rearranging those cannot be proved to create the 
same observable semantics (in this case of course it can be 
actively disproved). That doesn't apply to all sequences of 
function calls, thankfully.

> Function calls are actually compiler barriers in every C (like)
> compiler, I guess that's even in the standard. Relying on this 
> too
> much can be dangerous with inlining though.

As I understand it (I'm not a compiler writer or a C standard 
expert):

*Opaque* function calls are a compiler memory barrier in C and 
that's only by necessity (that opaque function could contain a 
memory barrier, amongst other problems).

If the compiler can guarantee to maintain the same visible 
semantics of defined behaviour it can rearrange function calls 
just as freely as anything else.