Date: Mon, 22 Feb 2021 11:57:39 -0500
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
>
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
>
Received on 2021-02-22 10:57:56