H1 2015 Priorities and Bare-Metal Programming

[Johannes Pfau via Digitalmars-d]

Am Mon, 02 Feb 2015 02:49:48 -0800
schrieb Walter Bright <newshound2 at digitalmars.com>:

> On 2/2/2015 1:24 AM, Johannes Pfau wrote:
> > 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.
> 
> Having a volatile type is not going to make things better for such
> people. In fact, it may make things worse. It's harder to muck up
> volatileLoad() and volatileStore().
> 

Wrong: wrappers are provided by the library. Users simply do stuff like
PORTB.pin0 = Level.high;

they never have to use volatile directly. And it's actually the same in
C which provides macros.

I wrote this in reply to your statements that wrappers are not
necessarily, of course you didn't quote that part. Without wrappers,
end users do have to use volatileLoad/Store by themselves and now they
do need to know what volatile is, where it's necessary, ...

> 
> >> 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.
> 
> Please try it before deciding it does not work.

I guess one ad hominem wasn't enough?
http://goo.gl/Y9OFgG

_Dmain:
	push   rbp
	mov    rbp,rsp
	sub    rsp,0x10
	mov    rax,0x5                      <==
	mov    QWORD PTR [rbp-0x8],rax
	mov    ecx,DWORD PTR [rax]          <== a register based load

The instruction it should generate is
mov ecx, [0x5]

Not sure if it's actually more efficient on X86 but it makes a huge
difference on real microcontroller architectures.