ARM bare-metal programming in D (cont) - volatile

[Walter Bright]

On 10/24/2013 11:33 AM, eles wrote:
> On Thursday, 24 October 2013 at 17:02:51 UTC, Walter Bright wrote:
>> On 10/24/2013 4:18 AM, eles wrote:
>>> On Thursday, 24 October 2013 at 06:48:07 UTC, Walter Bright wrote:
>>>> On 10/23/2013 11:19 PM, Mike wrote:
>> Like I said, nobody (on the standards committees) could agree on exactly what
>> that meant.
>
> The standard committees might not agree, but there is somebody out there that
> really knows very accurately what that should mean: that somebody is the
> hardware itself.
>
> Just imagine the best hardware example that you have at hand: the microprocessor
> that you are programming for.
>
> It writes on the bus, there is a short delay before the signals are guaranteed
> to reach the correct levels, then reads the memory data and so on.
>
> You cannot read the data before the delay passes. You cannot say "well, I could
> postpone the writing on the address on the bus, let's read the memory location
> first" -- or you would read garbage. Or you cannot say: well, first I will
> execute the program without a processor then, when the user is already pissed
> off, I would finally execute all those instructions at once. Too bad that the
> computer is already flying through the window at that time.
>
> You command that processor from the compiler. Now, the thing that's needed is to
> give a way to do the same (ie commanding a hardware) from the program compiled
> by the compiler.

The trouble with that is since the standards people cannot agree on what 
volatile means, you're working with a compiler that has non-standard behavior. 
This is not portable and not reliable.