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

On 3/27/2025 6:59 PM, 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).
 

>
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.
 Anyway, I perceived the use of anything else than BASIC a challenge
on such systems; it seemed they were designed to just provide BASIC.
 

>
Remember, these systems did not have the resources you are talking
about.  The Atari ST was a monster compared to the popular home
computers - 512 KB ram on the cheapest version, compared to more typical
16 KB - 32 KB ranges.  And it had a price to match, way out of reach of
most home users.

 Yes. I compared it to the 640 kB of the ("quasi-standard") IBM PC.
 

[...]
>

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.
 

>

[...]
>
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.
 

However, your point /is/ still valid - people who are only
familiar with one programming language will have difficulty
understanding its limitations or seeing the benefits of other languages,
and tend to look at problems from a perspective limited by their own
language.

 Yes, this is actually a platitude (and I was reluctant to mention it
in the first place), but a general phenomenon, not restricted to IT.
 

[...]

>
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. 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).
 

[...]

>
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 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)

It's been a while since I coded up raw SPARC ASM. Remember that branch delay slot? Ever use it with a MEMBAR instruction? Shit would hit the fan.

should have
been considered, also (e.g.) support of addressing data structures as
known from (back then) contemporary languages; the NS 32xxx supported
that for example. 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.
 Janis