On 21/11/2022 19:44, Bart wrote:
> On 21/11/2022 17:56, David Brown wrote:
>> On 19/11/2022 22:49, Bart wrote:
>
>>>>>> I even suspect that the CPUs we use today are also as they are in
>>>>>> part due to C. It has been that influential.
>>
>> C is /massively/ influential to the general purpose CPUs we have today.
>
> "Massively" influential? Why, how do you think CPUs would have ended up
> without C?

As I said at the end of my previous post, it's very difficult to tell.
Maybe they would be more varied. Maybe we'd have more stacks. Maybe
we'd be freed from the idea that a "pointer" is nothing more than a
linear address - it could have bounds, or access flags. Registers and
memory could hold type information as well as values. Processors could
have had support for multi-threading or parallel processing. They could
have been designed around event models and signal passing, or have
hardware acceleration for accessing code or data by name. They could
have been better at handling coroutines. There are all kinds of
different things hardware /could/ do, at least some of which would
greatly suit some of the many different kinds of programming languages
we have seen through the years.

A few of these have turned up - there are processors with multiple
stacks optimised for Forth, there were early massively parallel
processors designed alongside the Occam language, the company Linn Smart
Computing made a radical new processor design for more efficient
implementation of their own programming language. Some ARM cores had
hardware acceleration for Java virtual machines.

But I have no specific thoughts - predictions about possible parallel
pasts are just as hard as predictions about the future!

>
> Two of the first machines I used were PDP10 and PDP11, developed by DEC
> in the 1960s, both using linear memory spaces. While the former was
> word-based, the PDP11 was byte-addressable, just like the IBM 360 also
> from the 1960s.
>

C was developed originally for these processors, and was a major reason
for their long-term success.

C was designed with some existing processors in mind - I don't think
anyone is suggesting that features such as linear memory came about
solely because of C. But there was more variety of processor
architectures in the old days, while almost all we have now are
processors that are good for running C code.

> The early microprocessors I used (6800, Z80) also had a linear memory
> space, at a time when it was unlikely C implementations existed for
> them, or that people even thought that much about C outside of Unix.
>
>>   The prime requirement for almost any CPU design is that you should
>> be able to use it efficiently for C.
>
> And not Assembly, or Fortran or any other language?

Not assembly, no - /very/ little code is now written in assembly.
FORTRAN efficiency used to be important for processor design, but not
for a very long time. (FORTRAN is near enough the same programming
model as C, however.)

> Don't forget that at
> the point it all began to change, mid-70s to mid-80, C wasn't that
> dominant. Any C implementations for microprocessors were incredibly slow
> and produced indifferent code.
>
> The OSes I used (for PDP10, PDP11, ICL 4/72, Z80) had no C involvement.
> When x86 popularised segment memory, EVERYBODY hated it, and EVERY
> language had a problem with it.
>

Yes - the choice of the 8086 for PC's was a huge mistake. It was purely
economics - the IBM designers wanted a 68000 processor. But IBM PHB's
said that since the IBM PC was just a marketing exercise and they would
never make more than a few thousand machines, technical benefits were
irrelevant and the 8086 devices were cheaper. (By the same logic, they
bought the cheapest OS they could get, despite everyone saying it was
rubbish.)

> The REASON for segmented memory was becaused 16-bits and address spaces
> larger than 64K words didn't mix. When this was eventually fixed on
> 80386 for x86, that was able to use 32-bit registers.
>
> According to you, without C, we would have been using 64KB segments even
> with 32 bit registers, or we maybe would never have got to 32 bits at
> all. What nonsense!
>

Eh, no. I did not say anything /remotely/ like that.

> (I was designing paper CPUs with linear addressing long before then,
> probably like lots of people.)
>
>
>> ll, the great majority of software is written in languages that, at
>> their core, are similar to C (in the sense that once the compiler
>> front-end has finished with them, you have variables, imperative
>> functions, pointers, objects in memory, etc., much like C).
>
> I wish people would just accept that C does not have and never has had a
> monopoly on lower level languages.
>

I does have, and has had for 40+ years, a /near/ monopoly on low-level
languages. You can dislike C as much as you want, but you really cannot
deny that!

> It a shame that people now associate 'close-to-the-metal' programming
> with a language where a function pointer type is written as
> `void(*)(void)`, and that's in the simples case.
>

I don't disagree that it is a shame, or that better (for whatever value
of "better" you like) low-level languages exist or can be made. That
doesn't change the facts.

>>
>
>>> Really? C was pretty much the only language in the world that does
>>> not specify the size of a byte. (It doesn't even a 'byte' type.)
>>>
>>
>> 8-bit byte and two's complement were, I think, inevitable regardless
>> of C.
>
> So were lots of things. It didn't take a clairvoyant to guess that the
> next progression of 8 -> 16 was going to be 32 and then 64.
>

Agreed.

> (The Z8000 came out in 1979. It was a 16-bit processor with a register
> set that could be accessed as 8, 16, 32 or 64-bit chunks. Actually you
> can also look at 68000 from that era, and the NatSemi 32032. I was an
> engineer at the time and very familiar with this stuff.
>
> C didn't figure in that world at all as far as I was concerned.)
>
>>> It is really nothing at all to do with C. (How would it have
>>> influenced that anyway, given that C implementions were adept are
>>> dealing with any memory model?)
>>>
>>
>> C implementations are /not/ good at dealing with non-linear memory,
>
> No longer likes it, as I said.
>
>> But of course C was not the only influence on processor evolution.
>
> OK, you admit now it was not '/massive/'; good!
>

Would you please stop making things up and pretending I said them?

C was a /massive/ influence on processor evolution and the current
standardisation of general-purpose processors as systems for running C
code efficiently. But it was not the only influence, or the sole reason
for current processor design.

>>>
>>>      #include <stdint.h>
>>>
>>> Otherwise it knows nothing about them. Second, if you look inside a
>>> typical stdint.h file (this one is from gcc/TDM on Windows), you
>>> might well see:
>>>
>>>      typedef signed char int8_t;
>>>      typedef unsigned char uint8_t;
>>>
>>> Nothing here guarantees that int8_t will be an 8-bit type; these
>>> 'exact-width' types are defined on top of those loosely-defined
>>> types. They're an illusion.
>>>
>>
>> Sorry, you are completely wrong here.  Feel free to look it up in the
>> C standards if you don't believe me.
>
> The above typedefs are from a C compiler you may have heard of: 'gcc'.
> Some may well use internal types such as `__int8`, but the above is the
> actual content of stdint.h, and makes `int8_t` a direct synonym for
> `signed char`.
>

They are part of C - specified precisely in the C standards. It does
not matter how any particular implementation defines them. The C
standards say they are part of C, and the type names are introduced into
the current namespace using "#include <stdint.h>" (Or "#include
<inttypes.h>".) The standards also say that "int8_t" is an 8-bit type,
with no padding, and two's complement representation. This has been the
case since C99 - there is no "looseness" or "illusions" in these types.

>
>
>> However, any kind of guesses as to how processors would have looked
>> without C, and therefore what influence C /really/ had, are always
>> going to be speculative.
>
> Without C, another lower-level systems language would have dominated,
> since such a language was necessary.

Perhaps - perhaps not. Domination of a particular market or niche does
not always happen. Perhaps we would instead have Forth, Ada, and
compiled BASIC in an equal balance.

>
> More interesting however is what Unix would have looked like without C.

How do you think it would have looked?