Subject: Re: Challenging the deprecation of volatile compound statements
From: Vishal Oza (vickoza_at_[hidden])
Date: 2021-02-22 16:51:27
I like this paper but I think that this might need some more examples
on how this works for clarification. Also look at code in the financial and
gaming industry for latency as well to make a stronger case if possible.
On Mon, Feb 22, 2021 at 4:29 PM Paul M. Bendixen via SG14 <
> 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
> 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
> Den man. 22. feb. 2021 kl. 17.57 skrev Michael Wong <
>> The paper number is D2327R0.
>> We should improve the headings in the paper as a first feedback.
>> Use something like this:
>> ISO JTC1/SC22/WG21: Programming Language C++
>> SG14, EWG, WG21
>> Reply to:
>> 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
>>> some example...
>>> > 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
>>> 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 mailing list
> â¢ â â â¢/â¢ â/â¢ â¢ â/â¢ â â¢ â¢/â â¢ â¢ â¢/â¢/â â¢/â â¢ â¢/â¢ â¢/â â¢ â¢ â/â¢/â â¢/â¢ â â â¢â
> â¢/â â â¢/â â/â¢ â/â¢ â¢/â¢ â â¢ â¢/â¢ â â¢ â â¢ â/â â¢ â â¢/â â â/â â//
> SG14 mailing list
SG14 list run by email@example.com
Older Archives on Google Groups