Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: C23 thoughts and opinions
Date: Mon, 3 Jun 2024 18:34:16 +0200
Organization: A noiseless patient Spider
Lines: 174
Message-ID: <v3kra8$3vgef$1@dont-email.me>
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>
 <20240603120043.00003511@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 03 Jun 2024 18:34:17 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9ed1b8381cdac1c9a5b585b8d6eebe0a";
	logging-data="4178383"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/IYKlfDU3m6BBciCEOnQ2LzEWEatKkJ7M="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:ze7mfB82KposDoNc6wMaA1FY/9A=
Content-Language: en-GB
In-Reply-To: <20240603120043.00003511@yahoo.com>
Bytes: 9660

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++. 
========== REMAINDER OF ARTICLE TRUNCATED ==========