Am Sun, 01 Feb 2015 13:45:24 -0800
schrieb Walter Bright <newshou...@digitalmars.com>:
> On 2/1/2015 3:22 AM, Johannes Pfau wrote:
> > Am Sun, 01 Feb 2015 02:11:42 -0800
> > schrieb Walter Bright <newshou...@digitalmars.com>:
> >> core.bitop.volatileLoad() and volatileStore() are implemented, and
> >> do the job. They are compiler intrinsics that result in single
> >> instructions. They support 8, 16, 32 and 64 bit loads and stores.
> >
> > I think everybody agreed that these low-level primitives can't be
> > used in end-user code.
>
> I apparently missed that discussion. (In any case, dealing with
> memory mapped I/O is not a usual programming task, I expect a
> programmer doing it will be more sophisticated.)
You keep saying that, but it's simply not true. It's a common task when
programming microcontrollers. And people working on microcontrollers
are often electrical engineers. Programming beginner courses in EE
teach almost nothing, especially not why volatile is necessary or how
it propagates with pointers etc. Usually those people just don't use
volatile as long as their code works. Once it breaks they add volatile
everywhere till it works again.
>
> > We can generate nice wrappers (nicer than C code),
> > which perform as well as C code, but only with force-inline _and_
> > enabled optimizations (we essentially need heavy constant folding).
>
> The compiler intrinsics participate in all optimizations.
Not sure what that's supposed to mean. The backend can generate
more efficient code if it knows that an address is a literal value. If
you add wrappers (void f(void* p) {volatileLoad(p)}) the information
that p is a constant is a literal is lost and needs to be recovered
by the backend, which is only done with enabled backend optimizations.
