5 ms·

Correct. More specifically: "Continue supporting the time-honored usage of volatile to load and store variables that are used for shared memory, signal handlin

Correct. More specifically: "Continue supporting the time-honored usage of volatile to load and store variables that are used for shared memory, signal handling, setjmp / longjmp, or other external modifications such as special hardware support." Which is what people want and use volatile for in the vast majority of cases. Removing that functionality would render driver, OS and embedded development a pain.

lisper 7y ago
> Removing that functionality would render driver, OS and embedded development a pain. It would be worse than "a pain", it would actually make it impossible. There is no way other than "volatile" to guarantee that a load or a store to/from a particular memory address happens at a particular time (AFAIK).
- sokoloff 7y ago
  There are non-portable means in most implementations (via asm extensions). Obviously, this is more work and much less convenient than a volatile keyword that gives you the functionality.
  - saagarjha 7y ago
    Doesn’t this need volatile itself since the compiler can’t introspect what the assembly is doing?
    - jacobush 7y ago
      Ehm, no, once you are in assembly, you do whatever you want to do. There is no compiler to mess things up for you. (Although, it's leaving that to you hehe... :-)
      - notimetorelax 7y ago
        I think the compiler still needs to know that the value might be modified from the outside. Otherwise it might optimize the read operation away from the codepath.
        simcop2387 7y ago
        You'd have to do all the reads in ASM too then, but it would still be possible. It'd be terrible ergonomically.
        saagarjha 7y ago
        At that point you’re really not writing C++ at all; you’re writing assembly in a .cpp file.
        m0zg 7y ago
        Nah. You could just define an inline function that'd do volatile read or write of a particular type. You don't have to hit assembly all the time.
        srfilipek 7y ago
        Yes, that is part of creating inline assembly in C or C++ code: http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html
- aardvark179 7y ago
  You should.be able to enforce it with the memory ordering supported since either C++11 or 14 (can’t recall which). It wouldn’t be quite as easy to write down, but might provide stronger guarantees than the volatile semantics.
  - the8472 7y ago
    compilers are still allowed to optimize atomics, e.g. eliminating redundant reads. they are not with volatile, e.g. when you need exactly-once semantics for IO ports.
  - asveikau 7y ago
    I disagree. Guaranteeing that the system behave as if operations have relative ordering is not the same as making sure an operation explicitly happens due to its side effects. They are entirely separate problems. A valid optimization for the former but not for the latter would be to coalesce redundant operations.
  - FartyMcFarter 7y ago
    How would you do something like this [1] using those? [1] https://godbolt.org/z/Aj5bJ8 https://godbolt.org/z/Aj5bJ8
    - amluto 7y ago
      I would argue that this particular example is useless. A volatile variable at file scope can easily be IO memory. A volatile static at function scope? Not so easy.
      - FartyMcFarter 7y ago
        It can be set by a debugger for example. In any case, the scope of the variable was not the point of the question. The behaviour doesn't really change if you make the variable a static file-scoped one.
- kabdib 7y ago
  "volatile" is really insufficient to work with modern memory systems. Is there total ordering, or is it another episode of Bus Master Wild West? Are writes combined? Do reads bypass the write queue, stall, or dig out as-yet-uncommitted values? How sensitive is the hardware to "harmless" extra reads or writes? Let's not forget cache protocols, and what happens to in-flight operations on a fault (sometimes partially executed instructions have to be "finished-up" by fault handlers, whose memory operations can be different in emulation from the actual native instructions). volatile is a weak tool in the face of all the stuff that hardware folks do to achieve performance or cost goals. Most of the platforms I've worked with use abstraction layers that bottom-out in compiler intrinsics or assembly language. I'm deeply suspicious when I see code using bare volatile declarations, as the code is often wrong.
- MaxBarraclough 7y ago
  I don't think that's right. At least according to [0] it's neither sufficient nor even necessary to use volatile for concurrent code. My understanding is that it's really only useful for memory-mapped IO, and to get setjmp/longjmp to play nice. [0] https://stackoverflow.com/a/2485177 https://stackoverflow.com/a/2485177
WalterBright 7y ago
I thought a lot about what to do about volatile when designing D. volatile is deeply embedded in the C++ type system, and is a very semantically expensive feature for what seems like little gain. The solution was to replace volatile with a compiler intrinsic load and an intrinsic store. Those get special treatment in the code generator, and the rest of the type system does not have to carry the burden. https://dlang.org/phobos/core_bitop.html#.volatileLoad https://dlang.org/phobos/core_bitop.html#.volatileLoad
- kibwen 7y ago
  Indeed, exposing volatile read/write as library operations rather than making volatility be an intrinsic property of a variable via the type system is also what Rust settled on.

lisper 7y ago

> Removing that functionality would render driver, OS and embedded development a pain. It would be worse than "a pain", it would actually make it impossible. There is no way other than "volatile" to guarantee that a load or a store to/from a particular memory address happens at a particular time (AFAIK).

sokoloff 7y ago
There are non-portable means in most implementations (via asm extensions). Obviously, this is more work and much less convenient than a volatile keyword that gives you the functionality.
- saagarjha 7y ago
  Doesn’t this need volatile itself since the compiler can’t introspect what the assembly is doing?
  - jacobush 7y ago
    Ehm, no, once you are in assembly, you do whatever you want to do. There is no compiler to mess things up for you. (Although, it's leaving that to you hehe... :-)
    - notimetorelax 7y ago
      I think the compiler still needs to know that the value might be modified from the outside. Otherwise it might optimize the read operation away from the codepath.
      - simcop2387 7y ago
        You'd have to do all the reads in ASM too then, but it would still be possible. It'd be terrible ergonomically.
        saagarjha 7y ago
        At that point you’re really not writing C++ at all; you’re writing assembly in a .cpp file.
        m0zg 7y ago
        Nah. You could just define an inline function that'd do volatile read or write of a particular type. You don't have to hit assembly all the time.
      - srfilipek 7y ago
        Yes, that is part of creating inline assembly in C or C++ code: http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html
aardvark179 7y ago
You should.be able to enforce it with the memory ordering supported since either C++11 or 14 (can’t recall which). It wouldn’t be quite as easy to write down, but might provide stronger guarantees than the volatile semantics.
- the8472 7y ago
  compilers are still allowed to optimize atomics, e.g. eliminating redundant reads. they are not with volatile, e.g. when you need exactly-once semantics for IO ports.
- asveikau 7y ago
  I disagree. Guaranteeing that the system behave as if operations have relative ordering is not the same as making sure an operation explicitly happens due to its side effects. They are entirely separate problems. A valid optimization for the former but not for the latter would be to coalesce redundant operations.
- FartyMcFarter 7y ago
  How would you do something like this [1] using those? [1] https://godbolt.org/z/Aj5bJ8 https://godbolt.org/z/Aj5bJ8
  - amluto 7y ago
    I would argue that this particular example is useless. A volatile variable at file scope can easily be IO memory. A volatile static at function scope? Not so easy.
    - FartyMcFarter 7y ago
      It can be set by a debugger for example. In any case, the scope of the variable was not the point of the question. The behaviour doesn't really change if you make the variable a static file-scoped one.
kabdib 7y ago
"volatile" is really insufficient to work with modern memory systems. Is there total ordering, or is it another episode of Bus Master Wild West? Are writes combined? Do reads bypass the write queue, stall, or dig out as-yet-uncommitted values? How sensitive is the hardware to "harmless" extra reads or writes? Let's not forget cache protocols, and what happens to in-flight operations on a fault (sometimes partially executed instructions have to be "finished-up" by fault handlers, whose memory operations can be different in emulation from the actual native instructions). volatile is a weak tool in the face of all the stuff that hardware folks do to achieve performance or cost goals. Most of the platforms I've worked with use abstraction layers that bottom-out in compiler intrinsics or assembly language. I'm deeply suspicious when I see code using bare volatile declarations, as the code is often wrong.
MaxBarraclough 7y ago
I don't think that's right. At least according to [0] it's neither sufficient nor even necessary to use volatile for concurrent code. My understanding is that it's really only useful for memory-mapped IO, and to get setjmp/longjmp to play nice. [0] https://stackoverflow.com/a/2485177 https://stackoverflow.com/a/2485177

WalterBright 7y ago

I thought a lot about what to do about volatile when designing D. volatile is deeply embedded in the C++ type system, and is a very semantically expensive feature for what seems like little gain. The solution was to replace volatile with a compiler intrinsic load and an intrinsic store. Those get special treatment in the code generator, and the rest of the type system does not have to carry the burden. https://dlang.org/phobos/core_bitop.html#.volatileLoad https://dlang.org/phobos/core_bitop.html#.volatileLoad

kibwen 7y ago
Indeed, exposing volatile read/write as library operations rather than making volatility be an intrinsic property of a variable via the type system is also what Rust settled on.