Breaking volatile, breaking type punning, refusing to define consistent
order of evaluation, creating new forms of undefined behavior, and probably
a bunch more things that I'm forgetting are all ways in which the C and C++
languages have been captured by optimizationists to the detriment of
programmers.

There is no conceptual difficulty about volatile except for the people who
are trying to denigrate it so as to not have to implement it correctly. A
volatile variable should be given a storage location, memory or register.
It cannot be assumed to maintain a value across reads or writes. As the
abstract machine processes side effects, it may not reorder them, including
reads or writes to the volatile variables. For conventional compilation,
those reads and writes are simply assembly language instructions reading or
writing the assigned storage location, the same as for any other variable.

While some compilers have modes that treat volatile access as atomic, that
has never been required.

On Sun, Jun 12, 2022, 5:24 AM Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hi Jason,
>
>
>
> today not even assembler is executed as written, let's just name two
> features: instruction reordering, speculative execution.
>
>
>
> But for programming we still assume that
>
> - the visible effects of our program are the same as written. For it
> there is the abstract machine in C++,
>
> - the performance of the program is not totally worse than written. We
> (at least) expect the optimizers and the execution hardware to not
> pessimize the code into another O notation category.
>
>
>
> Everything else to fine-control, what the system does, is difficult to
> achieve even on specified platforms with a specific compiler.
>
>
>
> The volatile keyword was (and is) always a clunky means. Non
> volatile-accessing instructions could be moved before and after
> volatile-accessing ones. Memory barriers for other CPU cores to communicate
> with other threads running there had to (depending on the platform and the
> compiler) be inserted in addition to declaring variables as volatile. You
> could not distinguish different "volatile streams" for the ordering. Even
> the compilers, which supported memory fences, did not distinguish between
> read and write barriers for volatile.
>
>
>
> For getting all this right, you had to be a specialist and careful. But as
> specialist you wanted to have a good tool with possibility for finegrained
> control.
>
>
>
>
>
> If the aim is to have certain points in the program, where no instruction
> ordering may be made from before or after, e.g. after every line or at
> certain checkpoints,
>
> if the aim is to be able to read the contents of certain variables at
> certain locations in the program, because they are stored in a specific
> memory region, then this can be achieved through the compiller, optimizer,
> linker, debugger.
>
>
>
> Perhaps volatile for those use cases could be/have been saved by defining
> those use cases, listing the expected result and whether volatile is a good
> method/expression of the intention to do it.
>
>
>
> Best,
>
> Sebastian
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>