Re: C23 thoughts and opinions

On 03/06/2024 11:00, Michael S wrote:

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:
  

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

I think Scott can answer the high-end NIC questions a lot better than I could.

 

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
appropriate peripherals, such as sophisticated PWM units and encoder
interfaces, and advanced timers.
>

 I was not talking about electric motors.

Petrol and diesel engines have far less demanding requirements for the timing of their control systems.  The fastest control loops you need to control them are a fraction of the speed of those used for high-end electric motor control, and the corresponding acceptable jitter levels are much less fussy.  And they are invariably controlled by microcontrollers, and have been for decades.  (The microcontrollers you use typically have some specialised timing peripherals.)
However, I would not be surprised to see programmable logic in the controllers for jet engines, if that is what you are talking about.  The markets there are too small, and the control details too different between different models, for there to be microcontrollers with jet-engine peripherals.  But regardless, it is all still hierarchical in the same way, with a RTOS and real-time software tasks sitting above the dedicated hardware and below the high-level control software.

>
Well, Linus is not on his team, but if he was, he would say the same
thing. But probably at much higher rate than weekly.
  

>
Yes, but Linux Torvalds knows shit about C++.  He knows a lot about
C, and many other things.
>
He also - not unreasonably - believes that if C++ was used in the
Linux kernel, lots of others who know nothing about using C++ in OS's
and low-level work would make a complete mess of things.  You don't
want someone to randomly add std::vector<> or the like into kernel
code.  You don't want people who take delight in smart-arse coding,
such as some regulars in c.l.c++, anywhere near the kernel.
>

 Or may be he understand that [for kernel] proclaimed advantages of C++
do not matter or matter too little. And disadvantage of higher
difficulty to see quickly what's going on, is real.
 It is interesting to mention that experienced 46 y.o. Dave Cutler and
young student Linus Torvalds independently came to the same conclusion
w.r.t. to kernel language choice.

You /do/ understand that these decisions were made some 30 years ago? The languages, developers, compilers, targets, and many other things have changed in that time.

That despite Cutler's employer being
very C++-oriented at that moment and despite most of the decisions
taken during the peak years of OO hype.
Unlike Torvalds, Cutler was not in a position to fully disable
development of 3-rd party kernel modules in C++, but he did his best to
discourage this practice.
 

But other OS's are not the Linux kernel - it has particularly unique
challenges.  If you have an appropriate team, C++ is vastly better
for writing RTOS kernels than C.
>

 I find your statement unproven.
How many surviving and proliferating RTOS kernels are written in
each language?
 

Oh, there's little doubt that most publicly available RTOS kernels are in C, not C++.  That does not mean C is in any way /better/ for the task.  There are multiple reasons for C being the language of choice here:
1. Most well-known RTOS kernels have a history stretching back to the previous century.  C++ was not nearly as viable an option at that time, for a great many reasons.
2. If you write your kernel in C++, you pretty much have to use C++ for the application code unless you also write a C API for it.  If you write your kernel in C, you can use almost any language for the application code.
3. Most well-known RTOS's are for microcontrollers, often including small CISC devices and other microcontrollers for which toolchain support was traditionally poor, expensive, and barely classifiable as C90 never mind C++ or even C99.  If you want to support these devices, C90 is the only way to go.
4. There is a bizarre attitude in a lot of the embedded world that "ANSI C" (meaning C89/C90) is somehow magical and "the standard".  Marketing departments see it as a "feature" that the code is written to this long out-dated and inferior language standard.
5. Lots of embedded programmers are not great programmers, or not educated as programmers - they are hardware or electronics engineers that have moved into software.  C90 is often all they know, and certainly they have never learned more than basic C++.
So there are plenty of reasons why C (especially C90) is dominant in RTOS's.  Note that none of these are technical reasons - C90 is never chosen because it is a /better/ language than C++ (or even C99).  It is chosen /despite/ being a weaker language.  (Some non-technical reasons can be good arguments, of course - but in most cases they are not.)
After all, there is virtually nothing that you can write in C90 that you cannot use directly in modern C++.  Baring a few cases where you need casts in C++ but not in C (and such casts are typically mandated by embedded coding standards anyway), you can compile the same code as C++.   Since you can do almost everything with modern C++ that you can with C90 or C99, and you can do vastly more with modern C++ - resulting in /much/ safer coding, as long as the programmers are competent - it is obvious that an appropriately restricted subset C++ is a technically better choice of language.