The ability to do "volatile" memory access has come up here at DConf.

Right now I'm utilizing a bug in GDC as a feature to do what I need.  GDC implements shared as volatile, so I'm able to use this "bug" to my advantage.  Iain has proposed a solution here (http://bugzilla.gdcproject.org/show_bug.cgi?id=126).  Iain has explained to me that shared and volatile actually have similar, but different semantics.

Walter has proposed use peek() and poke() built-ins implemented in the runtime that can be given special treatment by the compiler.

I would like to find a *universal* D solution to this, so I can have nice portable code that works across all compilers, so I'd like to ask the LCD contributors to chime in with their thoughts.

Does LDC currently have a solution for this?  I hope we can all come to some agreement on an implementation that is uniform across all compilers.  Please participate in the GDC discussion and let us know your thoughts.

Thanks,
Mike

"Mike" <none@none.com> writes:

> The ability to do "volatile" memory access has come up here at DConf.
>
> Right now I'm utilizing a bug in GDC as a feature to do what I need. GDC implements shared as volatile, so I'm able to use this "bug" to my advantage.  Iain has proposed a solution here (http://bugzilla.gdcproject.org/show_bug.cgi?id=126).  Iain has explained to me that shared and volatile actually have similar, but different semantics.
>
> Walter has proposed use peek() and poke() built-ins implemented in the
> runtime that can be given special treatment by the compiler.
>
> I would like to find a *universal* D solution to this, so I can have nice portable code that works across all compilers, so I'd like to ask the LCD contributors to chime in with their thoughts.
>
> Does LDC currently have a solution for this?  I hope we can all come to some agreement on an implementation that is uniform across all compilers.  Please participate in the GDC discussion and let us know your thoughts.
>
> Thanks,
> Mike

I don't know LDC solution, but it looks like shared is not like a C volatile.

In my C experience, volatile can work, but only with simple memory-mapped registers and variables set by interrupt handlers. Setting/clearing individual bits in registers sometimes didn't do what was intended (eg fifoctl |= 0x04 may write all bits in register fifoctl instead of bit set and sometimes that is not what you want). Vender C compilers for specific chips usually have extensions to set/get/tst individual bits like bit types or have bit operators on ptrs (fifoctl.2 = 1 to set bit 2 in fifo register).

When I use gcc for embedded work, there is usually a lot of disassembly to make sure the compiler is generating the correct instructions to access registers. Sometimes I just write assembly instead of relying on compiler behavior.

I don't know the answer, but I don't think volatile is enough. Maybe take peek/poke instrinsics a little further to provide common memory access operations that all D compilers can provide and do the right thing for their target cpu, like use bitset instruction.

load, store, bitset/clr/tst, etc
-- 
Dan

One of the solution can be
template Volatile(T)
{
  alias Volatile = __gdc_volatile__(T);
}

And each compiler defines this template in a way which suits it best, because stock DMD frontend can't accept arbitrary keywords, so you need to hide them behind some common syntax.

Without keyword:
template Volatile(T)
{
  pragma(constructVolatileType)
  alias Volatile = T;
}

Usage:

shared Volatile!int var; //global volatile int variable