Subject: Re: Agenda for next SG14 meeting
From: Paul M. Bendixen (paulbendixen_at_[hidden])
Date: 2021-02-09 16:52:29
Just to come clean after last month's discussion regarding the deprecation.
The optimization I thought was there on certain architectures was a
misconception as it will only work on registers in that architecture,
so to clarify no I have not found any architectures where the `|=` is
actually a singular bit flip on the _volatile_ _variable_.
I still believe Wouter is in the right especially when it comes to
libraries and HALs
Could you get around it by declaring the macro "extern C" :)
Den tir. 9. feb. 2021 kl. 20.34 skrev Michael Wong via SG14
> 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, 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?
> SG14 mailing list
-- â¢ â â â¢/â¢ â/â¢ â¢ â/â¢ â â¢ â¢/â â¢ â¢ â¢/â¢/â â¢/â â¢ â¢/â¢ â¢/â â¢ â¢ â/â¢/â â¢/â¢ â â â¢â â¢/â â â¢/â â/â¢ â/â¢ â¢/â¢ â â¢ â¢/â¢ â â¢ â â¢ â/â â¢ â â¢/â â â/â â//
SG14 list run by firstname.lastname@example.org
Older Archives on Google Groups