On 13-08-2024 08:37, Erik Christiansen via Dng wrote:
> On 10.08.24 22:06, Steve Litt wrote:
> > Hendrik Boom said on Thu, 8 Aug 2024 10:51:40 -0400
> >
> > >On Thu, Aug 08, 2024 at 09:35:50AM -0500, o1bigtenor via Dng wrote:
> > >> On Thu, Aug 8, 2024 at 8:52 AM Dan Purgert via Dng
> > >>
> > >> Why is C/C++ so absolutely wonderful?
> > >
> > >Primarily because C (not C++) has been around for a longer time
> > >than most other tools.  Old enough that it was around when Linux got
> > >written and it has become the interlingua for Linux software.
> > >
> > >Not because it's a great language.
> >
> > I think it's a pretty darn good language. It makes sense, its syntax is
> > pretty guessable (except for pointers to functions), and it's a small
> > language that's easily learned.
> >
> > >
> > >It was a breath of fresh air in the 1970's, but by now language
> > >technology has advanced a lot since then.
> >
> > I wouldn't be caught dead doing threads in C.
> >
>
> Having only done Embedded development (software & some hardware) in a 30
> year career (now 16 years behind me), I only used assembler and C. In the
> latter case, no heap, as malloc is indeterministic, so unviable in hard
> realtime. There were times where a DIY block allocator was used, e.g.
> for message packets - with fixed block size, it could always grab the
> first available, and so was deterministic. (And a memory leak would
> interfere with the design goal of 25 year uptime.)
>
> Much of the embedded work was telecoms call control - up to hundreds of
> threads, one per concurrent call, using one state machine code base. The
> design language was ITUT SDL (Specification Z.100), allowing any mix of
> interacting state machines, each with any number of threads. (Max fixed
> at run-time.)
>
> I grant that C is not ideal for implementing that ... so I sometimes did
> it in assembler - sort of. Using DIY macros, it was not difficult to
> create a limited macro-language providing states, transitions, signal
> (event) handling, and instance variable handling to the degree needed.
> The queues and multi-threaded timer service needed was fun to implement.
> Purely event-driven software is a bit different. There can be no looping
> or long-winded processing in a state transition as it is merely
> cooperatively multi-tasking.
>
> And in the early days, there were no compilers for the little 8-bit
> microcontrollers used. (Though one system had 13 of them, hierarchically
> handling network interface, call control, and system supervision. With
> an average of 62.5 uS per trunk channel at the top, and a 0.6 MIPS
> processor, assembler and dodging averages were it - in 1982.)
>
> Porting an RTOS implementation from 68000 assembler to PowerPC was a fun
> month's work, involving learning both those instruction sets, and
> providing an interesting comparison. I'd rather do that than muck with
> C++ any day.
>
> Being able to build the GNU toolchain for 68000, PowerPC, V850, AVR,
> etc. from project to project was productivity enhancing. And always
> working on HP-UX, Solaris, Linux over the decades, with Vi then Vim,
> gcc, and exuberant ctags, "*nix is the IDE" was manifest.
>
> I remember an NEC engineer asking "Is gcc code vulnerable to the SLD &
> SST instruction hardware bug on the V850?" It didn't take long to be
> able to answer that Nick Clifton had obviated the issue in August 2005.
> I seriously doubt that could have been established in ten minutes if
> we'd used a commercial toolchain.
>
> And I still value understanding that gobbeldygook like "dereferencing"
> merely refers to "indirect addressing", something that pretty much every
> processor has in its instruction set. Not all syntactic sugar is
> beneficial, I think.
>
> Erik
>
Not exactly embedded software but this does remind me of the (1993)
design principals for The Decision Support System (BOS) of the Storm
Surge Barrier at Hook of Holland in The Netherlands.

- Limited to standard Unix calls (X/Open compliant)

- No threads used, but separately monitored processes

- C++ limited to “safe” constructs

- No third-party class libraries used

- Simple straightforward interprocess communication

- Using Named Pipes for reliability

- Atomic writes

- Guaranteed delivery

- Content not lost when process dies or disconnects


Everything for safety and speed and still functioning since 1997.

Grtz.

Nick