Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Janis Papanagnou 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: References: <868qp1ra5f.fsf@linuxsc.com> <20250319115550.0000676f@yahoo.com> <20250319201903.00005452@yahoo.com> <86r02roqdq.fsf@linuxsc.com> <20250320204642.0000423a@yahoo.com> <87iko3s3h2.fsf@nosuchdomain.example.com> <874izi82a4.fsf@nosuchdomain.example.com> 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: 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