On 31/07/2023 21:38, Vir Campestris wrote:
> On 28/07/2023 22:32, Ed Prochak wrote:
>
> >>No but porting a version of unix to an 8 bit machine is possible.
> >>Performance would suffer on 16bit and higher operations but
> >>it is possible.
>
> All the genuine 8-bit machines I've used were limited to 64k RAM. CPU
> speed might not be an issue, but I think RAM size would be.

I've used at least one with 256KB memory (eg. the PCW 8256), and also
created a Z80-based prototype myself with extra, bank-switched memory.

An OS could use clever bank-switching, or it can use the extra memory
for a RAMdisk, or for data rather than code. There are possibilities.

But in the end it was easier to switch to 8088/86-based machines even
with their segmented memory.

In article <ua95pr$3cff7$1@dont-email.me>,
Vir Campestris <vir.campestris@invalid.invalid> wrote:
....
>(And BTW, as someone who spent decades making a living out of 8080 and
>its successors - I didn't like any of them)

Kinda like working at McDonalds, right?

--
When someone tells me he/she is a Christian I check to see if I'm
still in possession of my wallet.

On 2023-07-31, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <ua95pr$3cff7$1@dont-email.me>,
> Vir Campestris <vir.campestris@invalid.invalid> wrote:
> ...
>>(And BTW, as someone who spent decades making a living out of 8080 and
>>its successors - I didn't like any of them)
>
> Kinda like working at McDonalds, right?

Well ... you can work with and dislike the 8080, but still like a solid
three out of these four: coworkers, boss, customers, compensation.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 29/07/2023 02:15, Paul Edwards wrote:
> On Thursday, July 27, 2023 at 9:44:00 PM UTC+8, David Brown wrote:
>
>>> Ok, but that is declaring a variable specifically as int8_t -
>>> which didn't even exist in C90 - but "signed char" does, so
>>> let's say that was used.
>>>
>> Yes - so what? People declare variables of all kinds of types.
>
> For what reason would people be declaring an integral
> type int8_t? I've never felt the need to do that. I just
> use "int" and expect that to be portable.

I use "int" where "int" is appropriate, and "int8_t" and whatever that
suits. And I expect both to be portable, with the exception of
specialist devices such as some DSP's that don't have 8-bit (and maybe
not even 16-bit) types.

Usually a type such as "int8_t" has three main uses. One is if you are
working on 8-bit processors. Another is if you have large arrays, or
arrays of structs, and want compact storage of small data types. The
third is to match fixed structures such as file formats, network packet
formats, or hardware registers.

>
> When you're programming on an x64 how often do you
> code int8_t?

I very rarely write code in C for x86-64. But if I needed a big array
of small numbers, I'd use int8_t (or uint8_t, or whatever was suitable).

> I bet people are coding int8_t when they're
> about to build an 8080 program because they know
> what the immediate resource constraints are and are
> basically writing non-portable code.
>

Nobody writes code for 8080 devices any more, nor have they done so for
decades. But people /do/ write C code for 8-bit devices, and then
int8_t will turn up regularly.

> I guess that's an underlying assumption I failed to mention.
>
> I'm trying to write portable code, even for my operating
> system code (obviously with the exception of some
> minimal assembler).

Portable to what? It is extremely rare to have to make code portable to
/any/ architecture with a C implementation. Often you can make
reasonable assumptions that hold true for all the targets you are
interested in. (And often these assumptions are not actually needed in
order to write good code.)

>
>> And C99 became standard a generation ago - it's okay to use it.
>
> Cobol was a standard in various years too. It's OK to use
> that too.
>

Use Cobol where Cobol is appropriate. For C programming, there are
almost no systems that are in use today that do not have C99 toolchains.
(Even MSVC supports almost all C99 now.) The <stdint.h> types are
available in most pre-C99 toolchains too.

> My question is about C90. That is the language I know
> and wish to use.
>

OK. Write a version of <stdint.h> for whatever ancient toolchain you
have managed to dig up, and we are back to using int8_t and other
standard types.

> One day I may rewrite my entire C90 OS and toolchain
> in Pascal or Turtle Graphics, but I haven't completed
> C90 yet.
>
>>> I normally don't define such a narrow type. I was "taught"
>>> to define variables as "int" unless you have a good reason
>>> to do otherwise, and let it match the natural word size
>>> (which is why I expect "int" to be 64-bit on an x64).
>
>> You were taught badly - or at least, badly outdated. A better rule is
>> to use the appropriate type for the task.
>
> This is a conceptual change to give a new language.

No, it is standard practice for all programming languages ever made (at
least, those with types). It is not a "conceptual change" to suggest
using a screwdriver for screws, rather than always using a hammer.

>
> I'm not saying that it's right or wrong (I'm not claiming to
> be a language expert). I'm just saying that it's not the
> language I am currently programming in, and my question
> is about C90. Or possibly K&R C 1. ie the original intent
> of the language.
>

Even pre K&R1 C had more than one type.

> I am exploring what Ritchie had in mind. I am willing to
> change it if I find a place where Ritchie was "obviously"
> insane, but so far I haven't found anything wrong at all.
>

Ritchie was smart enough to use modern tools, modern languages, and
modern programming techniques - and if they were not good enough, he
made new ones. The idea of using C90 today, or 8080 processors, or
sticking to "int" as your only type, is about as far from Ritchie's
mindset as you can get.

>> "int" is often a reasonable enough choice when you can't think of
>> anything better, and you are only working with small numbers (up to
>> 16-bit) or know the platform must be 32-bit int minimum (maybe your code
>> is full of POSIX calls), and you are not storing a lot of them (you
>> don't want to waste cache space with big arrays of "int" when uint8_t
>> would have sufficed), and you don't need maximal speed for local
>> variables on 64-bit targets.
>
> It is not that I will "only be working with small numbers".
> It is that I am expecting the program to adapt to - and
> have the same limitations as - the target machine, not
> the source code.
>
> So if I have a calculator program, I expect to be able to add
> up numbers to 2**31 on a 32-bit machine and up to 127 on
> the 8080. If my "users" (ie me) doesn't like that, then they
> should upgrade processor.
>

You expect incorrectly. "int" is never smaller than 16-bit.

But it is not unreasonable to let the limits for some things depend on
the architecture.

> A calculator is not a particularly good example. The number
> of arguments to main() would be a better example.
>
>>> I don't even use "short" - never had a reason to.
>
>> "short" is also /long/ outdated, IMHO. Use types that say what you
>> mean. "short" really doesn't say anything at all, and has no guarantees
>> that "int" does not also have.
>
> And what I normally mean is "adapt to the target machine's
> natural word size as Ritchie said (as far as I know that's what
> he said)".

Except "int" does not do that, at least not entirely. It does not adapt
to anything smaller than 16 bits, and on most 64-bit architectures, it
is implemented as 32-bit.

>
> Unless I'm dealing with files, and then I use "long", as C90 says.
>
>> "int" says "at least 16-bits, and a reasonably efficient local type for
>
> It didn't say that in K&R 1 and I am questioning the ANSI
> committee's decision to put a constraint there.
>

K&R 1 gave a list of sizes for different machines, with 16-bit as the
smallest for "int". K&R 2 made "int" a minimum size of 16 bits,
predating the ANSI standard publication (though I have no idea who made
the decision about it).

I have never heard of any C implementation that considered itself
remotely standard (even "K&R 1 standard") that had int smaller than
16-bit. Maybe others have heard of such systems.

> Maybe they figured that no-one would ever program
> for the 8080 again so no-one will complain.
>

The 8080 was discontinued in 1990, while K&R 2 was published in 1988.
The 8080 had therefore been long surpassed by other devices by then.
However, other 8-bit devices were extremely common at the time, and are
still in common use. There is no reason to suppose the 8080 in
particular was remotely relevant to either the ANSI C committee, or the
K&R authors or editors. Both groups were fully aware of the importance
of 8-bit systems at the time.

> That was an incorrect assumption.
>

If they assumed that no one (baring a small handful of enthusiasts)
would program 8080 devices again, they'd have been right. But I doubt
they even considered it.

>>> I don't think K & R 1 specified a minimum size for "int".
>>>
>> I believe they specified it had to be at least -32767 to 32767 in range,
>> but I don't have a copy of the book handy.
>
> I believe that is wrong, and was answered a month ago
> or something. I was expecting someone else to confirm
> that before I replied.
>

I have looked, at it was not until the second edition that a minimum
range was specified. In the first edition, only example sizes were
given, with 16-bit being the smallest.

>> Regardless, K&R C is as relevant as ancient Latin - great for historical
>> interest, but not for any real-world coding done today.
>
> I'm not necessarily doing what you call "real-world coding".
>