Date: Tue, 9 Feb 2021 14:33:37 -0500
Thanks Wouter, I will put it on the agenda.
Other agenda items I believe are freestanding updates.
On Tue, Feb 9, 2021 at 2:25 PM Wouter van Ooijen <wouter.vanooijen_at_[hidden]>
wrote:
> Hi all
>
> The point I'd like to defend is not about signed/unsigned, but about the
> unfortunate effects of the deprecation (in C++20) of compound assignments
> to volatile variables, like
>
> some_register |= 0x01;
>
> to set the lowest bit of (presumably) a hardware register. When the
> deprecation becomes a removal, and with C++20 when you want to avoid
> deprecation warnings, this has to be written as
>
> some_register = some_register | 0x01;
>
> My worries are twofold. In reverse order of importance:
>
> 1) When some_register is a complex expression, the alternative is
> unnecessary versbose, error-prone, and impedes reading, like (not yet very
> complicated, but shows the point):
>
> uarts[ index ].enable = uarts[ index ].enable | 0x01;
>
> 2) Such an assignment are (currently, and for the foresable future)
> common practice in C code, in examples (often provided by the
> manufacturer), and in header files, potentially also in macros in header
> files. One could argue that the existing practices in the C world are of
> no concern to the C++ world, but in the field of small-embedded C is still
> dominant, and the acceptance of C++ depends on the ability to use existing
> C resources, and on an easy transition for C users to C++.
>
> The counter argument (which is AFAIK the main driver for the deprecation)
> is that in situations with a non-trivial memory hierargy (multiple
> processors, caches, delayed writes) the semantics of a compound assignment
> are not clear. IMO this is not a sufficient argument to deprecate this
> construct in sitations where its semantics are clear.
>
> I instigated a discussion about this on reddit
> <https://www.reddit.com/r/cpp/comments/jswz3z/compound_assignment_to_volatile_must_be/>,
> which contains many of the arguments from both sides, some confusion, and
> occasionally a profound lack of insight into the nature and needs of
> small-embedded programming.
>
> Wouter van Ooijen
>
> 0638150444 - HL15 4.060
>
> ------------------------------
> *From:* Michael Wong <fraggamuffin_at_[hidden]>
> *Sent:* Tuesday, February 9, 2021 6:23 PM
> *To:* Low Latency:Game Dev/Financial/Trading/Simulation/Embedded Devices <
> sg14_at_[hidden]>
> *Cc:* Wouter van Ooijen <wouter.vanooijen_at_[hidden]>
> *Subject:* Agenda for next SG14 meeting
>
> Hi all, our next call tomorrow at 2 ET 19 00 UTC is on Embedded SIG.
>
> Are there any agenda? There is a possible discussion with Wouter on
> signed and unsigned.
> Wouter, would you be interested in discussing that in SG14 tomorrow?
>
> Any other agenda?
>
> Cheers.
>
Other agenda items I believe are freestanding updates.
On Tue, Feb 9, 2021 at 2:25 PM Wouter van Ooijen <wouter.vanooijen_at_[hidden]>
wrote:
> Hi all
>
> The point I'd like to defend is not about signed/unsigned, but about the
> unfortunate effects of the deprecation (in C++20) of compound assignments
> to volatile variables, like
>
> some_register |= 0x01;
>
> to set the lowest bit of (presumably) a hardware register. When the
> deprecation becomes a removal, and with C++20 when you want to avoid
> deprecation warnings, this has to be written as
>
> some_register = some_register | 0x01;
>
> My worries are twofold. In reverse order of importance:
>
> 1) When some_register is a complex expression, the alternative is
> unnecessary versbose, error-prone, and impedes reading, like (not yet very
> complicated, but shows the point):
>
> uarts[ index ].enable = uarts[ index ].enable | 0x01;
>
> 2) Such an assignment are (currently, and for the foresable future)
> common practice in C code, in examples (often provided by the
> manufacturer), and in header files, potentially also in macros in header
> files. One could argue that the existing practices in the C world are of
> no concern to the C++ world, but in the field of small-embedded C is still
> dominant, and the acceptance of C++ depends on the ability to use existing
> C resources, and on an easy transition for C users to C++.
>
> The counter argument (which is AFAIK the main driver for the deprecation)
> is that in situations with a non-trivial memory hierargy (multiple
> processors, caches, delayed writes) the semantics of a compound assignment
> are not clear. IMO this is not a sufficient argument to deprecate this
> construct in sitations where its semantics are clear.
>
> I instigated a discussion about this on reddit
> <https://www.reddit.com/r/cpp/comments/jswz3z/compound_assignment_to_volatile_must_be/>,
> which contains many of the arguments from both sides, some confusion, and
> occasionally a profound lack of insight into the nature and needs of
> small-embedded programming.
>
> Wouter van Ooijen
>
> 0638150444 - HL15 4.060
>
> ------------------------------
> *From:* Michael Wong <fraggamuffin_at_[hidden]>
> *Sent:* Tuesday, February 9, 2021 6:23 PM
> *To:* Low Latency:Game Dev/Financial/Trading/Simulation/Embedded Devices <
> sg14_at_[hidden]>
> *Cc:* Wouter van Ooijen <wouter.vanooijen_at_[hidden]>
> *Subject:* Agenda for next SG14 meeting
>
> Hi all, our next call tomorrow at 2 ET 19 00 UTC is on Embedded SIG.
>
> Are there any agenda? There is a possible discussion with Wouter on
> signed and unsigned.
> Wouter, would you be interested in discussing that in SG14 tomorrow?
>
> Any other agenda?
>
> Cheers.
>
Received on 2021-02-09 13:33:50