Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?)

On 28/03/2025 02:59, Janis Papanagnou wrote:

On 27.03.2025 15:04, David Brown wrote:

On 27/03/2025 03:24, Janis Papanagnou wrote:

On 27.03.2025 00:21, bart wrote:

On 26/03/2025 18:09, Janis Papanagnou wrote:

[...]

>
Many of the BASIC's on home computers were quite sophisticated - the BBC
Micro (and later Archimedes) versions were famously advanced.  Of course
versions for things like the ZX80 - with 4 KB rom, and 1 KB ram (for
screen memory, OS data, interpreter data, BASIC program, and BASIC data)
were very limited.

 I've programmed with a couple BASIC dialects back these days; besides
the mainframe thing; Olivetti, Wang, Commodore, Sharp. As seen from a
big picture, they all were basically the same crude thing. Only few
years later; Algol 68, Pascal, Simula, C, Fortran (half a step back),
C++, Java, and so on. Each of these languages was a progress compared
to BASIC (even Fortran, that I disliked as well).
 

Yes, each of these had advantages over BASIC and were better suited to many uses.  So what?  They are different kinds of languages.  BASIC was useful in ways that none of these others were remotely suitable.  You don't teach schoolkids programming with Fortran any more than you write linear algebra systems in BASIC.  You don't put a C compiler in an interactive computer with 8 KB rom and ram any more than you write an OS in BASIC.
Yes, BASIC was crude and limited - /all/ programming languages of that era were crude and limited by today's standards, because /all/ computers were crude and limited.  BASIC was perhaps more crude and limited than others of the time, because it was used primarily on computers that were more crude and limited.
And as computers got more powerful, so did the BASICs that ran on them - the BASIC on a BBC Micro was massively more powerful and structured than the BASIC on a ZX81.

>
Pascal would have been hopeless on such systems.  A compiled - or even
byte-compiled (such as P-code) - language would be totally out of the
question.  A minimal Pascal implementation, such as existed for the BBC
Micros and the ZX Spectrum, needed more in the range of 16 K rom /
program and the same again of ram for source code, compiled /
byte-compiled code, and program data.

 I seem to recall that there were Pascal compilers available for a
couple of those old PC systems.

Yes, as I said.  I used a couple of them (though only briefly).

 Anyway, I perceived the use of anything else than BASIC a challenge
on such systems; it seemed they were designed to just provide BASIC.

No other language came close to BASIC as a language that could be implemented in very small code space, a very small ram space, and was easy to learn for beginners.  The systems were not designed to provide BASIC - they were designed to be cheap and easy to use, and that meant putting BASIC in a rom rather than than having large and expensive ram or /very/ expensive disk storage.

[...]
>

I think it was a professor at the university who meant that anyone
who started with BASIC would be incapable of ever doing real CS.

>
It was Dijkstra who said that.  As usual, his comments were
entertainingly exaggerated when made, and then taken out of context.

 No, I meant another professor whose lectures I attended at our
University. - It could of course be that he was just citing Dijkstra,
but he didn't sound as if he did; it was certainly his strong opinion.
 

You can be very confident that he was citing, or paraphrasing, Dijkstra.

>

[...]
>
The point with BASIC is that if all you know is BASIC without knowing
anything else you probably won't be able to understand the problems
with it. I know you have a broader language repertoire, so I presume
you know BASIC's deficiencies (or at least the deficiencies of those
BASIC dialects that were around until around 1980).

>
That was not Dijstra's point at all - it was the "trial and error"
attitude to programming that you got from interpreted languages that he
disliked.

 As said, I wasn't attributing that to Dijkstra but a local professor.
And the argument was not about interpreters but more about lacking
structuring features, hard coded line numbers, gotos, and a lot more
the like.

That is like criticising the Romans for using chariots instead of cars. It is just prejudice and ignorance.
Later languages were able to have better structuring, and didn't need line numbers, because the systems they were designed for were faster, and had text editors.
And later BASICs had more structure, and dispensed with the need for line numbers.  With BBC BASIC, for example, you very rarely referred to line numbers at all, and code was well structured (albeit limited to a single file).

>
The 68000, specifically, is a great example for an inferior CPU
architecture. (Your mileage obviously varies if you think it was
even "wonderful".)

>
What do you think is "inferior" about the 68k architecture?  At the
time, the main business-world competitor, the 8086, was 8-bit with some
16-bit features, and built with a view towards backwards compatibility
rather than the future.  The 68k had a 32-bit ISA with a 16-bit ALU -
looking towards the 32-bit future while accepting that it had to be
cost-effective.

 I wouldn't compare it to the x86 series - my opinion on that is not
much different to the 68k.

Is that based on your ignorance of x86 or ignorance of 68k?  I doubt if many people think the x86 has ever been a good architecture, but the 68k is generally viewed very differently.

Have a look at the NS 32016/32 processors
(around 1979/1984). If you know the 68k but not the NS 32xxx you may
want to have a look into, e.g., "1986_National_NS32000_Databook.pdf"
(that you will find online).

I had a look, to augment the little I knew of the NS30000 ISA.  It is very similar to the 68k in many ways.  I think you'd have to dig into fine detail to see real differences.
So, again, what do /you/ think is "inferior" about the 68k architecture?   Either I'm missing something, or you are missing something.

 

[...]

>
SPARC certainly had some interesting features and concepts.  (I never
used it, but read a fair bit about it, and briefly used the Altera NIOS
soft core that had some similarities.)  The TMS320C24x DSPs I used were
utterly horrible.

 I used it for the implementation of a channel encoding system, a
typical "signal processing" application; it was great. Imagining
I would have to use any other processor I already knew these days
(65xx, 68k, x86)... - that would have been really annoying.
 

There's no doubt that the TMS320 devices can be used to do many types of DSP-style operations very efficiently.  That's not the point - that does not stop it from being horrible to work with.  (It is also fair to characterise it as an "interesting" architecture - that is also not at odds with being horrible to use.)

[...]

>
There are plenty of things I find disappointingly similar between most
cpu architectures.  It's hard for novel ideas to break through.

 But there were ideas! But not only the interesting ideas (like the
frame shift on the stack [SPARC]; one detail I memorized) should have
been considered,

Yes, I like the register window idea of the SPARC.  But it is hard to make it scalable - it would be significantly more flexible if the register window was actually a memory window with a specialised cache setup.

also (e.g.) support of addressing data structures as
known from (back then) contemporary languages; the NS 32xxx supported
that for example.

Can you give an example?
There was, back then, a tendency for CISC processors to have a lot of complicated addressing modes to access certain data structures.  It was later shown that these were inefficient and limited, and it was better to have faster register calculations and do the addressing calculations in software - for the 68030 and 68040, compilers ignored the complicated addressing modes and did the scaling and indirections in software because it was faster.  Later implementations of the 68k ISA, like the Coldfire, dropped the messiest address modes entirely.  Of course, the NS32000 didn't have the address registers of the 68k, so the balance might have been different there.

And these ideas were already old; see for example
Seegmüller: Einführung in die Systemprogrammierung (1974)
(And I would be surprised if he'd been the first who described that.)
 But yes, the "break through" factors (e.g. the market factors) were
an issue.
 

Part of
the blame for that, of course, is the success of C - a cpu design tends
to be successful if and only if it is efficient for the C model of
programming, other than for a few specialised areas (like graphics work
or some highly SIMD-friendly algorithms).  I'd like to see cpu designs
with multiple stacks, multiple register banks for fast task switching,
hardware support for multi-tasking, locks, atomic accesses,
transactional memory, CSP-style message passing, memory allocation,
buffer management, etc.  There are countless bits and pieces that could
make processors much faster and much more secure for a lot of work.
>
The XMOS devices are one of the few architectures to come up with really
new ideas and have some market success.

 For a long time now I'm not up to date any more with CPUs and their
architectural differences.
 

I can recommend reading about the XMOS.  (It's for embedded use, not a general-purpose processor.)