H1 2015 Priorities and Bare-Metal Programming

[Walter Bright via Digitalmars-d]

On 2/2/2015 2:30 PM, Johannes Pfau wrote:
> I does: if the backend can't know that a value is known at compile time
> it cant use absolute addresses:
>
> void test(ubyte* ptr)
> {
>      volatileLoad(ptr); //Can't use literal addressing might be runtime
>      value
> }
>
> The context here is that pragma(address) allows avoiding one wrapper
> function. See below.

Again, that is simply an inlining issue.


> The pragma(address, 0x05) makes sure that the compiler backend always
> knows that PORTA is at 0x05.

Constant propagation and inlining do that. Both are standard optimizations that 
every compiler does. Adding language features on the presumption that compilers 
won't do that is like trying to fix the broken engine in your car by adding 
another engine in the trunk.


> -O mostly fixes performance problems, but adding an additional property
> function is still much uglier than declaring an extern variable with an
> address in many ways. (compiler bugs,

Language features should not be added because of compiler bugs.

> user-facing code,

Library wrapper types will be showing up more and more. How nice they are is up 
to the library designer.


> debug info, ...)

Symbolic debugging is always going to be an issue until there are debuggers that 
are better designed to work with D.


> Also it's a conceptually nice way for typed registers: You can read it
> as: I've got a Register of type PORT which is an extern variable located
> add a fixed address. PORT abstract away volatile access.

     auto a = PORT!0x1234;

looks nicer than:

     pragma(address, 0x1234) PORT a;