On Fri, 9 Feb 2024 15:29:09 +0100
David Brown <david.brown@hesbynett.no> wrote:

> On 09/02/2024 14:55, Michael S wrote:
> > On Thu, 8 Feb 2024 08:52:12 +0100
> > David Brown <david.brown@hesbynett.no> wrote:
> >>
> >> You are just a rounding error :-)
> >>
> >> But it is interesting to hear of exceptions to the general trend.
> >>
> >
> > That is one option.
> > Another one is you pulling your statistics out of one of your major
> > anatomical features.
> >
>
> You do know that embedded Windows - "WinCE" - had its last version
> release in 2013, and ended extended support last year? It's share of
> the market (whatever market you choose) was never particularly
> significant despite significant effort from MS, which is why they
> dropped it.
>
> Clearly my comment about "two or three unfortunate people" was not
> meant as a serious statistic.
>
> And of course people also make systems that can be classified as
> "embedded", but with a desktop (or even server) version of Windows.
>

Do you know that there were two families of Windows OSes intended for
use in embedded devices that used completely different kernels and were
similar only by sharing [significant] part of the user-level API? One
is discontinued. I'd guess, because the CE kernel was designed for a
single core and nowadays even on the low end multiple cores are common.
Discontinued, but still available.
Another one, based on NT family of kernels, is doing similarly to how
it did for the last couple of decades.

The major blow that could kill it in the future is a relatively recent
requirement that all 64-bit kernel drivers should be not just
crypto-signed (that was always a case) but signed by Microsoft's test
lab, which means that it's not just costs money, but also requires
bureaucratic procedures.
But that's what could kill it in the future rather than already
happening.

On 09/02/2024 15:52, Michael S wrote:
> On Fri, 9 Feb 2024 15:29:09 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>
>> On 09/02/2024 14:55, Michael S wrote:
>>> On Thu, 8 Feb 2024 08:52:12 +0100
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>
>>>> You are just a rounding error :-)
>>>>
>>>> But it is interesting to hear of exceptions to the general trend.
>>>>
>>>
>>> That is one option.
>>> Another one is you pulling your statistics out of one of your major
>>> anatomical features.
>>>
>>
>> You do know that embedded Windows - "WinCE" - had its last version
>> release in 2013, and ended extended support last year? It's share of
>> the market (whatever market you choose) was never particularly
>> significant despite significant effort from MS, which is why they
>> dropped it.
>>
>> Clearly my comment about "two or three unfortunate people" was not
>> meant as a serious statistic.
>>
>> And of course people also make systems that can be classified as
>> "embedded", but with a desktop (or even server) version of Windows.
>>
>
> Do you know that there were two families of Windows OSes intended for
> use in embedded devices that used completely different kernels and were
> similar only by sharing [significant] part of the user-level API? One
> is discontinued. I'd guess, because the CE kernel was designed for a
> single core and nowadays even on the low end multiple cores are common.
> Discontinued, but still available.
> Another one, based on NT family of kernels, is doing similarly to how
> it did for the last couple of decades.
>

That's the line that started as "Windows NT 4.0 Embedded", and is now at
"Windows 10 IoT", with a new naming convention every couple of years
along the way? AFAIK - and I admit I don't know a lot here, so correct
me if I'm wrong - these are just normal Windows versions with a few
restrictions and a licensing model better suited to things like kiosks
and point-of-sale systems. I count these as desktop versions of
Windows, not an embedded OS, as they generally run on what is basically
a normal (if small) PC.

But if you count these sorts of things as "embedded", then I agree there
are a large number of embedded Windows systems around.

The market share in this area is, however, dropping significantly as it
is taken by Linux - especially in the guise of Android. (And again, the
total unit numbers are negligible compared to the unit numbers for
microcontroller systems.)

> The major blow that could kill it in the future is a relatively recent
> requirement that all 64-bit kernel drivers should be not just
> crypto-signed (that was always a case) but signed by Microsoft's test
> lab, which means that it's not just costs money, but also requires
> bureaucratic procedures.

It's that kind of thing that makes Linux /so/ much easier for
developers. If MS testing could be viewed as an indication of quality,
reliability, compatibility or security (as in the Apple world), then
there would be value in it for some people.

> But that's what could kill it in the future rather than already
> happening.
>

Cryto-signing and the work and effort involved even for simple drivers
has already pushed smaller customers away. It's one thing to pay the
time, money and developer resources for this nonsense when you are
shipping cash registers to Walmart's, but it's another matter if you are
producing mere hundreds or even a few thousands of systems. My company
is primarily an electronics manufacturing company for third-party
designs (as well as development services), and I can only ever remember
one customer being interested in any sort of embedded Windows system.
But we have lots of them using embedded Linux.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

[some previous material removed or summarized]

> bart <bc@freeuk.com> writes:
>
>> On 07/02/2024 15:36, Ben Bacarisse wrote:
>>
>>> bart <bc@freeuk.com> writes:
>>>
>>>> On 07/02/2024 10:47, Ben Bacarisse wrote:
>>>>
>>>>>> [on choosing between declaring local variables always at the
>>>>>> start of a function, before any statements, or declaring
>>>>>> local variables throughout the body of a function, usually
>>>>>> with an initializing declaration at the point of first use;
>>>>>> an all-at-the-top style gives a single place to look for
>>>>>> all locals used in the function body]
>>>>>
>>>>> You should not need an inventory of what's being operated on.
>>>>> Any function so complex that I can't tell immediately what
>>>>> declaration corresponds to which name needs to be re-written.
>>>>
>>>> But if you keep functions small, eg. the whole body is visible
>>>> at the same time, then there is less need for declarations to
>>>> clutter up the code. They can go at the top, so that you can
>>>> literally can just glance there.
>>>
>>> Declarations don't clutter up the code, just as the code does not
>>> clutter up the declarations. That's just your own spin on the
>>> matter. They are both important parts of a C program.
>>
>> That sounds like your opinion against mine. It's nothing to do
>> with spin, whatever that means.
>
> It's spin, because the term is emotive. "Cluttering up" is how
> you feel about it. The phrase is just a mildly pejorative one
> about appearances. There's no substance there. To make a
> technical point you would have to explain how, for example,
>
> struct item *items;
> ...
> n_elements = get_number_of_items(...);
> items = malloc(n_elements * sizeof *items);
> ...
>
> is technically better than
>
> n_elements = get_number_of_items(...);
> struct item *items = malloc(n_elements * sizeof *items);
>
> I've explained (more than once) how I find reasoning about
> the direct initialise at first use style easier with fewer
> distractions.

I would like to offer another perspective here. First let me state
some personal preferences without giving any whys or wherefores.

I mostly put declarations at the start of a compound statement,
before any statements in the same block. I'm not absolutely opposed
to writing declarations "between statements", but in most cases I
don't if there is a reasonable way to avoid it.

I usually declare variables in the most-nested compound statement
that works. I'm not entirely rigorous about it.

In most cases I write initializing declarations for variables that
are not subsequently modified. For other variables it varies (no
pun intended), but typically such variables are declared without an
initializer.

When writing for() statements, sometimes I use the declaring form
for the first clause, but most of the time I don't.

I am strongly biased in favor of keeping function bodies short. To
put some numbers on that, 25 lines for almost all functions, 40
lines for longer functions, and 60 lines for all functions (with the
qualifier that longer than 60 lines is not categorically excluded,
but there needs to be a compelling argument that observing the
60-line bound is not feasible). Those numbers are of course meant
as upper bounds, and not as being typical or representative.

I strongly prefer code that looks clean. The word "clean" here
means lots of different things, but "easy on the eyes" might be a
good capsule summary. That said, the measure is not purely visual:
it's also important that the code be semantically clean, but that
idea is even harder to define than visual appearance.

(Amusing aside: as it happens I recently wrote a function whose
body consisted of 25 initializing declarations, followed by four
one-line imperative statements and then a single simple return
statement.)

Now here are some explanations.

Short functions are easier to understand than long functions.
Conversely, functions that are, say, longer than a single page are
very likely to be more difficult to comprehend. A corollary to this
relationship is that long functions need to be cleaner than short
functions: a short function body can bend or break style rules
without losing too much understandability, but long function bodies
tend to become harder to understand much faster if they aren't
fastidious in hewing to good style aesthetics.

In choosing where to put declarations, I find that I have a
different mindset when reading declarations than when reading
executable statements. (Yes I know initializing declarations are
executable but I think everyone knows what I mean.) Switching
between those two mindsets, even though it may be subconscious,
requires some amount of mental effort, so it's mentally easier (for
me anyway) when reading code to keep declarations and statements
separate. I often will put in a blank line after the declarations
and before the statements, especially in the outermost block of a
function. The blank line both makes it easier to find the dividing
point between the two regimes and also gives a kind of mental cue to
(maybe make it easier to) switch from one mindset to the other.

Another concern is uniformity. Putting declarations at top of block
always works; trying to declare at the point of first use sometimes
doesn't. Similarly using the expression form of for() always works,
but trying to use declaration-style for()s sometimes doesn't. Being
completely uniform is not an absolute requirement, or even a super
high priority, but it does exert a slight pressure in the direction
of choosing top-of-block declarations rather than being mixed in
with executable statements.

I should say explicitly that the above statements, and indeed I
think all the statements in this posting, are relating only my own
reactions and assessments, and for sure other people may have
different reactions and assessments, and there is no contradiction
in that. Each person has his or her own central nervous system, and
how different people react can vary a lot from person to person. An
example I like to give about myself is I am partially colorblind, so
things like putting keywords in a different color are in many cases
worse than useless for me, no matter how helpful they may be for
other people.

Now I would like to offer some views on the earlier discussions.

First, I don't think what bart is advocating is completely without
merit. His position is more strict than my own, but certainly there
is some overlap.

Second, I think there is also some merit in the declare-at-first-use
style, especially when such a declaration includes initialization
and the variable being declared is never changed after the
declaration. I don't use this style all the time but there are
instances where it clearly does better than the alternatives.

Third, what I think is the key difference between my choices and the
other styles debated is that, at least in this domain, my approach
is less dogmatic and more pragmatic. Along this particular axis
flexibility is key. (Having said that, I should add that I cannot
envision ever completely abandoning initializing-declarations.)

Fourth, I would not describe the notion that "declarations clutter
up [non-declaration statements]" as spin. Don't get me wrong, there
are plenty of things that certain people say that I /do/ think of as
spin, but in my view this isn't one of them. Also let me add that I
share your frustration that some people don't make more of an effort
to express themselves in more objective ways. In this case though I
think what is being voiced is a good faith effort to express a
personal reaction and not a disingenuous and artificially negative
statement made purely to rile people up (which I guess is my own
rough translation of the word "spin").

Wwll, I guess that's all. My thanks to everyone for their
attention. I hope y'all have gotten some value from my musings.

On Fri, 9 Feb 2024 17:22:53 +0100, David Brown wrote:

> But we have lots of them using embedded Linux.

What sort of CPUs, out of interest? Presumably x86/x86-64, ARM ... maybe
even RISC-V by now? Anything else (e.g. Motorola ColdFire)? Any feel for
relative popularity?

On 10/02/2024 08:18, Lawrence D'Oliveiro wrote:
> On Fri, 9 Feb 2024 17:22:53 +0100, David Brown wrote:
>
>> But we have lots of them using embedded Linux.
>
> What sort of CPUs, out of interest? Presumably x86/x86-64, ARM ... maybe
> even RISC-V by now? Anything else (e.g. Motorola ColdFire)? Any feel for
> relative popularity?

Almost all ARM, as far as I know, with a couple of x86 systems. But I
don't know the details of everything we make as pure production
contracts - it's only if the developers are needed to help with
problems, suggest improvements for the customers, or work with test
setups that we get involved.

Long ago, I worked a little with both MIPS and Coldfire embedded Linux
systems, but those are pretty much gone from the market now.

On Sat, 10 Feb 2024 17:11:47 +0100, David Brown wrote:

> Long ago, I worked a little with both MIPS and Coldfire embedded Linux
> systems, but those are pretty much gone from the market now.

MIPS gone as well? At one point I heard they were accounting for something
like 840 million chips per year. They had a particular niche in wireless
routers.

The company that used to own what there was of the MIPS IP is now called
Imagination Tech, and has gone all-in on RISC-V.

bart <bc@freeuk.com> writes:

> On 09/02/2024 00:02, Tim Rentsch wrote:
>
>> bart <bc@freeuk.com> writes:
>>
>>> You're never in a million years going to admit that my language
>>> has some good points are you?
>>
>> Where can I get a user manual for it?
>
> Why?

Because having at least some kind of user manual is a
sine qua non of any programming language that is meant
to be taken seriously. Any language that doesn't is
nothing more than a toy or pet project.

Furthermore, you may expect that no one will shower
your language with praise if all they ever hear is
you bragging about it.

On 10/02/2024 22:23, Lawrence D'Oliveiro wrote:
> On Sat, 10 Feb 2024 17:11:47 +0100, David Brown wrote:
>
>> Long ago, I worked a little with both MIPS and Coldfire embedded Linux
>> systems, but those are pretty much gone from the market now.
>
> MIPS gone as well? At one point I heard they were accounting for something
> like 840 million chips per year. They had a particular niche in wireless
> routers.
>

Emphasis on /had/. MIPS used to be the most common architecture in
routers of all kinds, but they have been pushed out by ARM. You see
them only in legacy designs. (Of course, many routers, switches, and
the like are still made with them - there's no need to change a hardware
design that works perfectly well for the task. But you won't find many
/new/ chips with MIPS cores.)

> The company that used to own what there was of the MIPS IP is now called
> Imagination Tech, and has gone all-in on RISC-V.

RISC-V has a number of technical and economic advantages over the
incumbent, ARM. How much of the market it will take remains to be seen.
(I personally hope it gains a lot - the x86/ARM duopoly is not good
for the market.)