H1 2015 Priorities and Bare-Metal Programming

[Johannes Pfau via Digitalmars-d]

Am Tue, 03 Feb 2015 07:09:10 -0800
schrieb Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:

> On 2/3/15 12:17 AM, Johannes Pfau wrote:
> > Well I see that you're not even considering adding a simple pragma
> > to help embedded programming. In that case I see absolutely no
> > reason to continue working on that. You guys say "we lack expertise
> > so we cannot help directly" and you're in "search of champions" for
> > these areas. But whenever somebody working with D on embedded
> > systems actually comes up with an issue related to embedded
> > programming and propose solutions you simply dismiss it. Often even
> > based on vague statements like "that's not a common task".
> > http://wiki.dlang.org/Vision/2015H1
> 
> I think we need to work on better inlining. Which format (pragma vs. 
> attribute etc) is just tactical detail. Clearly there needs to be
> "best effort" and "won't compile unless it inlines" directives.
> 

I wasn't part of that discussion and I don't want to be part of it. In
the end I don't care how exactly force inline is implemented, as long
as it is implemented.

> Johannes, please let us know whether this is everything needed to
> float your boat. I'm unclear whether you believe "volatile" data is
> needed or not. If it's not, we're good; if it is, you need to redo
> your argument because it was poorly conducted.
> 

I was actually not arguing for any kind of 'volatile data' or
replacing volatileLoad/Store (in this discussion). 

> > pragma(address) could be trivially implemented now and I still think
> > it's a logical extension of the language, whereas global property
> > ref functions for this purpose are just hacks. Till D will have
> > full inline control rust will probably already have all the market
> > share in these areas. At least I'm not willing to invest any more
> > effort into this.
> 
> No need to get agitated over this. We're all on the same boat.
> 
> Rust also uses intrinsics for volatile loads and stores: 
> http://doc.rust-lang.org/core/intrinsics/. It does have a way to
> force inlining recommended to use with caution: 
> https://mail.mozilla.org/pipermail/rust-dev/2013-May/004272.html
> 
> 
> Andrei

That's a misunderstanding. I don't want to replace
volatileLoad/Store intrinsics or any other kind of volatile access.
pragma(address) is something completely different. I posted a full
example here: https://forum.dlang.org/post/maotpd$1ape$1@digitalmars.com

Basically it adds this feature:
extern __gshared int x; //extern variable, default mangled name
pragma(mangle, "noop") extern __gshared int y; //specify name
pragma(address, 0x05) extern __gshared int z; //specify address
=====================

It doesn't make z volatile or add any other magic. It simply declares
that z is a variable at a _fixed absolute_ location (compile time
constant). I even posted a link to a full working implementation, 80
loc.

It's very useful on embedded systems where you have data at fixed
locations. Why not access this data like any other extern data using
variables?

It does allow some nice patterns when _combined_ with volatileLoad/Store
but this seems to only confuse people. Here's a reduced example for
that:
http://pastebin.com/RGhKdm9i
__builtin_volatile_load <=> volatileLoad