Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
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: <v2l828$18v7f$1@dont-email.me>
	<v2o57g$1t5p4$1@raubtier-asyl.eternal-september.org>
	<7d0e8f25-a8ba-4995-9b90-ff35f85d423f@gmail.com>
	<v2p91e$26lpk$1@raubtier-asyl.eternal-september.org>
	<beffc569-3606-b627-ded9-93ce8478f2dd@please.ty>
	<v2qfi0$2de9j$1@raubtier-asyl.eternal-september.org>
	<v2unfe$3alds$1@dont-email.me>
	<v2v637$3cunk$1@raubtier-asyl.eternal-september.org>
	<v3dmq6$2edto$1@dont-email.me>
	<hOu6O.6223$xPJ1.1866@fx09.iad>
	<20240602110213.00003b25@yahoo.com>
	<v3hn2j$3bdjn$1@dont-email.me>
	<20240602162914.0000648c@yahoo.com>
	<v3ii22$3g9ch$1@dont-email.me>
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 <david.brown@hesbynett.no> wrote:

> On 02/06/2024 15:29, Michael S wrote:
> > On Sun, 2 Jun 2024 14:03:30 +0200
> > David Brown <david.brown@hesbynett.no> 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 <lynnmcguire5@gmail.com> 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 ==========