# Re: [SG14] Challenging the deprecation of volatile compound statements

From: Paul M. Bendixen <paulbendixen_at_[hidden]>
Date: Mon, 22 Feb 2021 23:28:36 +0100
Thank you Michael
I have put in the D number and formatted the title more or less according
to what you proposed.
I also put in the date of the next mailing for the date. Is this ok or
should I use another date? The date the number was pulled?
If anyone wishes to be added/removed to/from the contributors list just
contact me.

If this is something that concerns you I would like an example as Arthur
mentioned. If you can give an excerpt from a codebase where this would pose
a problem I would love to include it in the paper. Even though I would
think that avr-libc, cmcis and the raspberry pi nano libraries would have a
pretty wide audience, I agree that it would be better to show a wider
impact.

If anyone can come up with a formulation of the "We don't know what we are
getting.If it is possible to get atomicity we would love it, but we know
that is rarely the case" sentence that doesn't sound completely idiotic,
I'll credit whoever can come up with it with coauthor credits. :D

Best
Paul

Den man. 22. feb. 2021 kl. 17.57 skrev Michael Wong <fraggamuffin_at_[hidden]
>:

> The paper number is D2327R0.
> We should improve the headings in the paper as a first feedback.
> Use something like this:
>
> Date:
>
> 2021-02-16
>
> Project:
>
> ISO JTC1/SC22/WG21: Programming Language C++
>
> Audience:
>
> SG14, EWG, WG21
>
> Authors:
>
>
> Contributors:
>
> Emails:
>
>
>
>
> Revision History
>
>
>
> Thanks. Regards
>
>
>
> *More Feedback coming.*
>
> On Fri, Feb 19, 2021 at 8:08 AM Ronan Keryell via SG14 <
> sg14_at_[hidden]> wrote:
>
>> 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
>> > fit.
>> Good example.
>>
>> Since it looks like LaTeX, perhaps you could improve the presentation of
>> the code samples with
>> \usepackage{listings}
>> \lstset{language=C++}
>>
>> \begin{lstlisting}
>> some example...
>> \end{lstlisting}
>>
>> > 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
>> ABI. :-)
>>
>> 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
>> AXI-MM bus to "something", do the computation, make a write access via
>> an AXI-MM bus to the same "something" or "something else".
>>
>> 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.
>>
>> Thanks,
>> --
>> Ronan KERYELL, Xilinx Research Labs / San José, California.
>> _______________________________________________
>> SG14 mailing list
>> SG14_at_[hidden]

>>
>

--
• − − •/• −/• • −/• − • •/− • • •/•/− •/− • •/• •/− • • −/•/− •/• − − •−
•/− − •/− −/• −/• •/• − • •/• − • − • −/− • − •/− − −/− −//