volatile, shared in LDC

[Dan Olson via digitalmars-d-ldc]

"Mike" <none at 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