H1 2015 Priorities and Bare-Metal Programming

[Iain Buclaw via Digitalmars-d]

On 2 February 2015 at 17:06, Johannes Pfau via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> 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
>

The error DMD gives when optimizations are turned on is comical at best too.

Iain.