DIP62: Volatile type qualifier for unoptimizable variables in embedded programming

Mike via Digitalmars-d digitalmars-d at puremagic.com
Tue Jul 15 19:47:13 PDT 2014


On Tuesday, 15 July 2014 at 16:27:53 UTC, Johannes Pfau wrote:
> You may have seen Mike's talk about D on embedded systems and 
> were
> surprised about Iain's comment that using 'shared' as a 
> replacement for
> 'volatile' is actually only possible because of a bug in gdc.
>
> DIP62 describes how to solve this problem and make embedded 
> programming
> a first-class citizen in D:
> http://wiki.dlang.org/DIP62

Well, this was posted just as I went to sleep for the night (I'm 
in Asia), so I wasn't able to get my word in until the end.  
Sorry!

DIP62 is the exemplary DIP:  well researched and thoroughly 
specified.  I was actually in favor of peek/poke intrinsics until 
the DIP62 and its citations took me to school.

I still believe that the type qualifier is the right tool for the 
job, because despite having peek/poke intrinsics, users will 
still navigate towards making a volatile type to wrap peek/poke, 
as has already been proposed [1] Volatile!(T), [2] struct 
VolatilePointerToUint, etc...  It actually justifies DIP62, IMO.

After reading through this thread, the only argument against 
DIP62 that really made much sense was the cost/benefit tradeoff 
in the implementation.  I can't speak to the complexity of the 
implementation, but I do concede that the use of volatile will 
only be used in the lowest layer of hardware abstraction 
(although it will be used quite often there), and the workarounds 
are not burdensome.  The type qualifier would avoid such nonsense.

Anyway, I can see where this is going[3], so I guess I'll have to 
patch my airplane[4] with a template to make it fly :(

[1] 
http://forum.dlang.org/post/eznqslwpnxfnwlgzlsll@forum.dlang.org
[2] http://forum.dlang.org/post/lq4hqi$1j77$1@digitalmars.com
[3] https://github.com/D-Programming-Language/dmd/pull/3773
[4] 
http://www.youtube.com/watch?feature=player_detailpage&v=WKRRgcEk0wg#t=65

Mike


More information about the Digitalmars-d mailing list