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

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.

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

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.

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

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

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.

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

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.

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