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.