Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.lang.c
Subject: Re: The integral type 'byte' (was Re: Suggested method for returning
 a string from a C program?)
Date: Fri, 28 Mar 2025 02:59:42 +0100
Organization: A noiseless patient Spider
Lines: 147
Message-ID: <vs4vqf$1jono$1@dont-email.me>
References: <vrd77d$3nvtf$2@dont-email.me> <868qp1ra5f.fsf@linuxsc.com>
 <vrdhok$47cb$2@dont-email.me> <20250319115550.0000676f@yahoo.com>
 <vreuj1$1asii$4@dont-email.me> <vreve4$19klp$2@dont-email.me>
 <20250319201903.00005452@yahoo.com> <86r02roqdq.fsf@linuxsc.com>
 <vrh1br$35029$2@dont-email.me> <LRUCP.2$541.0@fx47.iad>
 <vrh71t$3be42$1@dont-email.me> <vrh9vh$3ev9o$1@dont-email.me>
 <vrhct4$3frk8$2@dont-email.me> <20250320204642.0000423a@yahoo.com>
 <vrhphb$3s62l$1@dont-email.me> <87iko3s3h2.fsf@nosuchdomain.example.com>
 <vrrvgp$1828d$1@dont-email.me> <874izi82a4.fsf@nosuchdomain.example.com>
 <vrttin$321rm$1@dont-email.me> <vrus18$3srn9$1@dont-email.me>
 <vruttb$3tpl0$1@dont-email.me> <vrv15d$1gs4$1@dont-email.me>
 <vs0kv7$1hb4h$2@dont-email.me> <vs11oi$1tp3r$1@dont-email.me>
 <vs1b8b$24nub$5@dont-email.me> <vs1ftc$2a7cq$1@dont-email.me>
 <vs225e$2pgqi$1@dont-email.me> <vs2ctp$34jvu$1@dont-email.me>
 <vs3lu9$di1m$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 28 Mar 2025 02:59:44 +0100 (CET)
Injection-Info: dont-email.me; posting-host="5e1941e9827e8475e54bd78cd6c2c6c5";
	logging-data="1696504"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX180ouehNF3IC1wZIfiSQc36"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:VbOjfl1S/Pd1A8h2mQBJEL4L/N0=
X-Enigmail-Draft-Status: N1110
In-Reply-To: <vs3lu9$di1m$1@dont-email.me>
Bytes: 8689

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