Subject: Re: Challenging the deprecation of volatile compound statements
From: Ronan Keryell (rkeryell_at_[hidden])
Date: 2021-02-18 21:20:36
On 2/17/21 5:36 PM, Paul M. Bendixen via SG14 wrote:
> So I've tried to incorporate the feedback given.
> I know I can have a tendency to ramble a bit in text so if the
> proposal is still not clear enough, please let me know.
That looks good.
> I've added a single example of usage in a library "from the wild", if
> further examples are required, I would like to know were they might
Since it looks like LaTeX, perhaps you could improve the presentation of
the code samples with
> I haven't added the "what do we expect from atomicity of compound
> expressions" section, as I frankly do no know what to expect other
> than it not breaking the hal that is often times _more_ important than
> the standard library.
I guess that in this area at least we do not care about breaking the
But perhaps a non normative note about no expectation of atomicity or
whatever could be useful.
> I'm still looking for any feedback this group may have.
I asked internally and the only feedback was "volatile is the problem,
not only this detail"... :-)
Since it is another discussion, I think that as volatile is in the
language and the compatibility with C is a selling point for C++, we
should keep the same behavior, even if it is blurry at the first place.
Anyone using volatile should be aware there are dragons here and be
aware of some hardware details and compiler implementation details while
not expecting too much.
In my FPGA company "x &= y" means do "x = (x & y)" with x only evaluated
once, and with x being volatile, first make a read access to x via an
AXI-MM bus to "something", do the computation, make a write access via
an AXI-MM bus to the same "something" or "something else".
There is no assumption about a load-modify-store instruction because,
well, there is no... instruction, just logic gates... ;-)
At the end there are only logic gates executing something equivalent to
the C++ program.
What will respond to reading x or writing x on some bus will depend on
some bigger picture depending for example on some RTL code
(Verilog/VHDL) outside of the scope of the C++ program.
Ronan KERYELL, Xilinx Research Labs / San JosÃ©, California.
SG14 list run by email@example.com
Older Archives on Google Groups