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_.

/Paul

P.S.:
I still believe Wouter is in the right especially when it comes to
libraries and HALs
P.P.S:
Could you get around it by declaring the macro "extern C" :)

Den tir. 9. feb. 2021 kl. 20.34 skrev Michael Wong via SG14
<sg14_at_[hidden]>:
>
> 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?
>>
>> Cheers.
>
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14

-- 
• − − •/• −/• • −/• − • •/− • • •/•/− •/− • •/• •/− • • −/•/− •/• − −
•− •/− − •/− −/• −/• •/• − • •/• − • − • −/− • − •/− − −/− −//