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

[Mike]

On Thursday, 24 October 2013 at 19:11:03 UTC, Walter Bright wrote:
> 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.

There should be some way, in the D language, to tell the compiler 
  "Do exactly what I say here, and don't try to be clever about 
it" without introducing unnecessary (and unfortunate) overhead.  
It doesn't have to be /volatile/.

/shared/ may be the solution here, but based on a comment by Iain 
Buclaw 
(http://forum.dlang.org/post/mailman.2454.1382619958.1719.digitalmars-d@puremagic.com) 
it seems there could be some disagreement on what this means to 
compiler implementers.  I don't see why "shared" could not only 
mean "shared by more than one thread/cpu", but also "shared by 
external hardware peripherals".

Maybe /shared/'s definition needs to be further defined to ensure 
all compilers implement it the same way, and be unambiguous 
enough to provide a solution to this /volatile/ debate.

Using peek and poke functions is, well, nah... Better methods 
exist.  Using inline assembly is a reasonable alternative, as is 
linking to an external C library, but why use D then?  Is 
low-level/embedded software development a design goal of the D 
language?