• Mike (20/20) May 23 2014 The ability to do "volatile" memory access has come up here at
• Dan Olson (22/40) May 24 2014 I don't know LDC solution, but it looks like shared is not like a C
• Kagamin (8/8) May 25 2014 One of the solution can be
• Kagamin (8/8) May 25 2014 Without keyword:

"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

Dan Olson <zans.is.for.cans yahoo.com> writes:

"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

"Kagamin" <spam here.lot> writes:

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.

"Kagamin" <spam here.lot> writes:

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

Usage:

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