Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
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 10:13:41 +0100
Organization: A noiseless patient Spider
Lines: 101
Message-ID: <vs5p85$2cucj$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>
 <vs3bvj$489m$1@dont-email.me> <vs4sln$1haaa$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 28 Mar 2025 10:13:44 +0100 (CET)
Injection-Info: dont-email.me; posting-host="2d3aa20cc6d3d8f05810bfc1b507b87c";
	logging-data="2521491"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+8VVrPD5UCjEXtZfpbKZ412LVHKlFKI1I="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:91doRJrxs6hRntr2lzaphJHgQf0=
In-Reply-To: <vs4sln$1haaa$1@dont-email.me>
Content-Language: en-GB

On 28/03/2025 02:05, Janis Papanagnou wrote:
> On 27.03.2025 12:14, bart wrote:
>> On 27/03/2025 02:24, Janis Papanagnou wrote:

>>
>> Also, by a 'few KB' I meant single figures, like 2-8KB for the code,
>> plus RAM. That Atari seems to have a bit more available.
> 
> Yes, I was comparing it with the "standard" IBM PC (which had 640 kB)
> and the Atari ST had first (I think) 500 kB (mine, a later version,
> had 1 MB).

So you are talking about a completely different world.  You are 
criticising machines of the class of ZX Spectrum, with 8-bit processors 
and 4KB - 32KB rom and ram, for using BASIC - and justifying it by 
telling us what you used on a a system more than an order of magnitude 
bigger?

As a few other points relating to things you have been talking about - 
the original IBM PC had 32 KB rom with BASIC, and typical systems had 64 
KB ram, not 640 KB.  (Of course later models and clones had more ram.)

And the Atari ST came with BASIC, and had a 68000 processor.  It is odd 
that you had that machine (which, alongside the Commodore Amiga, was 
widely and rightly considered fantastic machine, hardware and software), 
while also ridiculing two of its most important features.

> You are right to point out that some BASIC interpreters were provided
> in a ROM. I don't recall the ROM sizes of all the PCs I used back then,
> but I remember the Sharp PC 1401 pocket calculator that had 40 kB ROM
> for the OS with BASIC.
> 
>>
>> I've never used Basic. But it is one language I admire, even if it is
>> crude:
>>
>>    10 let a=0
>>    20 let a=a+1
>>    30 if a<1000000 then 20
>>    40 print a
> 
> Okay, you "admire" BASIC (and you found the 68000 CPU "wonderful");
> that tells a lot about your background and expertise.
> 

BASIC was an excellent language for the time, and for the resources 
available on these small systems.  It's a poor choice for larger 
programs, but that's not an issue for small systems.

You are the first person I have heard say that the 68000 was /not/ a 
great design - both in terms of the ISA and the implementation.

> 
> Try for a moment to understand that the quality of a CPU architecture is
> not (for assembler programmers) something measured in transistors.
> 
> There's huge differences in processor _architectures_, though...
> 

When you talk in general about a processor design, it includes /both/ 
the hardware design (for which transistor count is a factor) /and/ the 
ISA, as seen by programmers.  But it is fine, and often helpful, to 
separate these aspects.

So is it the ISA of the m68k that you don't like?  Given the massive 
popularity of the architecture (you can /still/ buy 68000 chips, and 
/new/ devices based on the m68k ISA were developed and released until 
about 10 years ago), it seems a minority opinion.

I've yet to see an ISA that I think is "perfect", and popularity of use 
does not imply technical quality, but the m68k stands out as 
extraordinarily good, especially compared to other ISA's of the time.

>>
>>>>
>>>> But also at that time - early 80s when Spectrums etc were popular -
>>>> there were some wonderful new 16/32-bit processors such as 68000,
>>>> Z8000/0 and NS32032, of which only the first survived.
> 
> If you mention 68000 and NS32032 playing in the same architectural
> league then it's hard for me to consider you a serious discussion
> partner.
> 

Indeed.  After all, the 68k was one of the most successful ISAs ever, 
and the x86 "won" for economic reasons, not technical reasons.  The 
NS32000, on the other hand, is known only to a few nerds.  I expect a 
large proportion of people in this newsgroup have had computers or 
devices with an 68k chip in them - Unix workstations, Apple Macs, games 
consoles, Wifi routers or network switches, Palm PDAs, calculators, 
printers - they were everywhere.

To be fair on the NS32000,  I don't think the ISA was the problem for 
the devices.  After all, the ISA was very similar to that of the 68k, 
albeit a bit more limited.  Both were multi-register orthogonal CISC (as 
distinct from accumulator and specialised register CISC, like the x86) 
with 8 32-bit general registers and a range of addressing modes 
including direct memory operations.  Both had linear addressing spaces 
and floating point coprocessors.