Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #27080 > unrolled thread
| Started by | "hogwarts" <122707@EmbeddedRelated> |
|---|---|
| First post | 2017-07-27 07:35 -0500 |
| Last post | 2017-08-21 11:28 +0200 |
| Articles | 20 on this page of 84 — 20 participants |
Back to article view | Back to comp.arch.embedded
Engineering degree for embedded systems "hogwarts" <122707@EmbeddedRelated> - 2017-07-27 07:35 -0500
Re: Engineering degree for embedded systems Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2017-07-27 15:25 +0200
Re: Engineering degree for embedded systems Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-07-30 12:05 -0400
Re: Engineering degree for embedded systems Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-07-30 19:05 +0100
Re: Engineering degree for embedded systems Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-08-01 08:55 -0400
Re: Engineering degree for embedded systems Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-08-01 14:23 +0100
Re: Engineering degree for embedded systems Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-08-03 11:03 -0400
Re: Engineering degree for embedded systems Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-08-06 10:35 +0100
Re: Engineering degree for embedded systems John Devereux <john@devereux.me.uk> - 2017-08-06 14:40 +0100
Re: Engineering degree for embedded systems rickman <gnuarm@gmail.com> - 2017-08-06 12:51 -0400
Re: Engineering degree for embedded systems Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-08-06 20:13 +0100
Re: Engineering degree for embedded systems rickman <gnuarm@gmail.com> - 2017-08-06 19:21 -0400
Re: Engineering degree for embedded systems Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-08-07 12:40 -0400
Re: Engineering degree for embedded systems rickman <gnuarm@gmail.com> - 2017-08-07 15:18 -0400
Re: Engineering degree for embedded systems Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-08-07 15:27 -0400
Re: Engineering degree for embedded systems rickman <gnuarm@gmail.com> - 2017-08-07 16:47 -0400
Re: Engineering degree for embedded systems Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-08-07 17:30 -0400
Re: Engineering degree for embedded systems rickman <gnuarm@gmail.com> - 2017-08-07 18:35 -0400
Re: Engineering degree for embedded systems Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-08-07 18:56 -0400
Re: Engineering degree for embedded systems rickman <gnuarm@gmail.com> - 2017-08-07 19:02 -0400
Re: Engineering degree for embedded systems Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-08-07 19:08 -0400
Re: Engineering degree for embedded systems Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2017-08-08 01:30 +0200
Re: Engineering degree for embedded systems Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-08-07 19:32 -0400
Re: Engineering degree for embedded systems rickman <gnuarm@gmail.com> - 2017-08-07 19:53 -0400
Re: Engineering degree for embedded systems Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-08-07 20:02 -0400
Re: Engineering degree for embedded systems stephen@mpeforth.com (Stephen Pelc) - 2017-08-07 23:49 +0000
Re: Engineering degree for embedded systems Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-08-07 20:07 -0400
Re: Engineering degree for embedded systems Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-08-08 08:00 +0100
Re: Engineering degree for embedded systems George Neuner <gneuner2@comcast.net> - 2017-08-07 01:21 -0400
Re: Engineering degree for embedded systems upsidedown@downunder.com - 2017-08-06 17:15 +0300
Re: Engineering degree for embedded systems Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-08-06 20:21 +0100
Re: Engineering degree for embedded systems upsidedown@downunder.com - 2017-08-07 10:35 +0300
Re: Engineering degree for embedded systems David Brown <david.brown@hesbynett.no> - 2017-08-07 12:54 +0200
Re: Engineering degree for embedded systems David Brown <david.brown@hesbynett.no> - 2017-08-07 12:34 +0200
Re: Engineering degree for embedded systems Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-08-07 12:43 -0400
Re: Engineering degree for embedded systems rickman <gnuarm@gmail.com> - 2017-08-06 12:50 -0400
Re: Engineering degree for embedded systems Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-08-07 12:36 -0400
Re: Engineering degree for embedded systems Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-08-07 18:40 +0100
Re: Engineering degree for embedded systems David Brown <david.brown@hesbynett.no> - 2017-08-08 10:23 +0200
Re: Engineering degree for embedded systems Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-08-08 09:46 +0100
Re: Engineering degree for embedded systems David Brown <david.brown@hesbynett.no> - 2017-08-08 11:26 +0200
Re: Engineering degree for embedded systems Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-08-08 11:09 +0100
Re: Engineering degree for embedded systems David Brown <david.brown@hesbynett.no> - 2017-08-08 12:56 +0200
Re: Engineering degree for embedded systems Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-08-08 15:56 +0100
Re: Engineering degree for embedded systems David Brown <david.brown@hesbynett.no> - 2017-08-08 17:11 +0200
Re: Engineering degree for embedded systems Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-08-08 16:33 +0100
Re: Engineering degree for embedded systems upsidedown@downunder.com - 2017-08-08 21:07 +0300
Re: Engineering degree for embedded systems David Brown <david.brown@hesbynett.no> - 2017-08-09 10:03 +0200
Re: Engineering degree for embedded systems upsidedown@downunder.com - 2017-08-10 14:30 +0300
Re: Engineering degree for embedded systems David Brown <david.brown@hesbynett.no> - 2017-08-10 15:11 +0200
Re: Engineering degree for embedded systems Walter Banks <walter@bytecraft.com> - 2017-08-16 18:39 -0400
Re: Engineering degree for embedded systems David Brown <david.brown@hesbynett.no> - 2017-08-17 09:37 +0200
Re: Engineering degree for embedded systems Walter Banks <walter@bytecraft.com> - 2017-08-17 08:24 -0400
Re: Engineering degree for embedded systems David Brown <david.brown@hesbynett.no> - 2017-08-17 16:06 +0200
Re: Engineering degree for embedded systems Walter Banks <walter@bytecraft.com> - 2017-08-17 12:15 -0400
Re: Engineering degree for embedded systems David Brown <david.brown@hesbynett.no> - 2017-08-18 14:45 +0200
Re: Engineering degree for embedded systems Walter Banks <walter@bytecraft.com> - 2017-08-25 09:51 -0400
Re: Engineering degree for embedded systems Les Cargill <lcargill99@comcast.com> - 2017-08-01 20:46 -0500
Re: Engineering degree for embedded systems David Brown <david.brown@hesbynett.no> - 2017-08-02 09:30 +0200
Re: Engineering degree for embedded systems Les Cargill <lcargill99@comcast.com> - 2017-08-05 15:11 -0500
Re: Engineering degree for embedded systems Paul Rubin <no.email@nospam.invalid> - 2017-08-08 00:22 -0700
Re: Engineering degree for embedded systems Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-08-08 08:36 +0100
Re: Engineering degree for embedded systems David Brown <david.brown@hesbynett.no> - 2017-08-08 12:37 +0200
Re: Engineering degree for embedded systems "tim..." <tims_new_home@yahoo.com> - 2017-07-27 17:46 +0100
Re: Engineering degree for embedded systems Grant Edwards <invalid@invalid.invalid> - 2017-07-27 16:54 +0000
Re: Engineering degree for embedded systems "tim..." <tims_new_home@yahoo.com> - 2017-07-27 19:57 +0100
Re: Engineering degree for embedded systems Frank Miles <fpm@u.washington.edu> - 2017-07-27 16:58 +0000
Re: Engineering degree for embedded systems Theo Markettos <theom+news@chiark.greenend.org.uk> - 2017-07-28 00:43 +0100
Re: Engineering degree for embedded systems jim.brakefield@ieee.org - 2017-07-30 15:26 -0700
Re: Engineering degree for embedded systems Chris <xxx.syseng.yyy@gfsys.co.uk> - 2017-07-27 23:45 +0000
Re: Engineering degree for embedded systems Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2017-08-03 19:50 +0200
Re: Engineering degree for embedded systems Les Cargill <lcargill99@comcast.com> - 2017-08-05 15:20 -0500
Re: Engineering degree for embedded systems upsidedown@downunder.com - 2017-08-06 09:17 +0300
Re: Engineering degree for embedded systems "tim..." <tims_new_home@yahoo.com> - 2017-08-06 10:12 +0100
Re: Engineering degree for embedded systems upsidedown@downunder.com - 2017-08-06 13:19 +0300
Re: Engineering degree for embedded systems Les Cargill <lcargill99@comcast.com> - 2017-08-06 09:59 -0500
Re: Engineering degree for embedded systems "tim..." <tims_new_home@yahoo.com> - 2017-08-06 18:06 +0100
Re: Engineering degree for embedded systems rickman <gnuarm@gmail.com> - 2017-08-06 21:31 -0400
Re: Engineering degree for embedded systems "tim..." <tims_new_home@yahoo.com> - 2017-08-07 09:32 +0100
Re: Engineering degree for embedded systems Les Cargill <lcargill99@comcast.com> - 2017-08-06 09:53 -0500
Re: Engineering degree for embedded systems upsidedown@downunder.com - 2017-08-07 10:59 +0300
Re: Engineering degree for embedded systems Les Cargill <lcargill99@comcast.com> - 2017-08-07 20:09 -0500
Re: Engineering degree for embedded systems upsidedown@downunder.com - 2017-08-08 21:31 +0300
Re: Engineering degree for embedded systems Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2017-08-21 11:28 +0200
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-08-08 11:26 +0200 |
| Message-ID | <ombvsd$ui3$1@dont-email.me> |
| In reply to | #27154 |
On 08/08/17 10:46, Tom Gardner wrote: > On 08/08/17 09:23, David Brown wrote: >> On 07/08/17 19:40, Tom Gardner wrote: >>> On 07/08/17 17:36, Phil Hobbs wrote: >> >>>> My stuff is all pthreads, because std::thread didn't exist at the time, >>>> but it does now, so presumably Boehm's input has been taken into >>>> account. >>> >>> I'm told C/C++12 /finally/ has a memory model, so perhaps >>> that will (a few decades too late) ameliorate the problem. >>> We'll see, but I'm not holding my breath. >> >> You mean C11/C++11 ? > > Oh.... picky picky picky :) Well, if you decide to look this up on google, it should save you a bit of false starts. > >> Whether people will use them >> appropriately or not, is another matter. > > My experience is that they won't. That's for two reasons: > 1) not really understanding threading/synchronisation > issues, because they are only touched upon in schools. > Obviously that problem is language agnostic. Agreed. This stuff is hard to understand if you want to get correct /and/ optimally efficient. > 2) any subtleties in the C/C++ specification and > implementation "suboptimalities"; I expect those will > exist :( I have read through the specs and implementation information - quite a bit of work has gone into making it possible to write safe code that is more efficient than was previously possible (or at least practical). It is not so relevant for small embedded systems, where you generally have a single core and little in the way of write buffers - there is not much, if anything, to be gained by replacing blunt full memory barriers with tuned load-acquire and store-release operations. But for bigger systems with multiple cpus, a full barrier can cost hundreds of cycles. There is one "suboptimality" - the "consume" memory order. It's a bit weird, in that it is mainly relevant to the Alpha architecture, whose memory model is so weak that in "x = *p;" it can fetch the contents of *p before seeing the latest update of p. Because the C11 and C++11 specs are not clear enough on "consume", all implementations (AFAIK) bump this up to the stronger "acquire", which may be slightly slower on some architectures. > > Plus, of course, as you note below... > >> In the embedded world there >> seems to be a fair proportion of people that still think C89 is a fine >> standard to use. > > ... > >> So yes, C11/C++11 solves the problem in a standardised way - but it will >> certainly take time before updated tools are in common use, and before >> people make use of the new features. > > ISTR that in the early-mid naughties there was a triumphant > announcement of the first /complete/ C or C++ compiler - 5 > or 6 years after the standard was published! Of course many > compilers had implemented a usable subset before that. > Things have changed a good deal since then. The major C++ compilers (gcc, clang, MSVC) have complete C++11 and C++14 support, with gcc and clang basically complete on the C++17 final drafts. gcc has "concepts", slated for C++20 pretty much "as is", and MSVC and clang have prototype "modules" which are also expected for C++20 (probably based on MSVC's slightly better version). <http://en.cppreference.com/w/cpp/compiler_support> These days a feature does not make it into the C or C++ standards unless there is a working implementation in at least one major toolchain to test it out in practice. > No, didn't save a reference :( > > >> And people got some things right, and some things wrong, at that time. >> I think the same thing will apply now that they /have/ memory models. > > Agreed. > > I'm gobsmacked that it took C/C++ so long to get around to > that /fundamental/ requirement. The absence and the delay > reflects very badly on the C/C++ community. As I said, people managed fine without it. Putting together a memory model that the C folks and C++ folks could agree on for all the platforms they support is not a trivial effort - and I am very glad they agreed here. Of course I agree that it would have been nice to have had it earlier. The thread support (as distinct from the atomic support, including memory models) is far too little, far too late and I doubt if it will have much use.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-08-08 11:09 +0100 |
| Message-ID | <b5giB.179066$W97.95506@fx36.am4> |
| In reply to | #27155 |
On 08/08/17 10:26, David Brown wrote: > On 08/08/17 10:46, Tom Gardner wrote: >> On 08/08/17 09:23, David Brown wrote: >>> On 07/08/17 19:40, Tom Gardner wrote: >>>> On 07/08/17 17:36, Phil Hobbs wrote: >>> >>>>> My stuff is all pthreads, because std::thread didn't exist at the time, >>>>> but it does now, so presumably Boehm's input has been taken into >>>>> account. >>>> >>>> I'm told C/C++12 /finally/ has a memory model, so perhaps >>>> that will (a few decades too late) ameliorate the problem. >>>> We'll see, but I'm not holding my breath. >>> >>> You mean C11/C++11 ? >> >> Oh.... picky picky picky :) > > Well, if you decide to look this up on google, it should save you a bit > of false starts. Unfortunately google doesn't prevent idiots from making tyupos :) (Or is that fortunately?) >>> Whether people will use them >>> appropriately or not, is another matter. >> >> My experience is that they won't. That's for two reasons: >> 1) not really understanding threading/synchronisation >> issues, because they are only touched upon in schools. >> Obviously that problem is language agnostic. > > Agreed. This stuff is hard to understand if you want to get correct > /and/ optimally efficient. > >> 2) any subtleties in the C/C++ specification and >> implementation "suboptimalities"; I expect those will >> exist :( > > I have read through the specs and implementation information - quite a > bit of work has gone into making it possible to write safe code that is > more efficient than was previously possible (or at least practical). It > is not so relevant for small embedded systems, where you generally have > a single core and little in the way of write buffers - there is not > much, if anything, to be gained by replacing blunt full memory barriers > with tuned load-acquire and store-release operations. But for bigger > systems with multiple cpus, a full barrier can cost hundreds of cycles. Agreed, with the caveat that "small" ain't what it used to be. Consider Zynqs: dual-core ARMs with caches and, obviously, FPGA fabric. Consider single 32 core MCUs for £25 one-off. (xCORE) There are many other examples, and that trend will continue. > There is one "suboptimality" - the "consume" memory order. It's a bit > weird, in that it is mainly relevant to the Alpha architecture, whose > memory model is so weak that in "x = *p;" it can fetch the contents of > *p before seeing the latest update of p. Because the C11 and C++11 > specs are not clear enough on "consume", all implementations (AFAIK) > bump this up to the stronger "acquire", which may be slightly slower on > some architectures. One of C/C++'s problems is deciding to cater for, um, weird and obsolete architectures. I see /why/ they do that, but on Mondays Wednesdays and Fridays I'd prefer a concentration on doing common architectures simply and well. >> ISTR that in the early-mid naughties there was a triumphant >> announcement of the first /complete/ C or C++ compiler - 5 >> or 6 years after the standard was published! Of course many >> compilers had implemented a usable subset before that. >> > > Things have changed a good deal since then. The major C++ compilers > (gcc, clang, MSVC) have complete C++11 and C++14 support, with gcc and > clang basically complete on the C++17 final drafts. gcc has "concepts", > slated for C++20 pretty much "as is", and MSVC and clang have prototype > "modules" which are also expected for C++20 (probably based on MSVC's > slightly better version). > > <http://en.cppreference.com/w/cpp/compiler_support> > > These days a feature does not make it into the C or C++ standards unless > there is a working implementation in at least one major toolchain to > test it out in practice. Yes, but I presume that was also the case in the naughties. (I gave up following the detailed C/C++ shenanigans during the interminable "cast away constness" philosophical discussions) The point was about the first compiler that (belatedly) correctly implemented /all/ the features. >>> And people got some things right, and some things wrong, at that time. >>> I think the same thing will apply now that they /have/ memory models. >> >> Agreed. >> >> I'm gobsmacked that it took C/C++ so long to get around to >> that /fundamental/ requirement. The absence and the delay >> reflects very badly on the C/C++ community. > > As I said, people managed fine without it. Putting together a memory > model that the C folks and C++ folks could agree on for all the > platforms they support is not a trivial effort - and I am very glad they > agreed here. Of course I agree that it would have been nice to have had > it earlier. The thread support (as distinct from the atomic support, > including memory models) is far too little, far too late and I doubt if > it will have much use. While there is no doubt people /thought/ they managed, it is less clear cut that it was "fine". I'm disappointed that thread support might not be as useful as desired, but memory model and atomic is more important.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-08-08 12:56 +0200 |
| Message-ID | <omc55c$fi2$1@dont-email.me> |
| In reply to | #27156 |
On 08/08/17 12:09, Tom Gardner wrote: > On 08/08/17 10:26, David Brown wrote: >> On 08/08/17 10:46, Tom Gardner wrote: >>> On 08/08/17 09:23, David Brown wrote: >>>> On 07/08/17 19:40, Tom Gardner wrote: >>>>> On 07/08/17 17:36, Phil Hobbs wrote: >>>> >>>>>> My stuff is all pthreads, because std::thread didn't exist at the >>>>>> time, >>>>>> but it does now, so presumably Boehm's input has been taken into >>>>>> account. >>>>> >>>>> I'm told C/C++12 /finally/ has a memory model, so perhaps >>>>> that will (a few decades too late) ameliorate the problem. >>>>> We'll see, but I'm not holding my breath. >>>> >>>> You mean C11/C++11 ? >>> >>> Oh.... picky picky picky :) >> >> Well, if you decide to look this up on google, it should save you a bit >> of false starts. > > Unfortunately google doesn't prevent idiots from making > tyupos :) (Or is that fortunately?) > >>>> Whether people will use them >>>> appropriately or not, is another matter. >>> >>> My experience is that they won't. That's for two reasons: >>> 1) not really understanding threading/synchronisation >>> issues, because they are only touched upon in schools. >>> Obviously that problem is language agnostic. >> >> Agreed. This stuff is hard to understand if you want to get correct >> /and/ optimally efficient. >> >>> 2) any subtleties in the C/C++ specification and >>> implementation "suboptimalities"; I expect those will >>> exist :( >> >> I have read through the specs and implementation information - quite a >> bit of work has gone into making it possible to write safe code that is >> more efficient than was previously possible (or at least practical). It >> is not so relevant for small embedded systems, where you generally have >> a single core and little in the way of write buffers - there is not >> much, if anything, to be gained by replacing blunt full memory barriers >> with tuned load-acquire and store-release operations. But for bigger >> systems with multiple cpus, a full barrier can cost hundreds of cycles. > > Agreed, with the caveat that "small" ain't what it used to be. > Consider Zynqs: dual-core ARMs with caches and, obviously, FPGA > fabric. True. I'd be happy to see people continue to use full memory barriers - they may not be speed optimal, but they will lead to correct code. Let those who understand the more advanced synchronisation stuff use acquire-release. And of course a key point is for people to use RTOS features when they can - again, using a mutex or semaphore might not be as efficient as a fancy lock-free algorithm, but it is better to be safe than fast. > Consider single 32 core MCUs for £25 one-off. (xCORE) The xCORE is a bit different, as is the language you use and the style of the code. Message passing is a very neat way to swap data between threads or cores, and is inherently safer than shared memory. > There are many other examples, and that trend will continue. > Yes. > >> There is one "suboptimality" - the "consume" memory order. It's a bit >> weird, in that it is mainly relevant to the Alpha architecture, whose >> memory model is so weak that in "x = *p;" it can fetch the contents of >> *p before seeing the latest update of p. Because the C11 and C++11 >> specs are not clear enough on "consume", all implementations (AFAIK) >> bump this up to the stronger "acquire", which may be slightly slower on >> some architectures. > > One of C/C++'s problems is deciding to cater for, um, > weird and obsolete architectures. I see /why/ they do > that, but on Mondays Wednesdays and Fridays I'd prefer > a concentration on doing common architectures simply > and well. > In general, I agree. In this particular case, the Alpha is basically obsolete - but it is certainly possible that future cpu designs would have equally weak memory models. Such a weak model is easier to make faster in hardware - you need less synchronisation, cache snooping, and other such details. > > >>> ISTR that in the early-mid naughties there was a triumphant >>> announcement of the first /complete/ C or C++ compiler - 5 >>> or 6 years after the standard was published! Of course many >>> compilers had implemented a usable subset before that. >>> >> >> Things have changed a good deal since then. The major C++ compilers >> (gcc, clang, MSVC) have complete C++11 and C++14 support, with gcc and >> clang basically complete on the C++17 final drafts. gcc has "concepts", >> slated for C++20 pretty much "as is", and MSVC and clang have prototype >> "modules" which are also expected for C++20 (probably based on MSVC's >> slightly better version). >> >> <http://en.cppreference.com/w/cpp/compiler_support> >> >> These days a feature does not make it into the C or C++ standards unless >> there is a working implementation in at least one major toolchain to >> test it out in practice. > > Yes, but I presume that was also the case in the naughties. No, not to the same extent. Things move faster now, especially in the C++ world. C++ is on a three year update cycle now. The first ISO standard was C++98, with C++03 being a minor update 5 years later. It took until C++11 to get a real new version (with massive changes) - and now we are getting real, significant improvements every 3 years. > (I gave up following the detailed C/C++ shenanigans during the > interminable "cast away constness" philosophical discussions) > > The point was about the first compiler that (belatedly) > correctly implemented /all/ the features. > > >>>> And people got some things right, and some things wrong, at that time. >>>> I think the same thing will apply now that they /have/ memory models. >>> >>> Agreed. >>> >>> I'm gobsmacked that it took C/C++ so long to get around to >>> that /fundamental/ requirement. The absence and the delay >>> reflects very badly on the C/C++ community. >> >> As I said, people managed fine without it. Putting together a memory >> model that the C folks and C++ folks could agree on for all the >> platforms they support is not a trivial effort - and I am very glad they >> agreed here. Of course I agree that it would have been nice to have had >> it earlier. The thread support (as distinct from the atomic support, >> including memory models) is far too little, far too late and I doubt if >> it will have much use. > > While there is no doubt people /thought/ they managed, > it is less clear cut that it was "fine". > > I'm disappointed that thread support might not be as > useful as desired, but memory model and atomic is more > important. The trouble with thread support in C11/C++11 is that it is limited to very simple features - mutexes, condition variables and simple threads. But real-world use needs priorities, semaphores, queues, timers, and many other features. Once you are using RTOS-specific API's for all these, you would use the RTOS API's for thread and mutexes as well rather than <thread.h> calls.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-08-08 15:56 +0100 |
| Message-ID | <GikiB.1254055$Ft7.454124@fx33.am4> |
| In reply to | #27158 |
On 08/08/17 11:56, David Brown wrote: > On 08/08/17 12:09, Tom Gardner wrote: >> On 08/08/17 10:26, David Brown wrote: >>> On 08/08/17 10:46, Tom Gardner wrote: >>>> On 08/08/17 09:23, David Brown wrote: >>>>> On 07/08/17 19:40, Tom Gardner wrote: >>>>>> On 07/08/17 17:36, Phil Hobbs wrote: >>>>> >>>>>>> My stuff is all pthreads, because std::thread didn't exist at the >>>>>>> time, >>>>>>> but it does now, so presumably Boehm's input has been taken into >>>>>>> account. >>>>>> >>>>>> I'm told C/C++12 /finally/ has a memory model, so perhaps >>>>>> that will (a few decades too late) ameliorate the problem. >>>>>> We'll see, but I'm not holding my breath. >>>>> >>>>> You mean C11/C++11 ? >>>> >>>> Oh.... picky picky picky :) >>> >>> Well, if you decide to look this up on google, it should save you a bit >>> of false starts. >> >> Unfortunately google doesn't prevent idiots from making >> tyupos :) (Or is that fortunately?) >> >>>>> Whether people will use them >>>>> appropriately or not, is another matter. >>>> >>>> My experience is that they won't. That's for two reasons: >>>> 1) not really understanding threading/synchronisation >>>> issues, because they are only touched upon in schools. >>>> Obviously that problem is language agnostic. >>> >>> Agreed. This stuff is hard to understand if you want to get correct >>> /and/ optimally efficient. >>> >>>> 2) any subtleties in the C/C++ specification and >>>> implementation "suboptimalities"; I expect those will >>>> exist :( >>> >>> I have read through the specs and implementation information - quite a >>> bit of work has gone into making it possible to write safe code that is >>> more efficient than was previously possible (or at least practical). It >>> is not so relevant for small embedded systems, where you generally have >>> a single core and little in the way of write buffers - there is not >>> much, if anything, to be gained by replacing blunt full memory barriers >>> with tuned load-acquire and store-release operations. But for bigger >>> systems with multiple cpus, a full barrier can cost hundreds of cycles. >> >> Agreed, with the caveat that "small" ain't what it used to be. >> Consider Zynqs: dual-core ARMs with caches and, obviously, FPGA >> fabric. > > True. I'd be happy to see people continue to use full memory barriers - > they may not be speed optimal, but they will lead to correct code. Let > those who understand the more advanced synchronisation stuff use > acquire-release. And of course a key point is for people to use RTOS > features when they can - again, using a mutex or semaphore might not be > as efficient as a fancy lock-free algorithm, but it is better to be safe > than fast. Agreed. >> Consider single 32 core MCUs for £25 one-off. (xCORE) > > The xCORE is a bit different, as is the language you use and the style > of the code. Message passing is a very neat way to swap data between > threads or cores, and is inherently safer than shared memory. Well, you can program xCOREs in C/C++, but I haven't investigated that on the principle that I want to "kick the tyres" of xC. ISTR seeing that the "interface" mechanisms in xC are shared memory underneath, optionally involving memory copies. That is plausible since xC interfaces have an "asynchronous nonblocking" "notify" and "clear notification" annotations on methods. Certainly they are convenient to use and get around some pain points in pure CSP message passing. I'm currently in two minds as to whether I like any departure from CSP purity :) >>> There is one "suboptimality" - the "consume" memory order. It's a bit >>> weird, in that it is mainly relevant to the Alpha architecture, whose >>> memory model is so weak that in "x = *p;" it can fetch the contents of >>> *p before seeing the latest update of p. Because the C11 and C++11 >>> specs are not clear enough on "consume", all implementations (AFAIK) >>> bump this up to the stronger "acquire", which may be slightly slower on >>> some architectures. >> >> One of C/C++'s problems is deciding to cater for, um, >> weird and obsolete architectures. I see /why/ they do >> that, but on Mondays Wednesdays and Fridays I'd prefer >> a concentration on doing common architectures simply >> and well. >> > > In general, I agree. In this particular case, the Alpha is basically > obsolete - but it is certainly possible that future cpu designs would > have equally weak memory models. Such a weak model is easier to make > faster in hardware - you need less synchronisation, cache snooping, and > other such details. Reasonable, but given the current fixation on the mirage of globally-coherent memory, I wonder whether that is a lost cause. Sooner or later people will have to come to terms with non-global memory and multicore processing and (preferably) message passing. Different abstractions and tools /will/ be required. Why not start now, from a good sound base? Why hobble next-gen tools with last-gen problems? >> I'm disappointed that thread support might not be as >> useful as desired, but memory model and atomic is more >> important. > > The trouble with thread support in C11/C++11 is that it is limited to > very simple features - mutexes, condition variables and simple threads. > But real-world use needs priorities, semaphores, queues, timers, and > many other features. Once you are using RTOS-specific API's for all > these, you would use the RTOS API's for thread and mutexes as well > rather than <thread.h> calls. That makes a great deal of sense to me, and it brings into question how much it is worth bothering about it in C/C++. No doubt I'll come to my senses before too long :)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-08-08 17:11 +0200 |
| Message-ID | <omck31$17n$1@dont-email.me> |
| In reply to | #27159 |
On 08/08/17 16:56, Tom Gardner wrote:
> On 08/08/17 11:56, David Brown wrote:
>> On 08/08/17 12:09, Tom Gardner wrote:
>>> On 08/08/17 10:26, David Brown wrote:
>
>
>>> Consider single 32 core MCUs for £25 one-off. (xCORE)
>>
>> The xCORE is a bit different, as is the language you use and the style
>> of the code. Message passing is a very neat way to swap data between
>> threads or cores, and is inherently safer than shared memory.
>
> Well, you can program xCOREs in C/C++, but I haven't
> investigated that on the principle that I want to "kick
> the tyres" of xC.
>
> ISTR seeing that the "interface" mechanisms in xC are
> shared memory underneath, optionally involving memory
> copies. That is plausible since xC interfaces have an
> "asynchronous nonblocking" "notify" and "clear
> notification" annotations on methods. Certainly they
> are convenient to use and get around some pain points
> in pure CSP message passing.
The actual message passing can be done in several ways. IIRC, it will
use shared memory within the same cpu (8 logical cores), and channels
("real" message passing) between cpus.
However, as long as it logically uses message passing then it is up to
the tools to get the details right - it frees the programmer from having
to understand about ordering, barriers, etc.
>
> I'm currently in two minds as to whether I like
> any departure from CSP purity :)
>
>
>>>> There is one "suboptimality" - the "consume" memory order. It's a bit
>>>> weird, in that it is mainly relevant to the Alpha architecture, whose
>>>> memory model is so weak that in "x = *p;" it can fetch the contents of
>>>> *p before seeing the latest update of p. Because the C11 and C++11
>>>> specs are not clear enough on "consume", all implementations (AFAIK)
>>>> bump this up to the stronger "acquire", which may be slightly slower on
>>>> some architectures.
>>>
>>> One of C/C++'s problems is deciding to cater for, um,
>>> weird and obsolete architectures. I see /why/ they do
>>> that, but on Mondays Wednesdays and Fridays I'd prefer
>>> a concentration on doing common architectures simply
>>> and well.
>>>
>>
>> In general, I agree. In this particular case, the Alpha is basically
>> obsolete - but it is certainly possible that future cpu designs would
>> have equally weak memory models. Such a weak model is easier to make
>> faster in hardware - you need less synchronisation, cache snooping, and
>> other such details.
>
> Reasonable, but given the current fixation on the mirage
> of globally-coherent memory, I wonder whether that is a
> lost cause.
>
> Sooner or later people will have to come to terms with
> non-global memory and multicore processing and (preferably)
> message passing. Different abstractions and tools /will/
> be required. Why not start now, from a good sound base?
> Why hobble next-gen tools with last-gen problems?
>
That is /precisely/ the point - if you view it from the other side. A
key way to implement message passing, is to use shared memory underneath
- but you isolate the messy details from the ignorant programmer. If
you have write the message passing library correctly, using features
such as "consume" orders, then the high-level programmer can think of
passing messages while the library and the compiler conspire to give
optimal correct code even on very weak memory model cpus.
You are never going to get away from shared memory systems - for some
kind of multi-threaded applications, it is much, much more efficient
than memory passing. But it would be good if multi-threaded apps used
message passing more often, as it is easier to get correct.
>
>>> I'm disappointed that thread support might not be as
>>> useful as desired, but memory model and atomic is more
>>> important.
>>
>> The trouble with thread support in C11/C++11 is that it is limited to
>> very simple features - mutexes, condition variables and simple threads.
>> But real-world use needs priorities, semaphores, queues, timers, and
>> many other features. Once you are using RTOS-specific API's for all
>> these, you would use the RTOS API's for thread and mutexes as well
>> rather than <thread.h> calls.
>
> That makes a great deal of sense to me, and it
> brings into question how much it is worth bothering
> about it in C/C++. No doubt I'll come to my senses
> before too long :)
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-08-08 16:33 +0100 |
| Message-ID | <QQkiB.494661$8M.287441@fx47.am4> |
| In reply to | #27160 |
On 08/08/17 16:11, David Brown wrote:
> On 08/08/17 16:56, Tom Gardner wrote:
>> On 08/08/17 11:56, David Brown wrote:
>>> On 08/08/17 12:09, Tom Gardner wrote:
>>>> On 08/08/17 10:26, David Brown wrote:
>
>>
>>
>>>> Consider single 32 core MCUs for £25 one-off. (xCORE)
>>>
>>> The xCORE is a bit different, as is the language you use and the style
>>> of the code. Message passing is a very neat way to swap data between
>>> threads or cores, and is inherently safer than shared memory.
>>
>> Well, you can program xCOREs in C/C++, but I haven't
>> investigated that on the principle that I want to "kick
>> the tyres" of xC.
>>
>> ISTR seeing that the "interface" mechanisms in xC are
>> shared memory underneath, optionally involving memory
>> copies. That is plausible since xC interfaces have an
>> "asynchronous nonblocking" "notify" and "clear
>> notification" annotations on methods. Certainly they
>> are convenient to use and get around some pain points
>> in pure CSP message passing.
>
> The actual message passing can be done in several ways. IIRC, it will
> use shared memory within the same cpu (8 logical cores), and channels
> ("real" message passing) between cpus.
>
> However, as long as it logically uses message passing then it is up to
> the tools to get the details right - it frees the programmer from having
> to understand about ordering, barriers, etc.
Just so.
I'm pretty sure:
- all "pure CSP" message passing uses the xSwitch fabric.
- the xC interfaces use shared memory between cores on
the same tile
- whereas across different tiles they bundle up a memory
copy and transmit that as messages across the xSwitch
fabric.
I can't think of a simpler/better way of achieving
the desired external behaviour.
>>> In general, I agree. In this particular case, the Alpha is basically
>>> obsolete - but it is certainly possible that future cpu designs would
>>> have equally weak memory models. Such a weak model is easier to make
>>> faster in hardware - you need less synchronisation, cache snooping, and
>>> other such details.
>>
>> Reasonable, but given the current fixation on the mirage
>> of globally-coherent memory, I wonder whether that is a
>> lost cause.
>>
>> Sooner or later people will have to come to terms with
>> non-global memory and multicore processing and (preferably)
>> message passing. Different abstractions and tools /will/
>> be required. Why not start now, from a good sound base?
>> Why hobble next-gen tools with last-gen problems?
>>
>
> That is /precisely/ the point - if you view it from the other side. A
> key way to implement message passing, is to use shared memory underneath
> - but you isolate the messy details from the ignorant programmer. If
> you have write the message passing library correctly, using features
> such as "consume" orders, then the high-level programmer can think of
> passing messages while the library and the compiler conspire to give
> optimal correct code even on very weak memory model cpus.
>
> You are never going to get away from shared memory systems - for some
> kind of multi-threaded applications, it is much, much more efficient
> than memory passing. But it would be good if multi-threaded apps used
> message passing more often, as it is easier to get correct.
Oh dear. Violent agreement. How boring.
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2017-08-08 21:07 +0300 |
| Message-ID | <opqjocdfqhq89f66icao8l4m84etid3o1p@4ax.com> |
| In reply to | #27160 |
On Tue, 08 Aug 2017 17:11:22 +0200, David Brown
<david.brown@hesbynett.no> wrote:
>On 08/08/17 16:56, Tom Gardner wrote:
>> On 08/08/17 11:56, David Brown wrote:
>>> On 08/08/17 12:09, Tom Gardner wrote:
>>>> On 08/08/17 10:26, David Brown wrote:
>
>>
>>
>>>> Consider single 32 core MCUs for £25 one-off. (xCORE)
When there are a large number of cores/processors available, I would
start a project by assigning a thread/process for each core. Later on
you might have to do some fine adjustments to put multiple threads
into one core or split one thread into multiple cores.
>>>
>>> The xCORE is a bit different, as is the language you use and the style
>>> of the code. Message passing is a very neat way to swap data between
>>> threads or cores, and is inherently safer than shared memory.
>>
>> Well, you can program xCOREs in C/C++, but I haven't
>> investigated that on the principle that I want to "kick
>> the tyres" of xC.
>>
>> ISTR seeing that the "interface" mechanisms in xC are
>> shared memory underneath, optionally involving memory
>> copies. That is plausible since xC interfaces have an
>> "asynchronous nonblocking" "notify" and "clear
>> notification" annotations on methods. Certainly they
>> are convenient to use and get around some pain points
>> in pure CSP message passing.
>
>The actual message passing can be done in several ways. IIRC, it will
>use shared memory within the same cpu (8 logical cores), and channels
>("real" message passing) between cpus.
>
>However, as long as it logically uses message passing then it is up to
>the tools to get the details right - it frees the programmer from having
>to understand about ordering, barriers, etc.
>
>>
>> I'm currently in two minds as to whether I like
>> any departure from CSP purity :)
>>
>>
>>>>> There is one "suboptimality" - the "consume" memory order. It's a bit
>>>>> weird, in that it is mainly relevant to the Alpha architecture, whose
>>>>> memory model is so weak that in "x = *p;" it can fetch the contents of
>>>>> *p before seeing the latest update of p. Because the C11 and C++11
>>>>> specs are not clear enough on "consume", all implementations (AFAIK)
>>>>> bump this up to the stronger "acquire", which may be slightly slower on
>>>>> some architectures.
>>>>
>>>> One of C/C++'s problems is deciding to cater for, um,
>>>> weird and obsolete architectures. I see /why/ they do
>>>> that, but on Mondays Wednesdays and Fridays I'd prefer
>>>> a concentration on doing common architectures simply
>>>> and well.
>>>>
>>>
>>> In general, I agree. In this particular case, the Alpha is basically
>>> obsolete - but it is certainly possible that future cpu designs would
>>> have equally weak memory models. Such a weak model is easier to make
>>> faster in hardware - you need less synchronisation, cache snooping, and
>>> other such details.
>>
>> Reasonable, but given the current fixation on the mirage
>> of globally-coherent memory, I wonder whether that is a
>> lost cause.
>>
>> Sooner or later people will have to come to terms with
>> non-global memory and multicore processing and (preferably)
>> message passing. Different abstractions and tools /will/
>> be required. Why not start now, from a good sound base?
>> Why hobble next-gen tools with last-gen problems?
>>
>
>That is /precisely/ the point - if you view it from the other side. A
>key way to implement message passing, is to use shared memory underneath
>- but you isolate the messy details from the ignorant programmer. If
>you have write the message passing library correctly, using features
>such as "consume" orders, then the high-level programmer can think of
>passing messages while the library and the compiler conspire to give
>optimal correct code even on very weak memory model cpus.
>
>You are never going to get away from shared memory systems - for some
>kind of multi-threaded applications, it is much, much more efficient
>than memory passing. But it would be good if multi-threaded apps used
>message passing more often, as it is easier to get correct.
What is the issue with shared memory systems ? Use unidirectional
FIFOs between threads in shared memory for the actual message. The
real issue how to inform the consuming thread that there is a new
message available in the FIFO.
>
>>
>>>> I'm disappointed that thread support might not be as
>>>> useful as desired, but memory model and atomic is more
>>>> important.
>>>
>>> The trouble with thread support in C11/C++11 is that it is limited to
>>> very simple features - mutexes, condition variables and simple threads.
>>> But real-world use needs priorities, semaphores, queues, timers, and
>>> many other features. Once you are using RTOS-specific API's for all
>>> these, you would use the RTOS API's for thread and mutexes as well
>>> rather than <thread.h> calls.
>>
>> That makes a great deal of sense to me, and it
>> brings into question how much it is worth bothering
>> about it in C/C++. No doubt I'll come to my senses
>> before too long :)
>
>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-08-09 10:03 +0200 |
| Message-ID | <omefd2$917$1@dont-email.me> |
| In reply to | #27162 |
On 08/08/17 20:07, upsidedown@downunder.com wrote: > On Tue, 08 Aug 2017 17:11:22 +0200, David Brown > <david.brown@hesbynett.no> wrote: > >> On 08/08/17 16:56, Tom Gardner wrote: >>> On 08/08/17 11:56, David Brown wrote: >>>> On 08/08/17 12:09, Tom Gardner wrote: >>>>> On 08/08/17 10:26, David Brown wrote: >> >>> >>> >>>>> Consider single 32 core MCUs for £25 one-off. (xCORE) > > When there are a large number of cores/processors available, I would > start a project by assigning a thread/process for each core. Later on > you might have to do some fine adjustments to put multiple threads > into one core or split one thread into multiple cores. The XMOS is a bit special - it has hardware multi-threading. The 32 virtual core device has 4 real cores, each with 8 hardware threaded virtual cores. For hardware threads, you get one thread per virtual core. >>> >>> Sooner or later people will have to come to terms with >>> non-global memory and multicore processing and (preferably) >>> message passing. Different abstractions and tools /will/ >>> be required. Why not start now, from a good sound base? >>> Why hobble next-gen tools with last-gen problems? >>> >> >> That is /precisely/ the point - if you view it from the other side. A >> key way to implement message passing, is to use shared memory underneath >> - but you isolate the messy details from the ignorant programmer. If >> you have write the message passing library correctly, using features >> such as "consume" orders, then the high-level programmer can think of >> passing messages while the library and the compiler conspire to give >> optimal correct code even on very weak memory model cpus. >> >> You are never going to get away from shared memory systems - for some >> kind of multi-threaded applications, it is much, much more efficient >> than memory passing. But it would be good if multi-threaded apps used >> message passing more often, as it is easier to get correct. > > What is the issue with shared memory systems ? Use unidirectional > FIFOs between threads in shared memory for the actual message. The > real issue how to inform the consuming thread that there is a new > message available in the FIFO. > That is basically how you make a message passing system when you have shared memory for communication. The challenge for modern systems is making sure that other cpus see the same view of memory as the sending one. It is not enough to simply write the message, then update the head/tail pointers for the FIFO. You have cache coherency, write re-ordering buffers, out-of-order execution in the cpu, etc., as well as compiler re-ordering of writes. It would be nice to see cpus (or chipsets) having better hardware support for a variety of synchronisation mechanisms, rather than just "flush all previous writes to memory before doing any new writes" instructions. Multi-port and synchronised memory is expensive, but surely it would be possible to have a small amount that could be used for things like mutexes, semaphores, and the control parts of queues.
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2017-08-10 14:30 +0300 |
| Message-ID | <80cooclfcuqrkdhibclmk5h8jklnbnnhrf@4ax.com> |
| In reply to | #27164 |
On Wed, 09 Aug 2017 10:03:40 +0200, David Brown <david.brown@hesbynett.no> wrote: >On 08/08/17 20:07, upsidedown@downunder.com wrote: >> On Tue, 08 Aug 2017 17:11:22 +0200, David Brown >> <david.brown@hesbynett.no> wrote: >> >>> On 08/08/17 16:56, Tom Gardner wrote: >>>> On 08/08/17 11:56, David Brown wrote: >>>>> On 08/08/17 12:09, Tom Gardner wrote: >>>>>> On 08/08/17 10:26, David Brown wrote: >>> >>>> >>>> >>>>>> Consider single 32 core MCUs for £25 one-off. (xCORE) >> >> When there are a large number of cores/processors available, I would >> start a project by assigning a thread/process for each core. Later on >> you might have to do some fine adjustments to put multiple threads >> into one core or split one thread into multiple cores. > >The XMOS is a bit special - it has hardware multi-threading. The 32 >virtual core device has 4 real cores, each with 8 hardware threaded >virtual cores. For hardware threads, you get one thread per virtual core. > >>>> >>>> Sooner or later people will have to come to terms with >>>> non-global memory and multicore processing and (preferably) >>>> message passing. Different abstractions and tools /will/ >>>> be required. Why not start now, from a good sound base? >>>> Why hobble next-gen tools with last-gen problems? >>>> >>> >>> That is /precisely/ the point - if you view it from the other side. A >>> key way to implement message passing, is to use shared memory underneath >>> - but you isolate the messy details from the ignorant programmer. If >>> you have write the message passing library correctly, using features >>> such as "consume" orders, then the high-level programmer can think of >>> passing messages while the library and the compiler conspire to give >>> optimal correct code even on very weak memory model cpus. >>> >>> You are never going to get away from shared memory systems - for some >>> kind of multi-threaded applications, it is much, much more efficient >>> than memory passing. But it would be good if multi-threaded apps used >>> message passing more often, as it is easier to get correct. >> >> What is the issue with shared memory systems ? Use unidirectional >> FIFOs between threads in shared memory for the actual message. The >> real issue how to inform the consuming thread that there is a new >> message available in the FIFO. >> > >That is basically how you make a message passing system when you have >shared memory for communication. The challenge for modern systems is >making sure that other cpus see the same view of memory as the sending >one. It is not enough to simply write the message, then update the >head/tail pointers for the FIFO. You have cache coherency, write >re-ordering buffers, out-of-order execution in the cpu, etc., as well as >compiler re-ordering of writes. Sure you have to put the pointers into non-cached memory or into write-through cache or use some explicit instruction to perform a cache write-back. The problem is the granulation of the cache, typically at least a cache line or a virtual memory page size. While "volatile" just affects code generation, it would be nice to have a e.g. "no_cache" keyword to affect run time execution and cache handling. This would put these variables into special program sections and let the linker put all variables requiring "no_cache" into the same cache line or virtual memory page. The actual implementation could then vary according to hardware implementation. If usage of some specific shared data is defined as a single producer thread (with full R/W access) and multiple consumer threads (with read only access) in a write-back cache system, the producer would activate the write-trough after each update, while each consumer would invalidate_cache before any read access, forcing a cache reload before using the data. The source code would be identical in both producer as well as consumer threads, but separate binary code could be compiled for the producer and the consumers. >It would be nice to see cpus (or chipsets) having better hardware >support for a variety of synchronisation mechanisms, rather than just >"flush all previous writes to memory before doing any new writes" >instructions. Is that really so bad limitation ? >Multi-port and synchronised memory is expensive, but >surely it would be possible to have a small amount that could be used >for things like mutexes, semaphores, and the control parts of queues. Any system with memory mapped I/O registers must have a mechanism that will disable any caching operations for these peripheral I/O registers. Extending this to some RAM locations should be helpful. --- BTW, discussing about massively parallel systems with shared memory resembles the memory mapped file usage with some big data base engines. In these systems big (up to terabytes) files are mapped into the virtual address space. After that, each byte in each memory mapped file is accessed just as a huge (terabyte) array of bytes (or some structured type) by simply assignment statements. With files larger than a few hundred megabytes, a 64 bit processor architecture is really nice to have :-) The OS handles loading a segment from the physical disk file into the memory using the normal OS page fault loading and writeback mechanism. Instead of accessing the page file, the mechanism access the user data base files. Thus you can think about the physical disks as the real memory and the computer main memory as the L4 cache. Since the main memory is just one level in the cache hierarchy, there are also similar cache consistency issues as with other cached systems. In transaction processing, typically some Commit/Rollback is used. I guess that designing products around these massively parallel chips, studying the cache consistency tricks used by memory mapped data base file systems might be helpful.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-08-10 15:11 +0200 |
| Message-ID | <omhlpo$eo6$1@dont-email.me> |
| In reply to | #27165 |
On 10/08/17 13:30, upsidedown@downunder.com wrote: > On Wed, 09 Aug 2017 10:03:40 +0200, David Brown > <david.brown@hesbynett.no> wrote: > >> On 08/08/17 20:07, upsidedown@downunder.com wrote: >>> On Tue, 08 Aug 2017 17:11:22 +0200, David Brown >>> <david.brown@hesbynett.no> wrote: >>> >>>> On 08/08/17 16:56, Tom Gardner wrote: >>>>> On 08/08/17 11:56, David Brown wrote: >>>>>> On 08/08/17 12:09, Tom Gardner wrote: >>>>>>> On 08/08/17 10:26, David Brown wrote: >>>> >>>>> >>>>> >>>>>>> Consider single 32 core MCUs for £25 one-off. (xCORE) >>> >>> When there are a large number of cores/processors available, I would >>> start a project by assigning a thread/process for each core. Later on >>> you might have to do some fine adjustments to put multiple threads >>> into one core or split one thread into multiple cores. >> >> The XMOS is a bit special - it has hardware multi-threading. The 32 >> virtual core device has 4 real cores, each with 8 hardware threaded >> virtual cores. For hardware threads, you get one thread per virtual core. >> >>>>> >>>>> Sooner or later people will have to come to terms with >>>>> non-global memory and multicore processing and (preferably) >>>>> message passing. Different abstractions and tools /will/ >>>>> be required. Why not start now, from a good sound base? >>>>> Why hobble next-gen tools with last-gen problems? >>>>> >>>> >>>> That is /precisely/ the point - if you view it from the other side. A >>>> key way to implement message passing, is to use shared memory underneath >>>> - but you isolate the messy details from the ignorant programmer. If >>>> you have write the message passing library correctly, using features >>>> such as "consume" orders, then the high-level programmer can think of >>>> passing messages while the library and the compiler conspire to give >>>> optimal correct code even on very weak memory model cpus. >>>> >>>> You are never going to get away from shared memory systems - for some >>>> kind of multi-threaded applications, it is much, much more efficient >>>> than memory passing. But it would be good if multi-threaded apps used >>>> message passing more often, as it is easier to get correct. >>> >>> What is the issue with shared memory systems ? Use unidirectional >>> FIFOs between threads in shared memory for the actual message. The >>> real issue how to inform the consuming thread that there is a new >>> message available in the FIFO. >>> >> >> That is basically how you make a message passing system when you have >> shared memory for communication. The challenge for modern systems is >> making sure that other cpus see the same view of memory as the sending >> one. It is not enough to simply write the message, then update the >> head/tail pointers for the FIFO. You have cache coherency, write >> re-ordering buffers, out-of-order execution in the cpu, etc., as well as >> compiler re-ordering of writes. > > Sure you have to put the pointers into non-cached memory or into > write-through cache or use some explicit instruction to perform a > cache write-back. > You also need the data pointed to in coherent memory of some sort (or synchronise it explicitly). It does not help if another processor sees the "data ready" flag become active before the data itself is visible! > The problem is the granulation of the cache, typically at least a > cache line or a virtual memory page size. No, that is rarely an issue. Most SMP systems have cache snooping for consistency. It /is/ a problem on non-uniform multi-processing systems. (And cache lines can lead to cache line thrashing, which is a performance problem but not a correctness problem.) > > While "volatile" just affects code generation, it would be nice to > have a e.g. "no_cache" keyword to affect run time execution and cache > handling. This would put these variables into special program sections > and let the linker put all variables requiring "no_cache" into the > same cache line or virtual memory page. The actual implementation > could then vary according to hardware implementation. That sounds like a disaster for coupling compilers, linkers, OS's, and processor MMU setups. I don't see this happening automatically. Doing so /manually/ - giving explicit sections to variables, and explicitly configuring an MMU / MPU to make a particular area of the address space non-cached is fine. I have done it myself on occasion. But that's different from trying to make it part of the standard language. > > If usage of some specific shared data is defined as a single producer > thread (with full R/W access) and multiple consumer threads (with read > only access) in a write-back cache system, the producer would activate > the write-trough after each update, while each consumer would > invalidate_cache before any read access, forcing a cache reload before > using the data. The source code would be identical in both producer as > well as consumer threads, but separate binary code could be compiled > for the producer and the consumers. That's what atomic access modes and fences are for in C11/C++11. > > >> It would be nice to see cpus (or chipsets) having better hardware >> support for a variety of synchronisation mechanisms, rather than just >> "flush all previous writes to memory before doing any new writes" >> instructions. > > Is that really so bad limitation ? For big SMP systems like modern x86 or PPC chips? Yes, it is - these barriers can cost hundreds of cycles of delay. And if you want the sequentially consistent barriers (not just acquire/release), so that all cores see the same order of memory, you need a broadcast that makes /all/ cores stop and flush all their write queues. (Cache lines don't need flushed - cache snooping takes care of that already.) I have used a microcontroller with a dedicated "semaphore" peripheral block. It was very handy, and very efficient for synchronising between the two cores. > >> Multi-port and synchronised memory is expensive, but >> surely it would be possible to have a small amount that could be used >> for things like mutexes, semaphores, and the control parts of queues. > > Any system with memory mapped I/O registers must have a mechanism that > will disable any caching operations for these peripheral I/O > registers. Extending this to some RAM locations should be helpful. > Agreed. But that ram would, in practice, be best implemented as a separate block of fast ram independent from the main system ram. For embedded systems, a bit of on-chip static ram would make sense. And note that it is /not/ enough to be uncached - you also need to make sure that writes are done in order, and that reads are not done speculatively or out of order. > --- > > BTW, discussing about massively parallel systems with shared memory > resembles the memory mapped file usage with some big data base > engines. > > In these systems big (up to terabytes) files are mapped into the > virtual address space. After that, each byte in each memory mapped > file is accessed just as a huge (terabyte) array of bytes (or some > structured type) by simply assignment statements. With files larger > than a few hundred megabytes, a 64 bit processor architecture is > really nice to have :-) > > The OS handles loading a segment from the physical disk file into the > memory using the normal OS page fault loading and writeback mechanism. > Instead of accessing the page file, the mechanism access the user data > base files. > > Thus you can think about the physical disks as the real memory and the > computer main memory as the L4 cache. Since the main memory is just > one level in the cache hierarchy, there are also similar cache > consistency issues as with other cached systems. In transaction > processing, typically some Commit/Rollback is used. > There is some saying about any big enough problem in computing being just an exercise in caching, but I forget the exact quotation. Serious caching systems are very far from easy to make, ensuring correctness, convenient use, and efficiency. > I guess that designing products around these massively parallel chips, > studying the cache consistency tricks used by memory mapped data base > file systems might be helpful. > Indeed.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2017-08-16 18:39 -0400 |
| Message-ID | <on2hjo$1jsg$1@gioia.aioe.org> |
| In reply to | #27166 |
On 2017-08-10 9:11 AM, David Brown wrote: > That sounds like a disaster for coupling compilers, linkers, OS's, and > processor MMU setups. I don't see this happening automatically. Doing > so/manually/ - giving explicit sections to variables, and explicitly > configuring an MMU / MPU to make a particular area of the address space > non-cached is fine. I have done it myself on occasion. But that's > different from trying to make it part of the standard language. couple comments on this. Compiling for multiple processors I have used named address spaces to define private and shared space. IEC/ISO 18037 The nice part of that is applications can start out running on a single platform and then split later with minimum impact on the source code. Admittedly I have done this on non MMU systems. I have linked across multiple processors including cases of heterogeneous processors. An other comment about inter-processor communication. We found out a long time ago that dual or multi port memory is not that much of an advantage in most applications. The data rate can actually be quite low. We have done quite a few consumer electronics packages with serial data well below a mbit some as low as 8Kbits/second. It creates skew between processor execution but generally has very limited impact on application function or performance. w.. w..
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-08-17 09:37 +0200 |
| Message-ID | <on3gra$84q$1@dont-email.me> |
| In reply to | #27169 |
On 17/08/17 00:39, Walter Banks wrote: > On 2017-08-10 9:11 AM, David Brown wrote: >> That sounds like a disaster for coupling compilers, linkers, OS's, and >> processor MMU setups. I don't see this happening automatically. Doing >> so/manually/ - giving explicit sections to variables, and explicitly >> configuring an MMU / MPU to make a particular area of the address space >> non-cached is fine. I have done it myself on occasion. But that's >> different from trying to make it part of the standard language. > > > couple comments on this. Compiling for multiple processors I have used > named address spaces to define private and shared space. IEC/ISO 18037 "IEC/ISO 18037" completely misses the point, and is a disaster for the world of embedded C programming. It is an enormous disappointment to anyone who programs small embedded systems in C, and it is no surprise that compiler implementers have almost entirely ignored it in the 15 years of its existence. Named address spaces are perhaps the only interesting and useful idea there, but the TR does not cover user-definable address spaces properly. > The nice part of that is applications can start out running on a single > platform and then split later with minimum impact on the source code. > > Admittedly I have done this on non MMU systems. > On some systems, such a "no_cache" keyword/attribute is entirely possible. My comment is not that this would not be a useful thing, but that it could not be a part of the C standard language. For example, on the Nios processor (Altera soft cpu for their FPGAs - and I don't remember if this was just for the original Nios or the Nios2) the highest bit of an address was used to indicate "no cache, no reordering", but it was otherwise unused for address decoding. When you made a volatile access, the compiler ensured that the highest bit of the address was set. On that processor, implementing a "no_cache" keyword would be easy - it was already done for "volatile". But on a processor that has an MMU? It would be a serious problem. And how would you handle casts to a no_cache pointer? Casting a pointer to normal data into a pointer to volatile is an essential operation in lots of low-level code. (It is implementation-defined behaviour, but works "as expected" in all compilers I have heard of.) So for some processors, "no_cache" access is easy. For some, it would require support from the linker (or at least linker scripts) and MMU setup, but have no possibility for casts. For others, memory barrier instructions and cache flush instructions would be the answer. On larger processors, that could quickly be /very/ expensive - much more so than an OS call to get some uncached memory (dma_alloc_coherent() on Linux, for example). uncached accesses cannot be implemented sensible or efficiently in the same way on different processors, and in some systems it cannot be done at all. The concept of cache is alien to the C standards. Any code that might need uncached memory is inherently low-level and highly system dependent. Therefore it is a concept that has no place in the C standards, even though it is a feature that could be very useful in many specific implementations for specific targets. A great thing about C is that there is no problem having such implementation-specific features and extensions. > > I have linked across multiple processors including cases of > heterogeneous processors. > > An other comment about inter-processor communication. We found out a > long time ago that dual or multi port memory is not that much of an > advantage in most applications. The data rate can actually be quite low. > We have done quite a few consumer electronics packages with serial data > well below a mbit some as low as 8Kbits/second. It creates skew between > processor execution but generally has very limited impact on application > function or performance. > > w.. > > w..
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2017-08-17 08:24 -0400 |
| Message-ID | <on41ti$1ifm$1@gioia.aioe.org> |
| In reply to | #27170 |
On 2017-08-17 3:37 AM, David Brown wrote: > "IEC/ISO 18037" completely misses the point, and is a disaster for > the world of embedded C programming. It is an enormous > disappointment to anyone who programs small embedded systems in C, > and it is no surprise that compiler implementers have almost entirely > ignored it in the 15 years of its existence. Named address spaces > are perhaps the only interesting and useful idea there, but the TR > does not cover user-definable address spaces properly. Guilty I wrote the section of 18037 on named address spaces based on our use in consumer applications and earlier WG-14 papers. We extended the named address space material to also include processor named space N1351,N1386 The fixed point material in 18037 is in my opinion reasonable. We use both of these a lot especially in programming the massively parallel ISA's I have been working on in the last few years. w..
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-08-17 16:06 +0200 |
| Message-ID | <on47kq$b3h$1@dont-email.me> |
| In reply to | #27171 |
On 17/08/17 14:24, Walter Banks wrote: > On 2017-08-17 3:37 AM, David Brown wrote: >> "IEC/ISO 18037" completely misses the point, and is a disaster for >> the world of embedded C programming. It is an enormous >> disappointment to anyone who programs small embedded systems in C, >> and it is no surprise that compiler implementers have almost entirely >> ignored it in the 15 years of its existence. Named address spaces >> are perhaps the only interesting and useful idea there, but the TR >> does not cover user-definable address spaces properly. > > > Guilty I wrote the section of 18037 on named address spaces based on our > use in consumer applications and earlier WG-14 papers. > > We extended the named address space material to also include processor > named space N1351,N1386 I don't know the details of these different versions of the papers. I have the 2008 draft of ISO/IEC TR 18037:2008 in front of me. With all due respect to your work and experience here, I have a good deal of comments on this paper. Consider it constructive criticism due to frustration at a major missed opportunity. In summary, TR 18037 is much like EC++ - a nice idea when you look at the title, but an almost total waste of time for everyone except compiler company marketing droids. The basic idea of named address spaces that are syntactically like const and volatile qualifiers is, IMHO, a good plan. For an example usage, look at the gcc support for "__flash" address spaces in the AVR port of gcc: <https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html> The AVR needs different instructions for accessing data in flash and ram, and address spaces provide a neater and less error-prone solution than macros or function calls for flash data access. So far, so good - and if that is your work, then well done. The actual text of the document could, IMHO, benefit from a more concrete example usage of address spaces (such as for flash access, as that is likely to be a very popular usage). The register storage class stuff, however, is not something I would like to see in C standards. If I had wanted to mess with specific cpu registers such as flag registers, I would be programming in assembly. C is /not/ assembly - we use C so that we don't have to use assembly. There may be a few specific cases of particular awkward processors for which it is occasionally useful to have direct access to flag bits - those are very much in the minority. And they are getting more in the minority as painful architectures like COP8 and PIC16 are being dropped in favour of C-friendly processors. It is absolutely fine to put support for condition code registers (or whatever) into compilers as target extensions. I can especially see how it can help compiler implementers to write support libraries in C rather than assembly. But it is /not/ something to clutter up C standards or for general embedded C usage. The disappointing part of named address spaces is in Annex B.1. It is tantalisingly close to allowing user-defined address spaces with specific features such as neat access to data stored in other types of memory. But it is missing all the detail needed to make it work, how and when it could be used, examples, and all the thought into how it would interplay with other features of the language. It also totally ignores some major issues that are very contrary to the spirit and philosophy of C. When writing C, one expects "x = 1;" to operate immediately as a short sequence of instructions, or even to be removed altogether by the compiler optimiser. With a user-defined address space, such as an SPI eeprom mapping, this could take significant time, it could interact badly with other code (such as another thread or an interrupt the is also accessing the SPI bus), it could depend on setup of things outside the control of the compiler, and it could fail. You need to think long and hard as to whether this is something desirable in a C compiler. It would mean giving up the kind of transparency and low-level predictability that are some of the key reasons people choose C over C++ for such work. If the convenience of being able to access different types of data in the same way in code is worth it, then these issues must be made clear and the mechanisms developed - if not, then the idea should be dropped. A half-written half-thought-out annex is not the answer. One point that is mentioned in Annex B is specific little endian and big endian access. This is a missed opportunity for the TR - qualifiers giving explicit endianness to a type would be extremely useful, completely independently of the named address space concept. Such qualifiers would be simple to implement on all but the weirdest of hardware platforms, and would be massively useful in embedded programming. > > The fixed point material in 18037 is in my opinion reasonable. No, it is crap. Look at C99. Look what it gave us over C90. One vital feature that made a huge difference to embedded programming is <stdint.h> with fixed size integer types. There is no longer any need for every piece of embedded C software, every library, every RTOS, to define its own types u16, u16t, uint_16_t, uWORD, RTOS_u16, and whatever. Now we can write uint16_t and be done with it. Then someone has come along and written this TR with a total disregard for this. So /if/ this support gets widely implemented, and /if/ people start using it, what types will people use? Either they will use "signed long _Fract" and friends, making for unreadable code due to the long names and having undocumented target-specific assumptions that make porting an error prone disaster, or we are going to see a proliferation of fract15_t, Q31, fp0_15, and a dozen different incompatible variations. If this was going to be of any use, a set of specific, fixed-size type names should have been defined from day one. The assorted _Fract and _Accum types are /useless/. They should not exist. My suggestion for a naming convention would be uint0q16_t, int7q8_t, etc., for the number of bits before and after the binary point. Implementations should be free to implement those that they can handle efficiently, and drop any that they cannot - but there should be no ambiguity. This would also avoid the next point - C99 was well established before the TR was written. What about the "long long" versions for completeness? Of course, with a sensible explicit naming scheme, as many different types as you want could exist. Then there is the control of overflow. It is one thing to say saturation would be a nice idea - but it is absolutely, totally and completely /wrong/ to allow this to be controllable by a pragma. Explicit in the type - yes, that's fine. Implicit based on what preprocessing directives happen to have passed before that bit of the source code is translated? Absolutely /not/. Equally, pragmas for precision and rounding - in fact, pragmas in general - are a terrible idea. Should the types behave differently in different files in the same code? Next up - fixed point constants. Hands up all those that think it is intuitive that 0.5uk makes it obvious that this is an "unsigned _Accum" constant? Write it as "(uint15q16_t) 0.5" instead - make it clear and explicit. The fixed point constant suffixes exist purely because someone thought there should be suffixes and picked some letters out of their hat. Oh, and for extra fun lets make these suffixes subtly different from the conversion specifiers for printf. You remember? that function that is already too big, slow and complicated for many embedded C systems. Then there is the selection of functions in <stdfix.h>. We have type-generic maths support in C99. There is no place for individual functions like abshr, abslr, abshk, abslk - a single type-generic absfx would do the job. We don't /need/ these underlying functions. The implementation may have them, but C programmers don't need to see that mess. Hide it away as implementation details. That would leave everything much simpler to describe, and much simpler to use, and mean it will work with explicit names for the types. And in the thirteen years that it has taken between this TR being first published, and today, when implementations are still rare, incomplete and inefficient, we now have microcontrollers that will do floating point quickly for under a dollar. Fixed point is rapidly becoming of marginal use or even irrelevant. As for the hardware IO stuff, the less said about that the better. It will /never/ be used. It has no benefits over the system used almost everywhere today - volatile accesses through casted constant addresses. The TR has failed to give the industry anything that embedded C programmers need, it has made suggestions that are worse than useless, and by putting in so much that is not helpful it has delayed any hope of implementation and standardisation for the ideas that might have been helpful. > > We use both of these a lot especially in programming the massively > parallel ISA's I have been working on in the last few years. > Implementation-specific extensions are clearly going to be useful for odd architectures like this. It is the attempt at standardisation in the TR that is a total failure.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2017-08-17 12:15 -0400 |
| Message-ID | <on4fff$824$1@gioia.aioe.org> |
| In reply to | #27172 |
On 2017-08-17 10:06 AM, David Brown wrote: > On 17/08/17 14:24, Walter Banks wrote: > > The AVR needs different instructions for accessing data in flash and > ram, and address spaces provide a neater and less error-prone > solution than macros or function calls for flash data access. > > So far, so good - and if that is your work, then well done. The > actual text of the document could, IMHO, benefit from a more concrete > example usage of address spaces (such as for flash access, as that is > likely to be a very popular usage). The named address space stuff is essentially all mine. > > > The register storage class stuff, however, is not something I would > like to see in C standards. If I had wanted to mess with specific > CPU registers such as flag registers, I would be programming in > assembly. C is/not/ assembly - we use C so that we don't have to > use assembly. There may be a few specific cases of particular > awkward processors for which it is occasionally useful to have direct > access to flag bits - those are very much in the minority. And they > are getting more in the minority as painful architectures like COP8 > and PIC16 are being dropped in favour of C-friendly processors. It > is absolutely fine to put support for condition code registers (or > whatever) into compilers as target extensions. I can especially see > how it can help compiler implementers to write support libraries in > C rather than assembly. But it is/not/ something to clutter up C > standards or for general embedded C usage. To be really clear this was a TR and never expected to be added to the C standards at the time. In the current environment I would like to see the C standards moved forward to support the emerging ISA's. There are many current applications that need additions to the language to describe effective solutions to some problems. Ad-hoc additions prevent the very thing that C is promoted for, that is portability. C standards are supposed to codify existing practice and so often the politics of standards become arguments about preserving old standards rather than support for newer processor technology. I know from what I have been doing is both the spirit and approach to code development in C can deal with changes in applications and processor technology. So many of the development tools still are restricted by the technology limits of development environments of 40 years ago. > > The disappointing part of named address spaces is in Annex B.1. It > is tantalisingly close to allowing user-defined address spaces with > specific features such as neat access to data stored in other types > of memory. But it is missing all the detail needed to make it work, > how and when it could be used, examples, and all the thought into > how it would interplay with other features of the language. It also > totally ignores some major issues that are very contrary to the > spirit and philosophy of C. When writing C, one expects "x = 1;" to > operate immediately as a short sequence of instructions, or even to > be removed altogether by the compiler optimiser. With a > user-defined address space, such as an SPI eeprom mapping, this could > take significant time, it could interact badly with other code (such > as another thread or an interrupt the is also accessing the SPI bus), > it could depend on setup of things outside the control of the > compiler, and it could fail. The named address space has often been used to support diverse forms of memory. To use your example x = 1; The choice where x is located and how it is accessed is made where it is declared. How it is handled after that is made by the compiler. The assumption is that the code is written with functional intent. As valid as the SPI conflict is it is a strawman in practice. C is filled with undefined and ambiguous cases and this type of potential problem in practice is very rare. > > You need to think long and hard as to whether this is something > desirable in a C compiler. I have and it is. Once I passed the general single address space C model named address space opened a level of flexibility that allows C to be used in a variety of application environments that conventional C code does not work well for. > It would mean giving up the kind of transparency and low-level > predictability that are some of the key reasons people choose C over > C++ for such work. If the convenience of being able to access > different types of data in the same way in code is worth it, then > these issues must be made clear and the mechanisms developed - if > not, then the idea should be dropped. A half-written > half-thought-out annex is not the answer. I buy the documentation point. From a usage point I disagree. Writing an application program that can be spread over many processors is a good example. In the two decades since this work was initially done things have changed considerably from consumer products that distributed an application over 3 or 4 processors. (after initially prototyping on a single processor). In these processor usage was almost always manually allocation using geographical centers of reference. This has evolved to compiler analysis that automate this whole process over many many processors. w..
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-08-18 14:45 +0200 |
| Message-ID | <on6n98$g16$1@dont-email.me> |
| In reply to | #27173 |
On 17/08/17 18:15, Walter Banks wrote:
> On 2017-08-17 10:06 AM, David Brown wrote:
>> On 17/08/17 14:24, Walter Banks wrote:
>>
>> The AVR needs different instructions for accessing data in flash and
>> ram, and address spaces provide a neater and less error-prone solution
>> than macros or function calls for flash data access.
>>
>> So far, so good - and if that is your work, then well done. The
>> actual text of the document could, IMHO, benefit from a more concrete
>> example usage of address spaces (such as for flash access, as that is
>> likely to be a very popular usage).
>
> The named address space stuff is essentially all mine.
>
>>
>>
>> The register storage class stuff, however, is not something I would
>> like to see in C standards. If I had wanted to mess with specific CPU
>> registers such as flag registers, I would be programming in assembly.
>> C is/not/ assembly - we use C so that we don't have to use assembly.
>> There may be a few specific cases of particular
>> awkward processors for which it is occasionally useful to have direct
>> access to flag bits - those are very much in the minority. And they
>> are getting more in the minority as painful architectures like COP8
>> and PIC16 are being dropped in favour of C-friendly processors. It
>> is absolutely fine to put support for condition code registers (or
>> whatever) into compilers as target extensions. I can especially see
>> how it can help compiler implementers to write support libraries in
>> C rather than assembly. But it is/not/ something to clutter up C
>> standards or for general embedded C usage.
>
> To be really clear this was a TR and never expected to be added to the C
> standards at the time.
I assume that it was hoped to become an addition to the C standards, or
at least a basis and inspiration for such additions - otherwise what was
the point? I would be quite happy with the idea of "supplementary"
standards to go along with the main C standards, to add features or to
provide a common set of implementation-dependent features. For example,
Posix adds a number of standard library functions, and gives guarantees
about the size and form of integers - thus people can write code that is
portable to Posix without imposing requirements on compilers for an
8051. A similar additional standard giving features for embedded
developers, but without imposing requirements on PC programmers, would
make sense.
>
> In the current environment I would like to see the C standards moved
> forward to support the emerging ISA's. There are many current
> applications that need additions to the language to describe effective
> solutions to some problems. Ad-hoc additions prevent the very thing that
> C is promoted for, that is portability.
C is intended to support two significantly different types of code. One
is portable code that can run on a wide range of systems. The other is
system-specific code that is targeted at a very small number of systems.
If you are writing code that depends on features of a particular ISA,
then you should be using target-specific or implementation-dependent
features.
If a new feature is useful across a range of targets, then sometimes a
middle ground would make more sense. The C standards today have that in
the form of optional features. For example, most targets support nice
8-bit, 16-bit, 32-bit and 64-bit integers with two's complement
arithmetic. But some targets do not support them. So C99 and C11 give
standard names and definitions of these types, but make them optional.
This works well for features that many targets can support, and many
people would have use of.
For features that are useful on only a small number of ISA's, they
should not be in the main C standards at all - a supplementary standard
would make more sense. Yes, that would mean fragmenting the C world
somewhat - but I think it would still be a better compromise.
Incidentally, can you say anything about these "emerging ISA's" and the
features needed? I fully understand if you cannot give details in
public (of course, you'll need to do so some time if you want them
standardised!).
> C standards are supposed to
> codify existing practice and so often the politics of standards become
> arguments about preserving old standards rather than support for newer
> processor technology.
That is a major point of them, yes.
> I know from what I have been doing is both the
> spirit and approach to code development in C can deal with changes in
> applications and processor technology.
>
> So many of the development tools still are restricted by the technology
> limits of development environments of 40 years ago.
It is the price of backwards compatibility. Like most C programmers, I
have my own ideas of what is "old cruft" that could be removed from C
standards without harm to current users. And like most C programmers,
my ideas about what is "old cruft" will include things that some other C
programmers still use to this day.
>
>>
>> The disappointing part of named address spaces is in Annex B.1. It is
>> tantalisingly close to allowing user-defined address spaces with
>> specific features such as neat access to data stored in other types of
>> memory. But it is missing all the detail needed to make it work, how
>> and when it could be used, examples, and all the thought into
>> how it would interplay with other features of the language. It also
>> totally ignores some major issues that are very contrary to the spirit
>> and philosophy of C. When writing C, one expects "x = 1;" to operate
>> immediately as a short sequence of instructions, or even to be removed
>> altogether by the compiler optimiser. With a
>> user-defined address space, such as an SPI eeprom mapping, this could
>> take significant time, it could interact badly with other code (such
>> as another thread or an interrupt the is also accessing the SPI bus),
>> it could depend on setup of things outside the control of the
>> compiler, and it could fail.
>
> The named address space has often been used to support diverse forms
> of memory. To use your example x = 1; The choice where x is located
> and how it is accessed is made where it is declared. How it is handled
> after that is made by the compiler. The assumption is that the code
> is written with functional intent.
>
Yes, that is the nice thing about named address spaces here.
> As valid as the SPI conflict is it is a strawman in practice. C is
> filled with undefined and ambiguous cases and this type of potential
> problem in practice is very rare.
I don't agree. If you first say that named address spaces give a way of
running arbitrary user code for something like "x = 1;", you are making
a very big change in the way C works. And you make it very easy for
programmers to make far-reaching code changes in unexpected ways.
Imagine a program for controlling a music system. You have a global
variable "volume", set in the main loop when the knob is checked, and
read in a timer interrupt that is used to give smooth transition of the
actual volume output (for cool fade-in and fade-out). Somebody then
decides that the volume should be kept in non-volatile memory so that it
is kept over power cycles. Great - you just stick a "_I2CEeprom"
address space qualifier on the definition of "volume". Job done.
Nobody notices that the timer interrupts now take milliseconds instead
of microseconds to run. And nobody - except the unlucky customer -
notices that all hell breaks loose and his speakers are blown when the
volume timer interrupt happens in the middle of a poll of the I2C
temperature sensors.
Now, you can well say that this is all bad program design, or poor
development methodology, or insufficient test procedures. But the point
is that allowing such address space modifiers so simply changes the way
C works - it changes what people expect from C. A C programmer has a
very different expectation from "x = 1;" than "x =
readFromEeprom(address);".
I am /not/ saying the benefits are not worth the costs here - I am
saying this needs to be considered very, very carefully, and features
needed to be viewed in the context of the effects they can cause here.
There are no /right/ answers - but calling it "a strawman in practice"
is very much the /wrong/ answer. Problems that occur very rarely are
the worst kind of problems.
This is a very different case from something like flash access, or
access to ram in different pages, where the access is quite clearly
defined and has definite and predictable timings. You may still have
challenges - if you need to set a "page select register", how do you
ensure that everything works with interrupts that may also use this
address space? But the challenges are smaller, and the benefits greater.
>
>>
>> You need to think long and hard as to whether this is something
>> desirable in a C compiler.
>
> I have and it is. Once I passed the general single address space
> C model named address space opened a level of flexibility that
> allows C to be used in a variety of application environments
> that conventional C code does not work well for.
>
>> It would mean giving up the kind of transparency and low-level
>> predictability that are some of the key reasons people choose C over
>> C++ for such work. If the convenience of being able to access
>> different types of data in the same way in code is worth it, then
>> these issues must be made clear and the mechanisms developed - if not,
>> then the idea should be dropped. A half-written
>> half-thought-out annex is not the answer.
>
> I buy the documentation point.
>
> From a usage point I disagree. Writing an application program that can
> be spread over many processors is a good example.
That is a very different kind of programming from the current
mainstream, and it is questionably as to whether C is a sensible choice
of language for such systems. But okay, let's continue...
> In the two decades
> since this work was initially done things have changed considerably from
> consumer products that distributed an application over 3 or 4
> processors. (after initially prototyping on a single processor). In
> these processor usage was almost always manually allocation using
> geographical centers of reference.
>
> This has evolved to compiler analysis that automate this whole process
> over many many processors.
>
I assume you are not talking about multi-threaded code working on an SMP
system - that is already possible in C, especially with C11 features
like threading, atomic access, and thread-local data. (Of course more
features might be useful, and just because it is possible does not mean
programmers get things right.)
You are talking about MPPA ("Multi purpose processor array") where you
have many small cores with local memory distributed around a chip, with
communication channels between the nodes.
I would say that named address spaces are not the answer here - the
answer is to drop C, or at least /substantially/ modify it. The XMOS xC
language is an example.
A key point is to allow the definition of a "node" of work with local
data, functions operating in the context of that node, and communication
channels in and out. Nodes should not be able to access data or
functions on other nodes except through the channels, though for
convenience of programming you might allow access to fixed data
(compile-time constants, and functions with no static variables, which
can all be duplicated as needed). Channel-to-channel connections should
ideally be fixed at compile time, allowing the linker/placer/router to
arrange the nodes to match the physical layout of the device.
Lots of fun, but not C as we know it.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2017-08-25 09:51 -0400 |
| Message-ID | <onpa18$1m9j$1@gioia.aioe.org> |
| In reply to | #27174 |
On 2017-08-18 8:45 AM, David Brown wrote:
> On 17/08/17 18:15, Walter Banks wrote:
>> On 2017-08-17 10:06 AM, David Brown wrote:
>>> On 17/08/17 14:24, Walter Banks wrote:
>>>
>>
>> To be really clear this was a TR and never expected to be added to
>> the C standards at the time.
>
> I assume that it was hoped to become an addition to the C standards,
> or at least a basis and inspiration for such additions - otherwise
> what was the point? I would be quite happy with the idea of
> "supplementary" standards to go along with the main C standards, to
> add features or to provide a common set of implementation-dependent
> features. For example, Posix adds a number of standard library
> functions, and gives guarantees about the size and form of integers -
> thus people can write code that is portable to Posix without imposing
> requirements on compilers for an 8051. A similar additional standard
> giving features for embedded developers, but without imposing
> requirements on PC programmers, would make sense.
>
>>
>> In the current environment I would like to see the C standards
>> moved forward to support the emerging ISA's. There are many
>> current applications that need additions to the language to
>> describe effective solutions to some problems. Ad-hoc additions
>> prevent the very thing that C is promoted for, that is
>> portability.
>
> C is intended to support two significantly different types of code.
> One is portable code that can run on a wide range of systems. The
> other is system-specific code that is targeted at a very small number
> of systems. If you are writing code that depends on features of a
> particular ISA, then you should be using target-specific or
> implementation-dependent features.
>
> If a new feature is useful across a range of targets, then sometimes
> a middle ground would make more sense. The C standards today have
> that in the form of optional features. For example, most targets
> support nice 8-bit, 16-bit, 32-bit and 64-bit integers with two's
> complement arithmetic. But some targets do not support them. So C99
> and C11 give standard names and definitions of these types, but make
> them optional. This works well for features that many targets can
> support, and many people would have use of.
>
> For features that are useful on only a small number of ISA's, they
> should not be in the main C standards at all - a supplementary
> standard would make more sense. Yes, that would mean fragmenting the
> C world somewhat - but I think it would still be a better
> compromise.
At the time 18037 was written there was a consensus that C should have a
core set of common features and additional standards written to support
specific additional application areas. The working title for 18037 was
"C standards for Embedded Systems". Common core features turned out in
practice to be very difficult to agree on and it was essentially abandoned.
The standard names was the way tying more diverse users together. In
general have worked well to support the types of embedded work that I do
without staying too far from the C language.
>>
>> So many of the development tools still are restricted by the
>> technology limits of development environments of 40 years ago.
>
> It is the price of backwards compatibility. Like most C programmers,
> I have my own ideas of what is "old cruft" that could be removed from
> C standards without harm to current users. And like most C
> programmers, my ideas about what is "old cruft" will include things
> that some other C programmers still use to this day.
The argument is more about development tools than language. Our tools
for example support both compiling to objects and linking as well as
absolute code compiling to an executable. We have supported both for a
long time. Our customers are split over the approach they use for
application development.
We have always compiled directly to machine code in our tools also not a
language specific issue. Development platforms once had limited
resources that were overcome with linking and post assembly translation.
Those restrictions don't apply any more.
The effects of old code generation technology is even more manifest than
that. Linking has become a lot smarter on terms of code generation but
it is a lot more computationally expensive than running a compiler
strategy pass to analyze the data and control flow of and application.
This information can give a compiler an overall plan to create code for
the application this time.
>>
>> The named address space has often been used to support diverse
>> forms of memory. To use your example x = 1; The choice where x is
>> located and how it is accessed is made where it is declared. How it
>> is handled after that is made by the compiler. The assumption is
>> that the code is written with functional intent.
>>
>
> Yes, that is the nice thing about named address spaces here.
>
>> As valid as the SPI conflict is it is a strawman in practice. C is
>> filled with undefined and ambiguous cases and this type of
>> potential problem in practice is very rare.
>
> I don't agree.
>
> I am /not/ saying the benefits are not worth the costs here - I am
> saying this needs to be considered very, very carefully, and
> features needed to be viewed in the context of the effects they can
> cause here. There are no /right/ answers - but calling it "a strawman
> in practice" is very much the /wrong/ answer. Problems that occur
> very rarely are the worst kind of problems.
>
I essentially stand behind my comments. Problems of moving variable
access methods using named address space have had few problems in practice.
>
> That is a very different kind of programming from the current
> mainstream, and it is questionably as to whether C is a sensible
> choice of language for such systems. But okay, let's continue...
Why, I have no real conflict with the historical C and generally have no
reason to want to impact old functionality. My approach is similar to
the K&R argument declaration changes. Add new syntax support both. 20
years later the marketplace will sort out which is used.
>
>> In the two decades since this work was initially done things have
>> changed considerably from consumer products that distributed an
>> application over 3 or 4 processors. (after initially prototyping on
>> a single processor). In these processor usage was almost always
>> manually allocation using geographical centers of reference.
>>
>> This has evolved to compiler analysis that automate this whole
>> process over many many processors.
>>
>
> I assume you are not talking about multi-threaded code working on an
> SMP system - that is already possible in C, especially with C11
> features like threading, atomic access, and thread-local data. (Of
> course more features might be useful, and just because it is possible
> does not mean programmers get things right.)
>
> You are talking about MPPA ("Multi purpose processor array") where
> you have many small cores with local memory distributed around a
> chip, with communication channels between the nodes.
>
That is a close enough description. C has been filled with ad-hoc
separate memory spaces. Thread local data you just mentioned, dsp
separate memory, historical real separate spaces for small embedded
systems, paging and protected memory. Don't discard these but formalize
there declaration and use. Do it in a way that can incorporate
functionally what has been done and don't do anything to impede the
continued use of what is there now.
In a similar way look at the current approach to multiprocessors
support. How different are threads to multiple execution units. Why
shouldn't multiprocessors be managed in similar ways that memory space
is currently managed and allocated now at least allowing for these to be
machine instead of manually optimized? Finally why shouldn't generic
approaches be formalized so the tools aren't restricting application
development?
By arguments for doing this in the C context are two. First the real
impact on the language is small, all are additions not changes and have
no impact on existing code bases. Second C is a living language and has
lasted as long as it has because standards for the language are there to
codify current practices.
w..
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2017-08-01 20:46 -0500 |
| Message-ID | <olrahm$j60$1@dont-email.me> |
| In reply to | #27095 |
Phil Hobbs wrote: > On 07/30/2017 02:05 PM, Tom Gardner wrote: >> On 30/07/17 17:05, Phil Hobbs wrote: >>> Another thing is to concentrate the course work on stuff that's >>> hard to pick up on your own, i.e. math and the more mathematical >>> parts of engineering (especially signals & systems and >>> electrodynamics). >> >> Agreed. >> >>> Programming you can learn out of books without much difficulty, >> >> The evidence is that /isn't/ the case :( Read comp.risks, (which >> has an impressively high signal-to-noise ratio), or watch the news >> (which doesn't). > > Dunno. Nobody taught me how to program, and I've been doing it since > I was a teenager. I picked up good habits from reading books and > other people's code. > From reading fora and such, I don't think people like to learn how to program that much any more. > Security is another issue. I don't do IoT things myself (and try not > to buy them either), but since that's the OP's interest, I agree that > one should add security/cryptography to the list of subjects to learn > about at school. > WRT to programming, generally "safety" or "security" means "don't expose UB in C programs". This becomes political, fast. I dunno that crypto knowlege is of any use or not, beyond the "might need it" level. >> >>> and with a good math background you can teach yourself anything >>> you need to know about. >> >> Agreed. >> >>> Just learning MCUs and FPGAs is a recipe for becoming obsolete. >> >> There's always a decision to be made as to whether to be a >> generalist or a specialist. Both options are valid, and they have >> complementary advantages and disadvantages. > > Being a specialist is one thing, but getting wedded to one set of > tools and techniques is a problem. > > Cheers > > Phil Hobbs > > -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-08-02 09:30 +0200 |
| Message-ID | <olruqd$cp5$1@dont-email.me> |
| In reply to | #27101 |
On 02/08/17 03:46, Les Cargill wrote: > Phil Hobbs wrote: >> On 07/30/2017 02:05 PM, Tom Gardner wrote: >>> On 30/07/17 17:05, Phil Hobbs wrote: >>>> Another thing is to concentrate the course work on stuff that's >>>> hard to pick up on your own, i.e. math and the more mathematical >>>> parts of engineering (especially signals & systems and >>>> electrodynamics). >>> >>> Agreed. >>> >>>> Programming you can learn out of books without much difficulty, >>> >>> The evidence is that /isn't/ the case :( Read comp.risks, (which >>> has an impressively high signal-to-noise ratio), or watch the news >>> (which doesn't). >> >> Dunno. Nobody taught me how to program, and I've been doing it since >> I was a teenager. I picked up good habits from reading books and >> other people's code. >> > You can certainly learn things that way - if the books and the code are good enough. You also need an expert or two that you can talk to (or at least, a good newsgroup!), and be able to research the details. Otherwise you learn from one example that a loop of 10 in C is written "for (i = 0; i < 10; i++)", and then a loop of 100 is "for (i = 0; i < 100; i++)". Then you see a web page with "for (i = 0; i < 100000; i++)" but when you try that on your AVR, suddenly it does not work. Most of the details of particular languages can be picked up from books (or websites), but I think that some training is needed to be a good programmer - you need to understand how to /think/ programming. Mathematics and electronics engineering help too. > From reading fora and such, I don't think people like to learn how to > program that much any more. Well, it is not uncommon in forums and newsgroups to get the people who have ended up with a project that is well beyond their abilities, and/or time frame, and they want to get things done without "wasting" time learning. And of course there are the people who believe they know it all already, and have great difficulty learning. > >> Security is another issue. I don't do IoT things myself (and try not >> to buy them either), but since that's the OP's interest, I agree that >> one should add security/cryptography to the list of subjects to learn >> about at school. >> > > WRT to programming, generally "safety" or "security" means "don't > expose UB in C programs". This becomes political, fast. > What do you mean by that? Undefined behaviour is just bugs in the code. The concept of undefined behaviour in C is a good thing, and helps you get more efficient code - but if your code relies on the results of undefined behaviour it is wrong. In some cases, it might happen to work - but it is still wrong. To be safe and secure, a program should not have bugs (at least not ones that affect safety or security!). That applies to all bugs - be it UB, overflows, misunderstandings about the specifications, mistakes in the specifications, incorrect algorithms, incorrect functions - whatever. UB is not special in that way. And what do you mean by "this becomes political" ? > I dunno that crypto knowlege is of any use or not, beyond the "might > need it" level. > A little crypto knowledge is good, as is lots - but a medium amount of crypto knowledge can be a dangerous thing. Most programmers know that they don't understand it, and will use third-party software or hardware devices for cryptography. They need to know a little about it, to know when and how to use it - but they don't need to know how it works. At the other end, the industry clearly needs a certain number of people who /do/ know how it all works, to implement it. The big danger is the muppets in the middle who think "that 3DES routine is so /slow/. I can write a better encryption function that is more efficient". >>> >>>> and with a good math background you can teach yourself anything >>>> you need to know about. >>> >>> Agreed. >>> >>>> Just learning MCUs and FPGAs is a recipe for becoming obsolete. >>> >>> There's always a decision to be made as to whether to be a >>> generalist or a specialist. Both options are valid, and they have >>> complementary advantages and disadvantages. >> >> Being a specialist is one thing, but getting wedded to one set of >> tools and techniques is a problem. >> >> Cheers >> >> Phil Hobbs >> >>
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2017-08-05 15:11 -0500 |
| Message-ID | <om58ci$2bv$1@dont-email.me> |
| In reply to | #27102 |
David Brown wrote: > On 02/08/17 03:46, Les Cargill wrote: >> Phil Hobbs wrote: <snip> > >> From reading fora and such, I don't think people like to learn how >> to program that much any more. > > Well, it is not uncommon in forums and newsgroups to get the people > who have ended up with a project that is well beyond their abilities, > and/or time frame, and they want to get things done without "wasting" > time learning. And of course there are the people who believe they > know it all already, and have great difficulty learning. > I see a lot of people who really lean on higher-order constructs. IMO, C++ vectors and arrays look remarkably similar, primarily differing in lifespan. But do some people, they're wildly different. NULL pointers and NUL terminated string seem to be a problem for many people. and perhaps just pointers of any sort. >> >>> Security is another issue. I don't do IoT things myself (and try >>> not to buy them either), but since that's the OP's interest, I >>> agree that one should add security/cryptography to the list of >>> subjects to learn about at school. >>> >> >> WRT to programming, generally "safety" or "security" means "don't >> expose UB in C programs". This becomes political, fast. >> > > What do you mean by that? Undefined behaviour is just bugs in the > code. The concept of undefined behaviour in C is a good thing, and > helps you get more efficient code - but if your code relies on the > results of undefined behaviour it is wrong. In some cases, it might > happen to work - but it is still wrong. > That's how I see it as well; others seem see the very existence of UB as one click short of criminal. Then again, perhaps what I am seeing is propaganda trying to create buzz for the Rust language. > To be safe and secure, a program should not have bugs (at least not > ones that affect safety or security!). That applies to all bugs - be > it UB, overflows, misunderstandings about the specifications, > mistakes in the specifications, incorrect algorithms, incorrect > functions - whatever. UB is not special in that way. > > And what do you mean by "this becomes political" ? > By that I mean the tone of communication on the subject becomes shrill and in cases, somewhat hysterical. If this is mainly propaganda then that would also explain it. Lets just say that my confidence that anyone can learn C has been shaken this year. >> I dunno that crypto knowlege is of any use or not, beyond the >> "might need it" level. >> > > A little crypto knowledge is good, as is lots - but a medium amount > of crypto knowledge can be a dangerous thing. Most programmers know > that they don't understand it, and will use third-party software or > hardware devices for cryptography. They need to know a little about > it, to know when and how to use it - but they don't need to know how > it works. > Right. It's like anything complex - we have specialists for that. > At the other end, the industry clearly needs a certain number of > people who /do/ know how it all works, to implement it. > > The big danger is the muppets in the middle who think "that 3DES > routine is so /slow/. I can write a better encryption function that > is more efficient". > Oh good grief. :) <snip> -- Les Cargill
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web