www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP20: Volatile read/write intrinsics

reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP20

This supersedes DIP17.

The primary reason to use intrinsics instead of something built into the 
language is that the latter is too complex for current (and likely also 
future) compiler implementations.

Destroy!

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Oct 10 2012
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 10/10/2012 20:31, Alex Rønne Petersen a écrit :

 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP20

 This supersedes DIP17.

 The primary reason to use intrinsics instead of something built into the
 language is that the latter is too complex for current (and likely also
 future) compiler implementations.

 Destroy!


We discussed it quite a lot already, but I still think volatile must be 
a qualifier of the memory, and not of the statement.

In other terms, volatile should alter the way memory is read and 
written, on every access to that memory. Not on a specific statement.
Oct 10 2012
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
On 10-10-2012 20:45, deadalnix wrote:

 Le 10/10/2012 20:31, Alex Rønne Petersen a écrit :

 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP20

 This supersedes DIP17.

 The primary reason to use intrinsics instead of something built into the
 language is that the latter is too complex for current (and likely also
 future) compiler implementations.

 Destroy!


 We discussed it quite a lot already, but I still think volatile must be
 a qualifier of the memory, and not of the statement.

 In other terms, volatile should alter the way memory is read and
 written, on every access to that memory. Not on a specific statement.


I have no problem with counter-proposals so long as we get the ball 
rolling. Can you write up a counter-DIP with your idea so we can get the 
various approaches clarified and figure out which one is better?

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Oct 10 2012
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 10 October 2012 at 19:09:34 UTC, deadalnix wrote:

 We discussed it quite a lot already, but I still think volatile 
 must be a qualifier of the memory, and not of the statement.


I barely know anything about this, but couldn't that be done as a 
library type? Something like a smart pointer.

This does bring me to a question though. What if you had:

void foo() {
    volatile_read();
}

foo();
bar();
foo();

Is the call to foo allowed to be reordered? I imagine it has to 
mark the whole call chain upwards as internally volatile too.
Oct 10 2012
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 10-10-2012 20:57, Adam D. Ruppe wrote:

 On Wednesday, 10 October 2012 at 19:09:34 UTC, deadalnix wrote:

 We discussed it quite a lot already, but I still think volatile must
 be a qualifier of the memory, and not of the statement.


 I barely know anything about this, but couldn't that be done as a
 library type? Something like a smart pointer.

 This does bring me to a question though. What if you had:

 void foo() {
     volatile_read();
 }

 foo();
 bar();
 foo();

 Is the call to foo allowed to be reordered? I imagine it has to mark the
 whole call chain upwards as internally volatile too.


Good observation!

So here's the thing: The compiler is only allowed to reorder calls to 
functions where it knows the source of the function and can thus figure 
out what it does.

So, for functions that it does not have the source code for, it must 
*never* reorder, *ever*. This is one reason volatileLoad and 
volatileWrite should not be pure: They directly affect code that 
surrounds calls to them.

For functions where the compiler does have the source code, it can 
trivially figure out if reordering is OK, based on whether there are any 
calls to volatileLoad and volatileStore somewhere down the call graph. 
It gets even easier to do these checks when inlining is involved (since 
then the volatileLoad/volatileStore calls are readily visible in context).

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Oct 10 2012
prev sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Wednesday, 10 October 2012 at 19:21:24 UTC, Adam D. Ruppe 
wrote:

 This does bring me to a question though. What if you had:

 void foo() {
    volatile_read();
 }

 foo();
 bar();
 foo();

 Is the call to foo allowed to be reordered? I imagine it has to 
 mark the whole call chain upwards as internally volatile too.


Function calls are never allowed to be reordered. In D, there 
might be some exceptions regarding strong purity, but the 
volatile instructions just couldn't/wouldn't be pure.

David
Oct 10 2012
prev sibling parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 10/10/2012 02:31 PM, Alex Rønne Petersen wrote:

 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP20

 This supersedes DIP17.

 The primary reason to use intrinsics instead of something built into the
 language is that the latter is too complex for current (and likely also
 future) compiler implementations.

 Destroy!


Since this can affect semantics but might not always be available, is 
there any chance you could add a feature detection intrinsic for this? 
Maybe a compile-time "haveVolatileOps" identifier would work.

Volatility might be absent if:
- The backend target can't forward the volatility guarantees, ex: a D 
compiler that emits JavaScript code.
- The compiler has not implemented volatile operations yet.
Oct 10 2012
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
On 11-10-2012 07:14, Chad J wrote:

 On 10/10/2012 02:31 PM, Alex Rønne Petersen wrote:

 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP20

 This supersedes DIP17.

 The primary reason to use intrinsics instead of something built into the
 language is that the latter is too complex for current (and likely also
 future) compiler implementations.

 Destroy!


 Since this can affect semantics but might not always be available, is
 there any chance you could add a feature detection intrinsic for this?
 Maybe a compile-time "haveVolatileOps" identifier would work.

 Volatility might be absent if:
 - The backend target can't forward the volatility guarantees, ex: a D
 compiler that emits JavaScript code.
 - The compiler has not implemented volatile operations yet.


I suppose a simple D_Volatile version identifier will do, like we have 
D_SIMD for core.simd.__simd.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Oct 10 2012
parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 10/11/2012 01:40 AM, Alex Rønne Petersen wrote:

 I suppose a simple D_Volatile version identifier will do, like we have
 D_SIMD for core.simd.__simd.


Cool.
Oct 11 2012
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
On 11-10-2012 14:42, Chad J wrote:

 On 10/11/2012 01:40 AM, Alex Rønne Petersen wrote:

 I suppose a simple D_Volatile version identifier will do, like we have
 D_SIMD for core.simd.__simd.


 Cool.


OK, updated.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Oct 11 2012
parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 10/11/2012 10:35 AM, Alex Rønne Petersen wrote:

 On 11-10-2012 14:42, Chad J wrote:

 On 10/11/2012 01:40 AM, Alex Rønne Petersen wrote:

 I suppose a simple D_Volatile version identifier will do, like we have
 D_SIMD for core.simd.__simd.


 Cool.


 OK, updated.


I do have a critique for your description:


 Compilers that support these intrinsics must define the D_Volatile version
identifier. Compilers that do not may support them, but programmers should not
rely on it.


I read this as meaning:
Compilers that support volatile intrinsics must define D_Volatile.
Compilers can support volatile intrinsics without defining D_Volatile.

And I see a contradiction ;)
Oct 11 2012
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
On 12-10-2012 04:05, Chad J wrote:

 On 10/11/2012 10:35 AM, Alex Rønne Petersen wrote:

 On 11-10-2012 14:42, Chad J wrote:

 On 10/11/2012 01:40 AM, Alex Rønne Petersen wrote:

 I suppose a simple D_Volatile version identifier will do, like we have
 D_SIMD for core.simd.__simd.


 Cool.


 OK, updated.


 I do have a critique for your description:


 Compilers that support these intrinsics must define the D_Volatile
 version identifier. Compilers that do not may support them, but
 programmers should not rely on it.


 I read this as meaning:
 Compilers that support volatile intrinsics must define D_Volatile.
 Compilers can support volatile intrinsics without defining D_Volatile.

 And I see a contradiction ;)


Oops. It should be clearer now.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Oct 11 2012
parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 10/11/2012 10:18 PM, Alex Rønne Petersen wrote:

 Oops. It should be clearer now.


It is!
Oct 11 2012