You may have seen Mike's talk about D on embedded systems and were surprised about Iain's comment that using 'shared' as a replacement for 'volatile' is actually only possible because of a bug in gdc.

DIP62 describes how to solve this problem and make embedded programming
a first-class citizen in D:
http://wiki.dlang.org/DIP62

This is the only language change necessary to make D really perfect for
embedded programming, so it's important that we fix this.
There are some more implementation issues, but these aren't language
problems and easy to fix.

The DIP provides detailed descriptions and rationales so I won't copy/paste this information into this post. But please:

* Read the complete DIP before commenting. I'd took a long time to
  write, so it's OK if it takes some time to read ;-) Also your question
  might already be answered.
* Although it's explained in the DIP in detail, I must mention this
  here again: We need _first-class_ support for embedded programming in
  D. Workarounds might be available (peek/poke, inline asm) but it will
  be obvious to most C programmers that C has got the better solution
  with the volatile qualifier. D enthusiasts might be happy if they can
  use workarounds to make D work on microcontrollers. But if we want to
  appeal to outsiders we can't confront them with obvious workarounds
  and hacks as the first thing they see in D. And if they think embedded
  programming is a second class citizen in D, why should they use it
  at all?

On 07/15/14 18:25, Johannes Pfau via Digitalmars-d wrote:
>   here again: We need _first-class_ support for embedded programming in
>   D. Workarounds might be available (peek/poke, inline asm) but it will
>   be obvious to most C programmers that C has got the better solution
>   with the volatile qualifier. D enthusiasts might be happy if they can

Compiler barriers are not "workarounds". "volatile" is not a "better solution". It's used in C only because it's defined and reasonably portable; barriers are a language extension, hence dialect specific.

First class support for "embedded programming" would be defining barriers, not transplanting C's volatile. You can already express all the described volatile semantics in GDC's D dialect, in a completely portable way and without using a single asm instruction. What's missing is just a defined standard interface which can be supported by all D compilers.

artur

Artur Skawina:

> You can already express
> all the described volatile semantics in GDC's D dialect, in a
> completely portable way and without using a single asm instruction.

What's GDC syntax?

Bye,
bearophile

Am Tue, 15 Jul 2014 19:03:52 +0200
schrieb Artur Skawina via Digitalmars-d <digitalmars-d@puremagic.com>:

> Compiler barriers are not "workarounds". "volatile" is not a "better solution". It's used in C only because it's defined and reasonably portable; barriers are a language extension, hence dialect specific.
> 
> First class support for "embedded programming" would be defining barriers, not transplanting C's volatile. You can already express all the described volatile semantics in GDC's D dialect, in a completely portable way and without using a single asm instruction. What's missing is just a defined standard interface which can be supported by all D compilers.
> 
> artur

Did you even read the section that explains why volatility is a property of the memory address and not of the access (4.2.3)? What's your response to that?

Why do shared variables have the privilege to prevent accessing shared memory in inappropriate ways but it's fine to place the burden of checking that all accesses to volatile memory are backed by compiler barriers to the user? How is that 'first class' support?

I intentionally didn't put any technical information into this post to make sure that people actually read the DIP and the only think you responded to were the non-technical parts of my first post...

Am Tue, 15 Jul 2014 17:07:26 +0000
schrieb "bearophile" <bearophileHUGS@lycos.com>:

> Artur Skawina:
> 
> > You can already express
> > all the described volatile semantics in GDC's D dialect, in a
> > completely portable way and without using a single asm
> > instruction.
> 
> What's GDC syntax?
> 
> Bye,
> bearophile

That's off-topic, but its asm("" : : : "memory");

On 15 July 2014 17:25, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> You may have seen Mike's talk about D on embedded systems and were surprised about Iain's comment that using 'shared' as a replacement for 'volatile' is actually only possible because of a bug in gdc.
>
> DIP62 describes how to solve this problem and make embedded programming
> a first-class citizen in D:
> http://wiki.dlang.org/DIP62
>
> This is the only language change necessary to make D really perfect for
> embedded programming, so it's important that we fix this.
> There are some more implementation issues, but these aren't language
> problems and easy to fix.
>
> The DIP provides detailed descriptions and rationales so I won't copy/paste this information into this post. But please:
>
> * Read the complete DIP before commenting. I'd took a long time to
>   write, so it's OK if it takes some time to read ;-) Also your question
>   might already be answered.
> * Although it's explained in the DIP in detail, I must mention this
>   here again: We need _first-class_ support for embedded programming in
>   D. Workarounds might be available (peek/poke, inline asm) but it will
>   be obvious to most C programmers that C has got the better solution
>   with the volatile qualifier. D enthusiasts might be happy if they can
>   use workarounds to make D work on microcontrollers. But if we want to
>   appeal to outsiders we can't confront them with obvious workarounds
>   and hacks as the first thing they see in D. And if they think embedded
>   programming is a second class citizen in D, why should they use it
>   at all?
>


More simply put.  A volatile keyword would be strictly for hardware access without locks.  We have 'shared' for inter-thread communication, and for ensuring that there is an ordered relationship between threads when accessing the same data location at the same time.

Regards
Iain

On 07/15/14 19:07, bearophile via Digitalmars-d wrote:
> Artur Skawina:
> 
>> You can already express
>> all the described volatile semantics in GDC's D dialect, in a
>> completely portable way and without using a single asm instruction.
> 
> What's GDC syntax?

Some examples: http://forum.dlang.org/post/501A6E01.7010809@gmail.com

It can all be wrapped in "saner" templates and structs (for mmapped register banks etc). Johannes specifically didn't ask for mem barriers, cpu barriers or atomicity, just for compiler optimization barriers -- these don't need 'volatile'.

artur

"Johannes Pfau"  wrote in message news:lq3nf4$rbp$1@digitalmars.com...

> Did you even read the section that explains why volatility is a property
> of the memory address and not of the access (4.2.3)? What's your
> response to that?

This is true, and it's the ideal I guess, but I'm not sure that it makes it worth extending the type system for.

My use of volatile in C consists entirely of

#define SOME_REGISTER (*(volatile unsigned *)(BASE + OFFSET))

And this could easily be done in D with a wrapper around peek/poke functions. (assuming they're intrinsics and inlining/optimization works correctly)

So, the complexity it adds to the type system and overloading etc is not worth it for my use cases.  What are the other use cases where it pulls its weight? 

On Tuesday, 15 July 2014 at 17:13:09 UTC, Johannes Pfau wrote:
> Why do shared variables have the privilege to prevent accessing shared
> memory in inappropriate ways but it's fine to place the burden of
> checking that all accesses to volatile memory are backed by compiler
> barriers to the user? How is that 'first class' support?

Maybe it can be automated by a wrapper template?

struct Volatile(T)
{
  T val;
  void opAssign(T v)
  {
    volatile_store(val, v);
  }
}

extern(C) Volatile!byte led;

foreach(i;0..10)
{
  led=0;
  led=1; //blink
}

On 07/15/14 19:11, Johannes Pfau via Digitalmars-d wrote:
> Am Tue, 15 Jul 2014 19:03:52 +0200
> schrieb Artur Skawina via Digitalmars-d <digitalmars-d@puremagic.com>:
> 
>> Compiler barriers are not "workarounds". "volatile" is not a "better solution". It's used in C only because it's defined and reasonably portable; barriers are a language extension, hence dialect specific.
>>
>> First class support for "embedded programming" would be defining barriers, not transplanting C's volatile. You can already express all the described volatile semantics in GDC's D dialect, in a completely portable way and without using a single asm instruction. What's missing is just a defined standard interface which can be supported by all D compilers.
> 
> Did you even read the section that explains why volatility is a property of the memory address and not of the access (4.2.3)? What's your response to that?

You're assuming that the raw memory needs to be exposed. It doesn't.

IOW, instead of:

   struct HWRegs { uint a; uint b; /*...*/ }
   auto ptr = cast(HWReg*)0xc0000000;

do:

   struct HWRegs { uint a; uint b; /*...*/ }
   auto ptr = cast(Volatile!HwRegs*)0xc0000000;

and the Volatile template will magically add all the access barriers.

> Why do shared variables have the privilege to prevent accessing shared memory in inappropriate ways but it's fine to place the burden of checking that all accesses to volatile memory are backed by compiler barriers to the user? How is that 'first class' support?

See above; just don't expose mmapped regs as normal memory.

> I intentionally didn't put any technical information into this post to make sure that people actually read the DIP and the only thing you responded to were the non-technical parts of my first post...

Because the technical details don't matter when the point is that 'volatile' is not necessary. I did read your DIP, when you announced it originally and also the gdc ml discussion that followed. I have not seen any good argument for introducing a volatile type qualifier. Could you show one (concrete) example where using 'volatile' is better than my approach?

artur