H1 2015 Priorities and Bare-Metal Programming

Johannes Pfau via Digitalmars-d digitalmars-d at puremagic.com
Mon Feb 2 01:24:59 PST 2015


Am Sun, 01 Feb 2015 13:45:24 -0800
schrieb Walter Bright <newshound2 at digitalmars.com>:

> On 2/1/2015 3:22 AM, Johannes Pfau wrote:
> > Am Sun, 01 Feb 2015 02:11:42 -0800
> > schrieb Walter Bright <newshound2 at 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.



More information about the Digitalmars-d mailing list