[Bug 126] Add support for attribute to mark data as volatile.

Johannes Pfau via D.gnu d.gnu at puremagic.com
Tue Jun 24 07:12:37 PDT 2014


Am Tue, 24 Jun 2014 10:46:11 +0000
schrieb "Timo Sintonen" <t.sintonen at luukku.com>:

> To keep this thread going, I had a quick look at the reference 
> material of the dip and picked some thoughts.
> 
> In some languages volatile has a stronger meaning, like 
> guaranteeing an atomic access. In some languages it may not 
> guarantee anything.
> 
> In this proposal volatile is only for optimization, not for 
> protection. It does not add any code, it just prevents the 
> optimizer removing some code.
> 
> Read-modify-write and multi-word access are not guaranteed. The 
> user should be aware of possible failures and for example avoid 
> longer data types than the word size of the processor.
> 
> Volatile is never recommended to use for communicatin between 
> threads. It has been mentioned to be a reasonably good method to 
> exchange data with an interrupt program. It is the only 
> reasonable way to access hardware registers. The only others I 
> have seen are library functions and inline assembly and they are 
> not acceptable.
> 
Yes, that's exactly how I envision 'volatile'.

> 
> Walter has been against this and now also Martin. I think there 
> is no use to bring this to the main forum. I understand the point 
> that it is not very good to have something in the language specs 
> that can not be guaranteed.
I think we should at least try to bring this to the main newsgroup,
however I got distracted with other things and I want to extend the DIP
a little (Only rationale stuff, no technical changes). The
newsgroups have been quite busy lately and there've been discussions
about two new DIPs. Neither Andrei nor Walter even posted a response
in these threads so now is probably not a good time to start the
discussion on this DIP. 

Volatile loses much of it's use when it's compiler specific. Although
we could 'ignore' dmd there's also ldc. (However, as we already have
incompatible inline asm compared to dmd and ldc it's probably not that
bad)

> 
> We just need this to access registers. Dmd is more for desktop 
> and servers. It will never support all the targets gcc can. Could 
> we make this a gdc extension?

Probably, however I'd make it an UDA then in core.gcc, similar to
@attribute. Main drawback here is that we add gdc specific code to the
frontend. But as we need that code for @attribute anyway we could add
some generic code to the frontend to allow backends to use UDAs.
 
> While writing this  it just popped to my mind: if volatile is not 
> good, could we reuse the 'system' word? Then it would be clear 
> that this is for accessing system resources and not for 
> application level.

volatile is still a (deprecated) keyword, so we don't break code by
reintroducing it. However, if we have to make it a gdc only extension I
wouldn't use a keyword with such a prominent name. An @volatile UDA is
much better then.

Of course there are also non-technical issues regarding the name
'volatile'. C/C++ coders will already know what it means, but Java/C#
coder could be confused.




More information about the D.gnu mailing list