[dmd-internals] Regarding deprecation of volatile statements

Alex Rønne Petersen xtzgzorex at gmail.com
Tue Jul 24 15:18:00 PDT 2012


On Wed, Jul 25, 2012 at 12:11 AM, Walter Bright <walter at digitalmars.com> wrote:
>
> On 7/24/2012 2:53 PM, Alex Rønne Petersen wrote:
>>
>> But shared can't replace volatile in kernel space. shared means
>> atomics/memory fences which is not what I want - that would just give me
>> unnecessary overhead. I want the proper, standard C semantics of volatile,
>
>
> C does not have Standard semantics for volatile. It's a giant mess.

Right, it leaves the exact definition of a volatile access to the
compiler. But most relevant C compilers have a fairly sane definition
of this. For example, GCC:
http://gcc.gnu.org/onlinedocs/gcc/Volatiles.html

>
>
>> not the atomicity that people seem to associate with it.
>
>
> Exactly what semantics are you looking for?

GCC's volatile semantics, pretty much. I want to be able to interact
with volatile memory without the compiler thinking it can optimize or
reorder (or whatever) my memory accesses. In other words, tell the
compiler to back off and leave volatile code alone.

>
>
>> Besides, shared isn't even implemented yet - how can it actually be called
>> a valid replacement for volatile at all, at this point?
>
>
> D volatile isn't implemented, either.

It doesn't insert a compiler reordering fence? Martin Nowak seemed to
think that it does, and a lot of old druntime code assumed that it
did...

>
>
>> It seems amazing to me that volatile was deprecated in favor of something
>> that isn't actually implemented (and even more amazing that the error
>> message points to a feature that doesn't do the same thing)... Note that I'm
>> writing actual kernel code here. I need something that actually works or I
>> can't reliably write this code in D...
>
>
> I need to know what you're looking for.
>
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

Regards,
Alex


More information about the dmd-internals mailing list