On Thursday, 7 May 2015 at 16:04:56 UTC, Jens Bauer wrote:
So back to what originally triggered this post; this is what
the question is actually about:
If writing a driver for <platform X>, how is reading/writing
hardware registers usually done in D ?
Here's my pre 2.067 code for `volatile` semantics
@inline T volatileLoad(T)(T* a)
{
asm { "" ::: "memory"; };
return *cast(shared T*)a;
}
@inline void volatileStore(T)(T* a, in T v)
{
asm { "" ::: "memory"; };
*cast(shared T*)a = v;
}
As Iain showed, shared does not provide any order guarantees, so
that's why I added the asm { "" ::: "memory"; }; memory barrier.
This code, however, is still incorrect because it uses a bug in
GDC as a feature. Iain explained that bug here:
https://youtu.be/o5m0m_ZG9e8?t=3141
There's also a post here that shows a volatileLoad/Store
implementation using memory barriers without shared
(http://forum.dlang.org/post/[email protected]), but
when I tried it with my cross-compiler, I got an ICE.
Furthermore, I don't even understand it. I don't understand
exactly what the +g and +m constraints do, and I hate using code
I don't understand.
Once 2.067 is properly merged and implemented, none of this will
be necessary anyway as volatileLoad/Store intrinsics were
introduced. That being said, you will still have to add some
boilerplate around volatileLoad/Store to make the syntax
tolerable. Johannes has a nice implementation of Volatile!T for
that purpose here (http://dpaste.dzfl.pl/dd7fa4c3d42b). I have
my own CTFE Template implementation here
(https://github.com/JinShil/stm32f42_discovery_demo/blob/master/source/stm32f42/mmio.d).
In terms of shared, I think the following thread is quite
telling:
http://forum.dlang.org/post/[email protected]. Based
on that, I wouldn't trust shared for anything, and I think it
should just be ignored altogether. See also
http://p0nce.github.io/d-idioms/#The-truth-about-shared
I'm not sure what to do yet for synchronized/atomic access. If I
had to do in now, I'd probably just stick with C-like techniques.
Mike
