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.

Vishal Oza

On Mon, Feb 22, 2021 at 4:29 PM Paul M. Bendixen via SG14 <
sg14_at_[hidden]> wrote:

> 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:
>>
>>
>> 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
>>> \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
>>> 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.
>>>
>>> Thanks,
>>> --
>>> Ronan KERYELL, Xilinx Research Labs / San José, California.
>>> _______________________________________________
>>> SG14 mailing list
>>> SG14_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>>>
>>
>
> --
> • − − •/• −/• • −/• − • •/− • • •/•/− •/− • •/• •/− • • −/•/− •/• − − •−
> •/− − •/− −/• −/• •/• − • •/• − • − • −/− • − •/− − −/− −//
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>