Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connectionsPath: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Michael S Newsgroups: comp.lang.c Subject: Re: C23 thoughts and opinions Date: Mon, 3 Jun 2024 12:00:43 +0300 Organization: A noiseless patient Spider Lines: 230 Message-ID: <20240603120043.00003511@yahoo.com> References: <7d0e8f25-a8ba-4995-9b90-ff35f85d423f@gmail.com> <20240602110213.00003b25@yahoo.com> <20240602162914.0000648c@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Injection-Date: Mon, 03 Jun 2024 11:00:32 +0200 (CEST) Injection-Info: dont-email.me; posting-host="2e115e67b3843932598c276339879624"; logging-data="4002254"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19ZJw/AFtKmwKX4awhCIyjdDzntsUGN9d0=" Cancel-Lock: sha1:wv1w/K+0anSuW5+AKHSOM0wlk74= X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32) Bytes: 11324 On Sun, 2 Jun 2024 21:44:01 +0200 David Brown wrote: > On 02/06/2024 15:29, Michael S wrote: > > On Sun, 2 Jun 2024 14:03:30 +0200 > > David Brown wrote: > > > >> On 02/06/2024 10:02, Michael S wrote: > >>> On Sat, 01 Jun 2024 01:27:41 GMT > >>> scott@slp53.sl.home (Scott Lurndal) wrote: > >>> > >>>> Lynn McGuire writes: > >>>>> On 5/26/2024 6:23 AM, Bonita Montero wrote: > >>>>>> Am 26.05.2024 um 09:13 schrieb jak: > >>>>>> > >>>>>>> About this I only agree partially because it depends a lot on > >>>>>>> the context in which it is used. Moreover, I would not know > >>>>>>> how to indicate an optimal programming language for all > >>>>>>> seasons. > >>>>>> > >>>>>> C++ is in almost any case the better C. > >>>>>> > >>>>>>> What you describe is the greatest inconvenience of c++. To > >>>>>>> make only one example, when they decided to rewrite the FB > >>>>>>> platform to accelerate it, they thought of migrating from php > >>>>>>> to c++ and they had a collapse of the staff suitable for > >>>>>>> work, so they thought of relying a compiler that translated > >>>>>>> the php into c++ and many of the new languages were born to > >>>>>>> try to remedy hits complexity. > >>>>>> > >>>>>> C++ is the wrong language for web applications. > >>>>>> I like Java more for that. > >>>>> > >>>>> C++ is the wrong language for real time apps. > >>>> > >>>> That's an incorrect statement. > >>>> > >>>>> No memory allocation allowed. > >>>> > >>>> It is trivially easy to write C++ code that doesn't > >>>> allocate memory dynamically. > >>>> > >>>>> > >>>>> I use C++ for my server side apps on my webserver. Works > >>>>> great. > >>>> > >>>> I use C++ for operating systems (you can't get more real-time > >>>> than that) > >>> > >>> Engines control is FAR more real-time that OS, to list just one > >>> example out of many. > >> > >> Most engine control software runs on an RTOS - so you have at least > >> as tough real-time requirements for the OS as for the application. > >> > > > > From what I read about this stuff (admittedly, long time ago) even > > when there is a RTOS, the important part runs alongside RTOS rather > > than "on" RTOS. > > I.e. there is high priority interrupt that is never ever masked by > > OS in the region that is anywhere close to expected time and all > > time-sensitive work is done by ISR, with no sort of RTOS calls. > > That's sort-of right. To be precise for something like this, we'd > have to say what exactly we mean by "engine controller". There are > many kinds of engine or motor, and many types of control that are > needed for them. Generally, there is a hierarchy of simpler but more > time-critical parts up to more complex but more flexible parts of the > system. > > As an example of a system of motor control that I've worked on > (electric motors rather than combustion engines), the most > timing-critical signal generation and safety (emergency stop, > overload protection, etc.) are all in hardware - typically dedicated > peripherals in the microcontroller. Some safety parts might also be > implemented in non-maskable interrupt functions that the RTOS can > never disable. > > The low-level control of the motors is typically run by timer > interrupt functions. These may be disabled by the RTOS, but will > only be disabled for a very short (and predictable) time - interrupt > disabling is usually essential to the way locks and inter-process > communication works, including communication between these timer > functions and the rest of the code. Higher level control runs as > RTOS tasks of various priorities, and communication with other boards > is usually a lower priority task. Clearly these real-time tasks > cannot be more "real-time" than the RTOS itself. Other boards might > have high level non-realtime system determining things like path > finding, or user interfaces. > > And until you get to the highest level stuff, there is no reason why > C++ is not suitable. But whether you use C++, C, Assembly, or Ada > for the low-level and more real-time critical code, you avoid dynamic > memory, exceptions, and other techniques that can have unpredictable > failure modes and unexpected delays. (The high-level stuff can be > written in any language.) > > > > >> The OS stuff Scott works with, AFAIK, is real-time OS's for > >> specific tasks such as high-end network equipment. It is not > >> general-purpose or desktop OS's (which I agree are not > >> particularly real-time). > > > > I'd characterized the software running within high-end NIC is as > > very soft real-time. > > I'd characterize it as whatever Scott says it is - he's the expert > there, not you or me. > > > You only care for buffers to not overflow. And if they > > overflow, it's not too bad either. > > That is true for some things, but most certainly not for all usage. > > > The flow is very much unidirectional > > or bi-directional with direction almost independent of each other. > > There are dependencies between directions, e.g. TCP acks, but they a > > weak dependencies timing-wise. > > There is a lot of networking that is not TCP/IP. > > High-speed network interfaces are used for two purposes - to get high > throughput, or to get low latencies. Throughput is not as sensitive > to timing and can tolerate some variation as long as the traffic is > independent, but latency is a different matter. > I think, nearly all work in high-end NIC is concentrated on throughput. For low latency, the best you can do with high end NIC is to disable all high-end features and to hope that in disabled state they do not hurt you too badly. It would be probably better to use specialized "dumb" NIC. I don't know if such things exist, but considering that high-frequency trading is still legal (IMHO, it shouldn't be) I would guess that they do. > > Hard real time is about closed loops, most often closed control > > loops, but not only those. > > > >> > >>> Of course, nowadays most of these things are no longer done on > >>> general-purpose CPUs or even MCUs. > >>> > >> > >> I think you have got that backwards. > >> > >> Most engine control /is/ done with general purpose > >> microcontrollers, or at least specific variants of them. They > >> will use ARM Cortex-R or Cortex-M cores rather than Cortex-A cores > >> (i.e., the "real-time" cores or "microcontroller" cores rather > >> than the "application" cores you see in telephones, Macs, and ARM > >> servers), but they are standard cores. Another common choice is > >> the PowerPC cores used in NXP's engine controllers. > >> > >> It used to be the case that engine control and other critical hard > >> real-time work was done with DSPs or FPGAs, but those days are long > >> past. > >> > > > > Are you sure? > > Pretty sure, yes. > > > It's much simpler and far more reliable to do such task with $5 PLD > > (which today means FPGA that boots from internal flash, rather than > > old day's PLD) than with MCU, regardless of price of MCU. > > No, it is not simpler or more reliable. Programmable logic is rarely > used for engine or motor control. You use microcontrollers with ========== REMAINDER OF ARTICLE TRUNCATED ==========