On Tue, Feb 9, 2021 at 5:55 PM Michael Wong <fraggamuffin_at_[hidden]> wrote:

> Topic: SG14 Low Latency Monthly
>
> This meeting is focused on Embedded. It will be chaired by John
> MacFarlane.
>
> Hi,
>
> Michael Wong is inviting you to a scheduled Zoom meeting.
>
> Topic: SG14 monthly Dec 2020-Feb 2021
> Time: Jan 13, 2020 02:00 PM Eastern Time (US and Canada)
> Every month on the Second Wed, until Feb 10, 2021, 3 occurrence(s)
> Dec 9, 2020 02:00 PM
> Jan 13, 2021 02:00 PM
> Feb 10, 2021 02:00 PM
> Please download and import the following iCalendar (.ics) files to your
> calendar system.
> Monthly:
>
> https://iso.zoom.us/meeting/tJcscuigqD8pHNESxi1bJ9ClURVqr_ZAvmv1/ics?icsToken=98tyKuCrrz4rEtKRsx-CRowqBY_4d_zwpilego14rwfsUiJ5OyD6A9B0I6BAKvnG
>
> Join from PC, Mac, Linux, iOS or Android:
> https://iso.zoom.us/j/93151864365?pwd=aDhOcDNWd2NWdTJuT1loeXpKbTcydz09
> Password: 789626
>
> Or iPhone one-tap :
> US: +12532158782,,93151864365# or +13017158592,,93151864365#
> Or Telephone:
> Dial(for higher quality, dial a number based on your current location):
> US: +1 253 215 8782 or +1 301 715 8592 or +1 312 626 6799 or +1
> 346 248 7799 or +1 408 638 0968 or +1 646 876 9923 or +1 669 900 6833
> or 877 853 5247 (Toll Free)
> Meeting ID: 931 5186 4365
> Password: 789626
> International numbers available: https://iso.zoom.us/u/abRrVivZoD
>
> Or Skype for Business (Lync):
> https://iso.zoom.us/skype/93151864365
>
> Agenda:
>
> 1. Opening and introduction
>
> ISO Code of Conduct
> <
>
> https://isotc.iso.org/livelink/livelink?func=ll&objId=20882226&objAction=Open&nexturl=%2Flivelink%2Flivelink%3Ffunc%3Dll%26objId%3D20158641%26objAction%3Dbrowse%26viewType%3D1
> >
>
> ISO patent policy.
>
> https://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770791/Common_Policy.htm?nodeid=6344764&vernum=-2
>
> WG21 Code of COnduct:
>
>
> https://isocpp.org/std/standing-documents/sd-4-wg21-practices-and-procedures
>
> 1.1 Roll call of participants
>
> 1.2 Adopt agenda
>
> 1.3 Approve minutes from previous meeting, and approve publishing
> previously approved minutes to ISOCPP.org
>
> 1.4 Action items from previous meetings
>
> 2. Main issues (125 min)
>
> 2.1 General logistics
>
> Future meeting plans
>
> Apr 14, 2020 02:00 PM ET/1800 UTC: Finance focus on low latency
> May 12, 2021 02:00 PM ET/1800UTC: Games
> June 9, 2021 02:00 PM ET/1800 UTC: Embedded
>
> 2.2 Paper reviews
>
> Compound assignment
>

C++ 20 deprecates compound assignment to volatile
memory map devices is common and uses this and create larger rift between
C and C++ world
harder to get c project to just recompile in C++, now you have to replace
compound assignment
header files also contain macros like this
its only deprecation but it is an intent to remove
difficult to pinpoint semantics problems, one read, one writeback

code that he does not control, and vendor headers in macros is the problme
the semantics of solution in paeper are the same

 can we get C to deprecate this ?

most of volatile is unspecified what it means
we do a read of register and or it with something
reading a device register dont give you any sensible value back
for some HW it might work or not work
if deprecation is not good, and attach proper semantics, then write a paper


main way for a bit set

impedance mismatch of the fundamental unit of byte
hard to read |= in a data race
the scenario can exasperate it during times when no memory order

C/C++ liasion group to deprecate this in C
fix with replacing compound with non-compound, this just impose a style
from C++ without benefit, so may not want to deprecate compound ops

this is a well known idiom on some embedded HW
fix in embedded world with a style guide with MISRA
changes a lot of old code prevents moving to C++ in embedded, so recommend
style guide to fix this

might not be funneling people down a path at all, but using operation
provided to them by HW vendor
here is a piece of code that works in C and now they want me to try C++
; now this make people move back to C

a|=b
a=a|b

volatile atomics that can give slightly better semantics in some use case,
but it is implementation specific

so specific semantics=volatile is used when using HW or signal, these need
specific instructions
compiler might only honor the size, and not CAS


could this be a compiler warning? could be lots of false positive, what
used to be there is fine

looks annoying to have this deprecation, will be no go for C++ in our tools
what are instructions emitted by volatile access, we sue C++ on CPU side
and in FPGA, and replace C++ program with equivalent, and is volatile is
emitting memory access
need to keep this as it is simpler for end user

support the other which is we see so many time in our code, assume that
when you write compound that you are doing RMW , was always a bug
so obviously misleading and hard t keep safeguard

what would be good outcome here, easiest is to undeprecate, but what do you
say? you dont say what they do and it is implementiaton specified, valid
syntax, but you dont know what it means
std should define semantics of compound operation but that might make it
worst

counter argument is it also has no defined semantcis in C either, C does
not warn you but C++ does, so we make it appear to have different behavior
when there is no difference


define volatile? yes there is another paper that is trying to define
meaning of volatile load and store, and atomic volatile

ask C/C++ liasion about deprecatign for C23, if NO then we know we have
input

JF to email aaron

hard to get a good feelign about each other's interest; see no consensus
from the discussion, mixed on both sides






















Freestanding?
>
P2268R0 is a roadmap

P2013 Language optional on EWG EP
P1642 Easy utilities in LEWG EP

Low cost deterministic exception for next Embedded call

P0829 is Std lib omnibus

beyond are still being discussed and needs implementation experience

Asking for volunteers

This is a future directions paper on embedded which is more then most
desktops

PB has a fork of this paper




> 2.2.1 any other proposal for reviews?
>
> SG14/SG19 features/issues/defects:
>
>
> https://docs.google.com/spreadsheets/d/1JnUJBO72QVURttkKr7gn0_WjP--P0vAne8JBfzbRiy0/edit#gid=0
>
> 2.3 Domain-specific discussions
>
> 2.3.1 SIG chairs
>
> - Embedded Programming chairs: Ben Craig, Wouter van Ooijen and Odin
> Holmes, John McFarlane
>
> - Financial/Trading chairs: Staffan Tjernström, Carl Cooke, Neal
> Horlock,
> Mateusz Pusz, Clay Trychta,
> - Games chairs: Rene Riviera, Guy Davidson and Paul Hampson
> - Linear Algebra chairs: Bob Steagall, Mark Hoemmen, Guy Davidson
>
> 2.4 Other Papers and proposals
>
> 2.5 Future F2F meetings:
>
> 2.6 future C++ Standard meetings:
> https://isocpp.org/std/meetings-and-participation/upcoming-meetings
>
> -
>
> 3. Any other business
> Reflector
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
> As well as look through papers marked "SG14" in recent standards committee
> paper mailings:
> http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/
> http://open-std.org/jtc1/sc22/wg21/docs/papers/2016/
>
> Code and proposal Staging area
> https://github.com/WG21-SG14/SG14
> 4. Review
>
> 4.1 Review and approve resolutions and issues [e.g., changes to SG's
> working draft]
>
> 4.2 Review action items (5 min)
>
> 5. Closing process
>
> 5.1 Establish next agenda
>
> 5.2 Future meeting
>
> April 14, 2021 02:00 PM Eastern Time ( 1800 UTC ): Finance
>
>
> Kind Rgds
>