On 26/07/2023 17:15, Paul Edwards wrote:
>
> I've never attempted to program in C on an 8-bit machine.
> I wouldn't have thought that the short&int = 16-bit minimum
> would be suitable.
>

I can't answer for the days of CP/M, but for the last twenty years at
least, C has been the main language of choice on 8-bit systems. 8-bit
exists almost exclusively in the world of small microcontrollers, and
while other languages (assembly, C++, Pascal, FORTH, Ada, BASIC) are all
used to some extent, C dominates.

There are two main ways in which the 16-bit "int" size is not a problem
on such systems. One is the use of compilers with a lot of extensions,
and possibly non-standard behaviour, geared towards more efficient
results. These are particularly popular on CISC 8-bit systems with few
registers.

The other method is better compiler optimisation - the compiler may
perform "int8_t a, b, c; a = b + c;" using just a single 8-bit add
despite the integer promotions to 16-bit, because it knows the result
will be correct.

(I have also seen the use of a C++ class that holds a single 8-bit value
and provides arithmetic operations, as a more efficient type than int8_t
because it is never subject to integer promotions. A limited subset of
C++ can work very well on 8-bit devices.)

On Thursday, July 27, 2023 at 7:41:40 PM UTC+8, David Brown wrote:

> I can't answer for the days of CP/M, but for the last twenty years at
> least, C has been the main language of choice on 8-bit systems. 8-bit
> exists almost exclusively in the world of small microcontrollers, and
> while other languages (assembly, C++, Pascal, FORTH, Ada, BASIC) are all
> used to some extent, C dominates.
>
> There are two main ways in which the 16-bit "int" size is not a problem
> on such systems. One is the use of compilers with a lot of extensions,
> and possibly non-standard behaviour, geared towards more efficient
> results. These are particularly popular on CISC 8-bit systems with few
> registers.

Ok, but that's almost an admission that C90 is not up to the task.
I have found C90 perfectly fine for my 16-bit and 32-bit
programming. ie I normally just define an "int" and let it
float.

> The other method is better compiler optimisation - the compiler may
> perform "int8_t a, b, c; a = b + c;" using just a single 8-bit add
> despite the integer promotions to 16-bit, because it knows the result
> will be correct.

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.

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

I don't even use "short" - never had a reason to.

I don't think K & R 1 specified a minimum size for "int".

As such - what are the ramifications of making "int" 8 bits
on a 8080?

I mean - yes, I know that it violates the C90 standard, but
after 33 years of strict adherence to it, maybe it is time for
us to part ways.

But not upwards to C99.

Instead, just a little bit down towards K & R 1.

> (I have also seen the use of a C++ class that holds a single 8-bit value
> and provides arithmetic operations, as a more efficient type than int8_t
> because it is never subject to integer promotions. A limited subset of
> C++ can work very well on 8-bit devices.)

It seems odd to not simply make int 8 bits rather than go to all
that effort. People are spending a lot of effort to type int8_t and
use C++ at all for a reason - it's the natural word type and they
know it. And they know that "int" isn't doing what it was
conceptually meant to do.

Just conjecture - not saying I'm reading the situation correctly.

BFN. Paul.

On 27/07/2023 15:00, Paul Edwards wrote:
> On Thursday, July 27, 2023 at 7:41:40 PM UTC+8, David Brown wrote:
>
>> I can't answer for the days of CP/M, but for the last twenty years at
>> least, C has been the main language of choice on 8-bit systems. 8-bit
>> exists almost exclusively in the world of small microcontrollers, and
>> while other languages (assembly, C++, Pascal, FORTH, Ada, BASIC) are all
>> used to some extent, C dominates.
>>
>> There are two main ways in which the 16-bit "int" size is not a problem
>> on such systems. One is the use of compilers with a lot of extensions,
>> and possibly non-standard behaviour, geared towards more efficient
>> results. These are particularly popular on CISC 8-bit systems with few
>> registers.
>
> Ok, but that's almost an admission that C90 is not up to the task.
> I have found C90 perfectly fine for my 16-bit and 32-bit
> programming. ie I normally just define an "int" and let it
> float.
>

It is an admission that toolchains are not up to the task - at least,
they can't generate ideal object code (especially for the ugly CISC
8-bit architectures with disjointed memory spaces) without adding to the
language and having the programmer write code in "Keil 8051" or "IAR
COP8" instead of standard C.

However, SDCC does a pretty good job while straying very little from
standard C, and for the 8-bit RISC AVR microcontroller, gcc is usually
used in a reasonably standard mode (there is an "8-bit int" mode
available if you want it, but I don't think it is much used).

Standard C is not a /great/ fit for such devices, but it is entirely
usable. For some 8-bit ISAs, like the Z80, it works well.

>> The other method is better compiler optimisation - the compiler may
>> perform "int8_t a, b, c; a = b + c;" using just a single 8-bit add
>> despite the integer promotions to 16-bit, because it knows the result
>> will be correct.
>
> 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.

And C99 became standard a generation ago - it's okay to use it.

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

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

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

But if ever have arrays of data that need to be efficient, using smaller
types is often faster because you get more of the data in your caches.
You generally don't need them for local variables, however.

"int" says "at least 16-bits, and a reasonably efficient local type for
calculations on the target". I'd prefer "int_fast16_t", meaning "at
least 16-bits and the most efficient local type on the target". On many
64-bit systems, this will be 64-bit in size because it can be handled
more efficiently.

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

Regardless, K&R C is as relevant as ancient Latin - great for historical
interest, but not for any real-world coding done today.

> As such - what are the ramifications of making "int" 8 bits
> on a 8080?

It would be non-standard, and break with the assumptions made by a great
proportion of C code, even C code written by people who understand the
language and its standards, and write highly portable code.

Alternatively, you could say there are no ramifications because no one
will ever program for the 8080 again.

>
> I mean - yes, I know that it violates the C90 standard, but
> after 33 years of strict adherence to it, maybe it is time for
> us to part ways.
>

Why? What part of the last 33 years of programming suggests it would be
a good idea to do something radically at odds with all standards of C,
past, present and future, and virtually all existing C code? Who would
use such a mongrel language, and what benefit would it give them?

> But not upwards to C99.
>

C99 is a /hugely/ superior language to C90. I truly hate the very rare
occasions when I have no choice but to code to C90.

> Instead, just a little bit down towards K & R 1.

That would be even worse. (And the idea is based on your incorrect
beliefs about K&R C.)

>
>> (I have also seen the use of a C++ class that holds a single 8-bit value
>> and provides arithmetic operations, as a more efficient type than int8_t
>> because it is never subject to integer promotions. A limited subset of
>> C++ can work very well on 8-bit devices.)
>
> It seems odd to not simply make int 8 bits rather than go to all
> that effort.

The C++ class can be written in a few dozen lines in standard C++, and
works with any C++ toolchain. Making int 8 bits means significant
re-writing of your compiler (especially if you want top efficiency),
libraries, and other code. The difference in effort is enormous.

> People are spending a lot of effort to type int8_t and
> use C++ at all for a reason - it's the natural word type and they
> know it. And they know that "int" isn't doing what it was
> conceptually meant to do.
>

People use C++ for many reasons, just as they use C for many reasons. I
highly doubt if many people (even gcc AVR users) use C++ simply to be
able to make such 8-bit classes.

And they use "int8_t" because that's the type they mean. I can't see a
problem with that.

> Just conjecture - not saying I'm reading the situation correctly.
>
> BFN. Paul.
>

David Brown <david.brown@hesbynett.no> writes:
>On 27/07/2023 15:00, Paul Edwards wrote:
>> On Thursday, July 27, 2023 at 7:41:40 PM UTC+8, David Brown wrote:

>> As such - what are the ramifications of making "int" 8 bits
>> on a 8080?
>
>It would be non-standard, and break with the assumptions made by a great
>proportion of C code, even C code written by people who understand the
>language and its standards, and write highly portable code.
>
>Alternatively, you could say there are no ramifications because no one
>will ever program for the 8080 again.

You haven't been following alt.os.development. Paul believes that the
8080 and 8086 is the be-all and end-all of computing. A perfect architecture
in his opinion. He believes an apocalypse will occur in the future
and the 8080 will be the only survivor.

On Thursday, July 27, 2023 at 10:15:22 PM UTC+8, Scott Lurndal wrote:

> >Alternatively, you could say there are no ramifications because no one
> >will ever program for the 8080 again.

> You haven't been following alt.os.development. Paul believes that the
> 8080 and 8086 is the be-all and end-all of computing. A perfect architecture
> in his opinion. He believes an apocalypse will occur in the future
> and the 8080 will be the only survivor.

Lie. I said no such thing. Quote what I actually said instead
of putting words into my mouth.

BFN. Paul.

On Wednesday, July 26, 2023 at 11:15:18 AM UTC-4, Paul Edwards wrote:
> On Wednesday, July 26, 2023 at 10:35:15 PM UTC+8, Ed Prochak wrote:
>
> > > Basically, what is standard C doing, and what does a C
> > > variant need to do to compete with PL/M? (with regard
> > > to promotion rule changes)
>
> > The versions of C in the mid 1980's competed with PL/M
> > and eventually won.
> Yeah - but I'm trying to compete in the 1970s on 8-bit machines.
>
> I've never attempted to program in C on an 8-bit machine.
> I wouldn't have thought that the short&int = 16-bit minimum
> would be suitable.

8bit machines often dealt with 16bit values, hence the ADC opcode.

> > > > > and at the time people started writing PL/M they instead were
> > > > > inspired by C90=C50, would C have been perfectly fine for the
> > > > > eventual task of writing the CPM-80 operating system?
>
> > Yes C would have been fine for CP/M. UNIX was eventually
> > written in C.
> Not 8-bit I think.

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.

> > Ignoring the differences, both languages are Turing complete,
> > so any program that can be written with PL/M can be written
> > in C and vice versa.
> Assuming sufficient memory. You can probably write in
> Cobol too, but not write CP/M-80 in Cobol.

I know of one operating system that was written in COBOL.
One of the developers is a close friend of mine. So even
COBOL can be used. Not necessarily the best choice, but
sometimes there are other constraints on which tools you
are allowed to use.

And yes I still say that is doable, though not necessarily
easy, nor will it execute as fast on an 8bit processor as
a flavor developed with PL/M or C.

> > > Starting in 1960, I would like a C90-inspired language that will
> > > cover the development of all OSes on all platforms. I know it
> > > is possible to write a mainframe OS in C90 (that's what I did
> > > with z/PDOS). With some assembler routines to be called from
> > > C of course. So IBM could have used C instead of PL/S and
> > > assembler on the S/360 line.
>
> > Why would they? PL/S had features that IBM wanted that made the
> > development easier.
> Ok sure - if they have the ability to spend a lot of work writing
> the PL/S compiler, and runtime resources too, then fine, I'm
> sure there are productivity features you can add. Maybe even
> call it C++, who knows.

I don't get it. You just seem to think C is the be-all and end-all of
programming languages. It isn't.

And as much as you might like to have C90 in 1964, it wasn't there.

>
> I'm more interested in the fact that a lot of it was in assembler,
> not PL/S, and I don't think it needed to be. E.g. the assembler
> (IFOX) itself is written in assembler. I think "SORT" too - and
> it's massive.

In the 1960's assembler was still a major programming language
for operating systems programming.

> > This "use C for any OS" mantra is nice, but
> > not useful. There are still parts that have to be written in assembly.
> I'm not disputing that there are parts that there is no choice
> but to write in assembly.
>
> My discussion is only about the parts where you have a
> choice.
>
> I don't mind if it is slower to write in C than PL/S - and
> this would be me writing my own OS - I don't control IBM.
>
> I want to (belatedly) compete with IBM, and Microsoft,
> and now DRI on the 8080. I actually went into writing
> PDOS/86 blind, and z/PDOS blind too. And although
> I have programmed in assembler on a 6502, I've
> never programmed on the 8080 at all, or any 8-bit
> machine in C, and so I'm still blind there.

Well, programming in the constraints of an 8bit processor
can be an enlightening experience. You'd be amazed how
much can really be done.
>
> Up until recently I thought you needed to program in
> assembler on an 8-bit machine if you wanted to write
> an OS, for space reasons. And then I found that the
> first OS of note for micros wasn't even written in
> assembler! Again - I wasn't aware this was possible.
>
> PDOS/86 takes up an entire 360k floppy disk. Just a
> minimal OS. There is no fat to cut out. How you can
> fit that into 64k and still leave room for apps - well,
> beats me. Especially if C90 forces int to 16 bits. And
> can you even code sensibly if ints were 8 bits (which
> is not even allowed)?

The 8086 can address up to 1MB of RAM of which
640K was usable in MS DOS. (Refer to Bill Gates famous
quote about 640K!) So 360KB for PDOS/86 uses only
half of available memory.

>
> No idea - like I said, I'm starting this blind.

> > So I think the bottom line answer to your question is:
> > Sure, CP/M can be written in C. And if you want to
> > use C90 or better, go for it.
> Ok - thanks. I guess what I can do is start with the CP/M
> API, since that's what I know is possible, write an OS in C
> and run it through an 8080 compiler and see what happens.
> Again - starting blind - I'm not sure what to expect.
>
> BFN. Paul.

If you are doing PDOS/86, then you might want to find a C
compiler to target that flavor of Intel processor. Intel made
the 8086 compatible with the 8080 instruction set but added
the larger memory space and some other enhancements
(a PUSH ALL instruction, which is VERY useful).

If you have questions about the 8086 and 80186, email me. I have
the datasheet somewhere on my bookshelves.

You've got yourself a nice challenge.
Ed
I'm on gmail as edprochak.

On Saturday, July 29, 2023 at 5:32:13 AM UTC+8, Ed Prochak wrote:

> > > The versions of C in the mid 1980's competed with PL/M
> > > and eventually won.

> > Yeah - but I'm trying to compete in the 1970s on 8-bit machines.
> >
> > I've never attempted to program in C on an 8-bit machine.
> > I wouldn't have thought that the short&int = 16-bit minimum
> > would be suitable.

> 8bit machines often dealt with 16bit values, hence the ADC opcode.

Sure. And that could possibly be "long".

> > > > > > and at the time people started writing PL/M they instead were
> > > > > > inspired by C90=C50, would C have been perfectly fine for the
> > > > > > eventual task of writing the CPM-80 operating system?
> >
> > > Yes C would have been fine for CP/M. UNIX was eventually
> > > written in C.
> > Not 8-bit I think.

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

Again - I am surprised this can be fit into 64k.

> > > Ignoring the differences, both languages are Turing complete,
> > > so any program that can be written with PL/M can be written
> > > in C and vice versa.

> > Assuming sufficient memory. You can probably write in
> > Cobol too, but not write CP/M-80 in Cobol.

> I know of one operating system that was written in COBOL.
> One of the developers is a close friend of mine. So even
> COBOL can be used. Not necessarily the best choice, but
> sometimes there are other constraints on which tools you
> are allowed to use.
>
> And yes I still say that is doable, though not necessarily
> easy, nor will it execute as fast on an 8bit processor as
> a flavor developed with PL/M or C.

Ok.

> > > > Starting in 1960, I would like a C90-inspired language that will
> > > > cover the development of all OSes on all platforms. I know it
> > > > is possible to write a mainframe OS in C90 (that's what I did
> > > > with z/PDOS). With some assembler routines to be called from
> > > > C of course. So IBM could have used C instead of PL/S and
> > > > assembler on the S/360 line.
> >
> > > Why would they? PL/S had features that IBM wanted that made the
> > > development easier.

> > Ok sure - if they have the ability to spend a lot of work writing
> > the PL/S compiler, and runtime resources too, then fine, I'm
> > sure there are productivity features you can add. Maybe even
> > call it C++, who knows.

> I don't get it. You just seem to think C is the be-all and end-all of
> programming languages. It isn't.

I'm not really claiming that. I'm not a language expert.
It's just the language I happen to know, and I'm trying
to find its limits, and seeing what historical hardware
can be covered by it.

> And as much as you might like to have C90 in 1964, it wasn't there.

And 2023 wasn't in the 1960s at all. So what? My question
isn't dependent on what happened historically software-wise.

It is dependent on hardware capabilities though.

> > I'm more interested in the fact that a lot of it was in assembler,
> > not PL/S, and I don't think it needed to be. E.g. the assembler
> > (IFOX) itself is written in assembler. I think "SORT" too - and
> > it's massive.

> In the 1960's assembler was still a major programming language
> for operating systems programming.

But it didn't need to be. If we had our time again, we would
have whipped out a C90 compiler as quickly as possible.
Perhaps?

> > > This "use C for any OS" mantra is nice, but
> > > not useful. There are still parts that have to be written in assembly..
> > I'm not disputing that there are parts that there is no choice
> > but to write in assembly.
> >
> > My discussion is only about the parts where you have a
> > choice.
> >
> > I don't mind if it is slower to write in C than PL/S - and
> > this would be me writing my own OS - I don't control IBM.
> >
> > I want to (belatedly) compete with IBM, and Microsoft,
> > and now DRI on the 8080. I actually went into writing
> > PDOS/86 blind, and z/PDOS blind too. And although
> > I have programmed in assembler on a 6502, I've
> > never programmed on the 8080 at all, or any 8-bit
> > machine in C, and so I'm still blind there.

> Well, programming in the constraints of an 8bit processor
> can be an enlightening experience. You'd be amazed how
> much can really be done.

Sure. That's what I'm gearing up to do.

> > Up until recently I thought you needed to program in
> > assembler on an 8-bit machine if you wanted to write
> > an OS, for space reasons. And then I found that the
> > first OS of note for micros wasn't even written in
> > assembler! Again - I wasn't aware this was possible.
> >
> > PDOS/86 takes up an entire 360k floppy disk. Just a
> > minimal OS. There is no fat to cut out. How you can
> > fit that into 64k and still leave room for apps - well,
> > beats me. Especially if C90 forces int to 16 bits. And
> > can you even code sensibly if ints were 8 bits (which
> > is not even allowed)?

> The 8086 can address up to 1MB of RAM of which
> 640K was usable in MS DOS. (Refer to Bill Gates famous
> quote about 640K!) So 360KB for PDOS/86 uses only
> half of available memory.

There is data as well, and also a conceptually simple
design "requires" the loader and OS to be at fixed
locations, so that chews up some space.

Once the OS is loaded it is flexible, but by then it's too late.

And then to spawn another program using C90, system()
is used, which loads another copy of command.com, so
there's almost nothing left.

Yes, you can use some tricks to reduce space, but I don't
want to take away the design simplicity, so my solution
is to switch to the 80286 so that I have 2 MB. I haven't
done that yet though.

> > > So I think the bottom line answer to your question is:
> > > Sure, CP/M can be written in C. And if you want to
> > > use C90 or better, go for it.

> > Ok - thanks. I guess what I can do is start with the CP/M
> > API, since that's what I know is possible, write an OS in C
> > and run it through an 8080 compiler and see what happens.
> > Again - starting blind - I'm not sure what to expect.
> >
> If you are doing PDOS/86, then you might want to find a C
> compiler to target that flavor of Intel processor. Intel made
> the 8086 compatible with the 8080 instruction set but added
> the larger memory space and some other enhancements
> (a PUSH ALL instruction, which is VERY useful).

Pardon? PDOS/86 has already been done, and it is already
written mostly in C, and I already have several C compilers
capable of producing 8086 code, although only 2 (that I
have encountered to date) can produce the huge memory
model I use (again, for simplicity).

> If you have questions about the 8086 and 80186, email me. I have
> the datasheet somewhere on my bookshelves.
>
> You've got yourself a nice challenge.

The 8086 challenge is already done. 80286 and 8080
haven't been done. x64 has only been done to proof of
concept.

BFN. Paul.

On 26/07/2023 16:15, Paul Edwards wrote:

> Up until recently I thought you needed to program in
> assembler on an 8-bit machine if you wanted to write
> an OS, for space reasons. And then I found that the
> first OS of note for micros wasn't even written in
> assembler! Again - I wasn't aware this was possible.
>
> PDOS/86 takes up an entire 360k floppy disk. Just a
> minimal OS. There is no fat to cut out. How you can
> fit that into 64k and still leave room for apps - well,

Are you talking about 8080 here or 8086?

As for the 360KB, does all the code on the disk need to be resident in
memory at the same time?

From what I remember of those primitives OSes, they basically just had
to provide a file system for running applications to use.

That could be done in a few KB. I used to write boot loaders that could
read disk sectors in a few hundred bytes, and reading a simple disk
format like FAT is trivial.

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.

When you're programming on an x64 how often do you
code int8_t? 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.

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

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

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

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.

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.

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.

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

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

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.

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

That was an incorrect assumption.

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

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

The Israelis revived Hebrew too, right?

There may be a circumstance where an allegedly dead language
unexpectedly comes alive.

E.g. I decide to lock my daughter up in a basement with
just access to UC386. Or she locks me up. If that happens
as of today you don't even get C90. You get the SubC
subset. There are people working on changing that situation
but it's an awfully slow process regardless of how many people
(who aren't doing the work) say how "easy" it is.

There is an OS called "Collapse OS" written on the belief
that supply systems are going to collapse. This was
pre-Covid too.

The next virus may only leave 1% of the population alive.

> > As such - what are the ramifications of making "int" 8 bits
> > on a 8080?

> It would be non-standard, and break with the assumptions made by a great
> proportion of C code, even C code written by people who understand the
> language and its standards, and write highly portable code.

And could that code be rewritten to be portable within
the "new" non-standard rules?

> Alternatively, you could say there are no ramifications because no one
> will ever program for the 8080 again.

That's not true. That's the entire basis of this thread. I am
gearing up to program on the 8080 unless I believe it is not
possible (which is what I previously believed).

Am I the only person doing that? In the last 2 weeks I have
spoken to 2 people who are interested in running CP/M-80.

That's not them personally programming on the 8080
though.

> > I mean - yes, I know that it violates the C90 standard, but
> > after 33 years of strict adherence to it, maybe it is time for
> > us to part ways.
> >
> Why? What part of the last 33 years of programming suggests it would be
> a good idea to do something radically at odds with all standards of C,
> past, present and future, and virtually all existing C code? Who would
> use such a mongrel language, and what benefit would it give them?

I would use it if I thought it was wise to do so.

The benefit would be PDOS-generic (as opposed to
PDOS/x86) running on 8-bit to 64-bit machines with
common source code. Not even conditional compilation.

And it's not "the last 33 years of programming" - it's what
was missed in the 1970s because PL/M was used instead
of C.

I missed it (even though I was alive) both because I was too
young to have a computer and because since then I have
had other priorities. It was only a few years ago that I even
realized that I should have written PDOS/86 using the huge
memory model, and only a few weeks ago (I think) that I
completed that model.

> > But not upwards to C99.
> >
> C99 is a /hugely/ superior language to C90. I truly hate the very rare
> occasions when I have no choice but to code to C90.

And C90 is hugely superior to SubC, and I'm still waiting
for that gap to be closed.

My question is not about what YOU should use - I did not
comment on that. Nor did I comment on which language
was "best" for any particular purpose at all.

> > Instead, just a little bit down towards K & R 1.

> That would be even worse. (And the idea is based on your incorrect
> beliefs about K&R C.)

I don't think it is me who is incorrect about K & R C 1.

> >> (I have also seen the use of a C++ class that holds a single 8-bit value
> >> and provides arithmetic operations, as a more efficient type than int8_t
> >> because it is never subject to integer promotions. A limited subset of
> >> C++ can work very well on 8-bit devices.)
> >
> > It seems odd to not simply make int 8 bits rather than go to all
> > that effort.

> The C++ class can be written in a few dozen lines in standard C++, and
> works with any C++ toolchain. Making int 8 bits means significant
> re-writing of your compiler (especially if you want top efficiency),
> libraries, and other code. The difference in effort is enormous.

Writing an application, writing an OS, and writing a compiler
are independent tasks.

I don't expect a person writing an application to do the
toolchain rewrite.

If it makes sense - and I don't have a solid opinion yet - then
I will potentially organize the toolchain modifications such
that when the application programmer referred to above
needs to make a decision on which way to jump, "significant
rewriting of your compiler" is not a factor.

On Saturday, July 29, 2023 at 8:04:30 AM UTC+8, Bart wrote:

> > PDOS/86 takes up an entire 360k floppy disk. Just a
> > minimal OS. There is no fat to cut out. How you can
> > fit that into 64k and still leave room for apps - well,

> Are you talking about 8080 here or 8086?

8086.

> As for the 360KB, does all the code on the disk need to be resident in
> memory at the same time?

Using my conceptually simple (and hopefully understandable)
design, yes.

> From what I remember of those primitives OSes, they basically just had
> to provide a file system for running applications to use.
>
> That could be done in a few KB. I used to write boot loaders that could
> read disk sectors in a few hundred bytes, and reading a simple disk
> format like FAT is trivial.

"trivial" is relative.

I've personally written FAT-12 and FAT-16 reading. It took years
before I finally managed to get writing done (just wondering
how to do it). I never got FAT-12 writing to work (didn't know
how to do it).

Someone else came along and added FAT-12 writing and
FAT-32 reading and writing, and they did it quickly as far as
I know.

I asked that same person (Alica from Slovakia) why they
didn't write their own OS and she said she had tried but
didn't know how to start.

So different people have different skills.

I tried to hire a group of budding computing friends who
turned up to a group to fix a bug in the FAT code.

They were excited at first, but they eventually decided
they couldn't do it. I suspect they were traumatized by
the experience.

So yeah, not everyone is a brainbox who finds this
stuff "trivial" to do. As for a few k, all the FAT code
(including LFN) is 3844 lines long and compiles to
this 8086 object code:

2023-07-29 08:22 56,783 fat.obj

almost blowing away the entire 64k possible in an
8-bit system, nevermind the smaller memory
footprints I believe CP/M could handle (MSDOS
1.0 certainly could).

BFN. Paul.

On 29/07/2023 01: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.
>
> When you're programming on an x64 how often do you
> code int8_t?

I'm astonished that you're asking such a question. I'd assumed you were
a programmer with decades of experience, and you're asking when you
would ever use a Byte type instead of an Int?

(Presumably your String types have been sequences of (Ints rather than
Bytes?)

But the answer to your question is: when defining discrete variables,
you use Int; when creating data structures with arrays and structs, you
will consider narrow types to minimise memory reqirements or to match
external requirements.

Memory is important now because it is so slow to access; and it was
important then because there was so little of it!

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

That would be a very poor calculator, useless actually. You can do far
better with 8080.

BTW why the obsession with 8080? A far superior superset was Z80.

It was easier to use: single supply voltage instead of three; simple,
square wave clock, higher clock speeds that didn't need a quartz crystal ...

You didn't need an array of special (and expensive) Intel support chips
either. (I don't know if there have been better 8080s since then.)

Plus more registers and more instructions.

On Z80, I used 8-byte bytes, 16-byte ints and 32-bit floats (emulated in
software). That would make for a nice little calculator.

> That's not true. That's the entire basis of this thread. I am
> gearing up to program on the 8080 unless I believe it is not
> possible (which is what I previously believed).

Go for Z80; the chances are there will be more of those about after an
apocalypse than 8080.

> And it's not "the last 33 years of programming" - it's what
> was missed in the 1970s because PL/M was used instead
> of C.

Why you regard C so highly even though it leaves so many things
open-ended? To me PL/M seems much better suited to the requirements of
the time!

> BTW why the obsession with 8080? A far superior superset was Z80.

His obsession is around the fact that he just bought a notebook computer with an NEC V20 chip, which has 8080 emulation.

Joe

On Friday, July 28, 2023 at 7:29:54 PM UTC-4, Paul Edwards wrote:
> On Saturday, July 29, 2023 at 5:32:13 AM UTC+8, Ed Prochak wrote:
>
> > > > The versions of C in the mid 1980's competed with PL/M
> > > > and eventually won.
>
> > > Yeah - but I'm trying to compete in the 1970s on 8-bit machines.
> > >
> > > I've never attempted to program in C on an 8-bit machine.
> > > I wouldn't have thought that the short&int = 16-bit minimum
> > > would be suitable.
>
> > 8bit machines often dealt with 16bit values, hence the ADC opcode.
> Sure. And that could possibly be "long".
> > > > > > > and at the time people started writing PL/M they instead were
> > > > > > > inspired by C90=C50, would C have been perfectly fine for the
> > > > > > > eventual task of writing the CPM-80 operating system?
> > >
> > > > Yes C would have been fine for CP/M. UNIX was eventually
> > > > written in C.
> > > Not 8-bit I think.
>
> > 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.
> Again - I am surprised this can be fit into 64k.

At first I was going to hold out GEOS for the Commadore64
as an example of a nearly modern GUI Operating system
that fits in 64K. But we were talking Unix, SO...

....I did a little digging. According to gunkies.org
https://gunkies.org/wiki/UNIX_First_Edition
"The UNIX First Edition (V1) occurred when UNIX was
re-written for the then-new PDP-11, a 'cheap' minicomputer,
from the PDP-7 for which it was originally written, at Bell
Laboratories."

Both the PDP-7 and PDP-11/20 (the first PDP-11 model)
came with 4K-words (8kbytes) of core memory.

64Kbytes leaves lots of room.

[snip the COBOL sidebar]
> > > > > Starting in 1960, I would like a C90-inspired language that will
> > > > > cover the development of all OSes on all platforms. I know it
> > > > > is possible to write a mainframe OS in C90 (that's what I did
> > > > > with z/PDOS). With some assembler routines to be called from
> > > > > C of course. So IBM could have used C instead of PL/S and
> > > > > assembler on the S/360 line.
> > >
> > > > Why would they? PL/S had features that IBM wanted that made the
> > > > development easier.
>
> > > Ok sure - if they have the ability to spend a lot of work writing
> > > the PL/S compiler, and runtime resources too, then fine, I'm
> > > sure there are productivity features you can add. Maybe even
> > > call it C++, who knows.
>
> > I don't get it. You just seem to think C is the be-all and end-all of
> > programming languages. It isn't.
> I'm not really claiming that. I'm not a language expert.
> It's just the language I happen to know, and I'm trying
> to find its limits, and seeing what historical hardware
> can be covered by it.

Well you will need to gain some understanding of programming
language features and architecture. What may seem to be simple
differences can have significant effects on performance and
usability.

Looking at your other posts I now understand that you want a
couple of things--
ONE: a C standard language that is usable from what I'll call
server/mainframe class processors (64bit)
down to
utility class processors (8bit).
Note: glad to see you are not asking to include 4 bit processors!

TWO: the ability to write an Operating system in that standard
C language that is portable from utility class to server class
hardware.

Sorry but you hit a key limit of the C language. I doubt ANY
language can meet both of those goals at the same time.

Just consider GNU/LINUX. Even though the LINUX kernel
is is available on many processors and platforms, these
are all a minimum of 32bit processors. And the source code
is not portable in the sense that it had compile conditionals
to modify the code as needed for the target hardware.

> > And as much as you might like to have C90 in 1964, it wasn't there.
> And 2023 wasn't in the 1960s at all. So what? My question
> isn't dependent on what happened historically software-wise.
>
Yes it is dependent on the historical changes.
There had been a LOT of changes in software design and languages
even in the 30 years from 1960 to 1990. Critical sections and
semaphores were just being defined in the early 1960s. These
are key to multitasking Operating Systems.

> It is dependent on hardware capabilities though.

As I mentioned above, your goal may not be possible.

> > > I'm more interested in the fact that a lot of it was in assembler,
> > > not PL/S, and I don't think it needed to be. E.g. the assembler
> > > (IFOX) itself is written in assembler. I think "SORT" too - and
> > > it's massive.
>
> > In the 1960's assembler was still a major programming language
> > for operating systems programming.
> But it didn't need to be. If we had our time again, we would
> have whipped out a C90 compiler as quickly as possible.
> Perhaps?

Again, you are ignoring the historical context.
By your reasoning, the ancients should have been able to
move directly from bronze to stainless steel.
Progress just doesn't happen that way.

> > > > This "use C for any OS" mantra is nice, but
> > > > not useful. There are still parts that have to be written in assembly.
> > > I'm not disputing that there are parts that there is no choice
> > > but to write in assembly.
> > >
> > > My discussion is only about the parts where you have a
> > > choice.
> > >
> > > I don't mind if it is slower to write in C than PL/S - and
> > > this would be me writing my own OS - I don't control IBM.
> > >
> > > I want to (belatedly) compete with IBM, and Microsoft,
> > > and now DRI on the 8080. I actually went into writing
> > > PDOS/86 blind, and z/PDOS blind too. And although
> > > I have programmed in assembler on a 6502, I've
> > > never programmed on the 8080 at all, or any 8-bit
> > > machine in C, and so I'm still blind there.
>
May I ask, are you skilled in assembly language?
For which processors?

It should not be a big step from 6502 to 8080 assembler.
On the 6502 did you program at the low level, bare hardware?
Or within a defined environment (like a commadore64)?

> > Well, programming in the constraints of an 8bit processor
> > can be an enlightening experience. You'd be amazed how
> > much can really be done.
> Sure. That's what I'm gearing up to do.
Cheers!

> > > Up until recently I thought you needed to program in
> > > assembler on an 8-bit machine if you wanted to write
> > > an OS, for space reasons. And then I found that the
> > > first OS of note for micros wasn't even written in
> > > assembler! Again - I wasn't aware this was possible.
> > >
> > > PDOS/86 takes up an entire 360k floppy disk. Just a
> > > minimal OS. There is no fat to cut out. How you can
> > > fit that into 64k and still leave room for apps - well,
> > > beats me. Especially if C90 forces int to 16 bits. And
> > > can you even code sensibly if ints were 8 bits (which
> > > is not even allowed)?
>
> > The 8086 can address up to 1MB of RAM of which
> > 640K was usable in MS DOS. (Refer to Bill Gates famous
> > quote about 640K!) So 360KB for PDOS/86 uses only
> > half of available memory.
> There is data as well, and also a conceptually simple
> design "requires" the loader and OS to be at fixed
> locations, so that chews up some space.
>
> Once the OS is loaded it is flexible, but by then it's too late.
>
> And then to spawn another program using C90, system()
> is used, which loads another copy of command.com, so
> there's almost nothing left.

It begins with how much you started with.
As noted above original UNIX ran in 8KB (4K of 16bit words)
>
> Yes, you can use some tricks to reduce space, but I don't
> want to take away the design simplicity, so my solution
> is to switch to the 80286 so that I have 2 MB. I haven't
> done that yet though.

So which target are you programming for, 8bit or 32 bit?

> > > > So I think the bottom line answer to your question is:
> > > > Sure, CP/M can be written in C. And if you want to
> > > > use C90 or better, go for it.
>
> > > Ok - thanks. I guess what I can do is start with the CP/M
> > > API, since that's what I know is possible, write an OS in C
> > > and run it through an 8080 compiler and see what happens.
> > > Again - starting blind - I'm not sure what to expect.
> > >
> > If you are doing PDOS/86, then you might want to find a C
> > compiler to target that flavor of Intel processor. Intel made
> > the 8086 compatible with the 8080 instruction set but added
> > the larger memory space and some other enhancements
> > (a PUSH ALL instruction, which is VERY useful).
> Pardon? PDOS/86 has already been done, and it is already
> written mostly in C, and I already have several C compilers
> capable of producing 8086 code, although only 2 (that I
> have encountered to date) can produce the huge memory
> model I use (again, for simplicity).

On Friday, July 28, 2023 at 8:28:29 PM UTC-4, Paul Edwards wrote:
[]
> So yeah, not everyone is a brainbox who finds this
> stuff "trivial" to do. As for a few k, all the FAT code
> (including LFN) is 3844 lines long and compiles to
> this 8086 object code:
>
> 2023-07-29 08:22 56,783 fat.obj
>
> almost blowing away the entire 64k possible in an
> 8-bit system, nevermind the smaller memory
> footprints I believe CP/M could handle (MSDOS
> 1.0 certainly could).
>
> BFN. Paul.

Okay. I am trying to make sure I don't offend you here,
but
you do know that the OBJ file contains more than the
executable code and that even the code it contains
may not be in binary format,
RIGHT?

Ed

Ed Prochak <edprochak@gmail.com> wrote:
> As noted above original UNIX ran in 8KB (4K of 16bit words)

No it didn't, and IMO it couldn't have done. It ran in 24k, and at
that time it was mostly still written in assembly language.

https://www.bell-labs.com/usr/dmr/www/1stEdman.html

Andrew.

> > As noted above original UNIX ran in 8KB (4K of 16bit words)
> No it didn't, and IMO it couldn't have done. It ran in 24k, and at
> that time it was mostly still written in assembly language.
>

"The UNIX Time-Sharing System

D. M. Ritchie"

"The PDP-11 on which UNIX is implemented is a 16-bit 12K computer,
and UNIX occupies 8K words. More than half of this space,
however, is utilized for a variable number of disk buffers; with
some loss of speed the number of buffers could be cut significantly."

https://www.tuhs.org/Archive/Distributions/Research/McIlroy_v0/UnixEditionZero.txt

Joe

On 28/07/2023 00:37, Paul Edwards wrote:
> On Thursday, July 27, 2023 at 10:15:22 PM UTC+8, Scott Lurndal wrote:
>
>>> Alternatively, you could say there are no ramifications because no one
>>> will ever program for the 8080 again.
>
>> You haven't been following alt.os.development. Paul believes that the
>> 8080 and 8086 is the be-all and end-all of computing. A perfect architecture
>> in his opinion. He believes an apocalypse will occur in the future
>> and the 8080 will be the only survivor.
>
> Lie. I said no such thing. Quote what I actually said instead
> of putting words into my mouth.
>
> BFN. Paul.

I haven't been following alt.os.development, and I have no intention of
doing so. But giving the correct quotation would read better than an
insult, whether or not it is justified.

(And BTW, as someone who spent decades making a living out of 8080 and
its successors - I didn't like any of them)

Andy

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.

<snip>
>> I'm more interested in the fact that a lot of it was in assembler,
>> not PL/S, and I don't think it needed to be. E.g. the assembler
>> (IFOX) itself is written in assembler. I think "SORT" too - and
>> it's massive.
> In the 1960's assembler was still a major programming language
> for operating systems programming.
>

Later than that. ICL's VME/K wasn't cancelled until the beginning of the
80s - and it was entirely written in assembler. Unlike VME/B.

Andy

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

Sorry for the delay - I was sick - possibly Covid as it had
symptoms I wasn't used to - plus had some other priorities.

> Looking at your other posts I now understand that you want a
> couple of things--
> ONE: a C standard language that is usable from what I'll call
> server/mainframe class processors (64bit)
> down to
> utility class processors (8bit).
> Note: glad to see you are not asking to include 4 bit processors!
>
> TWO: the ability to write an Operating system in that standard
> C language that is portable from utility class to server class
> hardware.
>
> Sorry but you hit a key limit of the C language. I doubt ANY
> language can meet both of those goals at the same time.

That's what I'm trying to understand.

Note that I have 16-bit to 64-bit already done.

I didn't notice any limitation in the language.

> Just consider GNU/LINUX. Even though the LINUX kernel
> is is available on many processors and platforms, these
> are all a minimum of 32bit processors. And the source code
> is not portable in the sense that it had compile conditionals
> to modify the code as needed for the target hardware.

They probably aren't using the PDOS-generic model
which is what I am now using.

> May I ask, are you skilled in assembly language?
> For which processors?

I know/used 6502, x86 and S/370 assembler.

I'm not claiming to be an expert. I program almost
exclusively in C90.

> On the 6502 did you program at the low level, bare hardware?
> Or within a defined environment (like a commadore64)?

On the C64.

> > Yes, you can use some tricks to reduce space, but I don't
> > want to take away the design simplicity, so my solution
> > is to switch to the 80286 so that I have 2 MB. I haven't
> > done that yet though.

> So which target are you programming for, 8bit or 32 bit?

The 80286 is 16-bit register size.

But right at the moment I have switched to 64-bit because
someone contributed some 64-bit code and I am utilizing
that as priority.

BFN. Paul.

On Monday, July 31, 2023 at 12:12:09 PM UTC+8, Ed Prochak wrote:

> Okay. I am trying to make sure I don't offend you here,
> but
> you do know that the OBJ file contains more than the
> executable code and that even the code it contains
> may not be in binary format,
> RIGHT?

Yes, I know that, but it's mostly binary code and
here is the fat code in the PDOS/86 kernel:

fat_TEXT CODE AUTO 33f2:0000 0000b222

45602 bytes. Compiled with Open Watcom.

I checked the disassembly - it is all legitimate code.

It could be the price of the huge memory model, which I
wouldn't encounter on the 8080.

BFN. Paul.

On Wednesday, August 2, 2023 at 6:03:47 AM UTC+8, David Brown wrote:

> Portable to what? It is extremely rare to have to make code portable to
> /any/ architecture with a C implementation.

It's not "have to", it's "want to". I didn't "have to" write
PDOS at all. Well, there could be room for a semantic
debate there, but I'm not interested in that.

> > And C90 is hugely superior to SubC, and I'm still waiting
> > for that gap to be closed.
> >
> I have no idea what "SubC" might be. But if someone says lasagne makes
> a nicer diner than plain bread, saying plain bread is nicer than eating
> rocks does not count as a reason for turning down the lasagne.

There is no public domain lasagne. Just public domain rocks.

> > Writing an application, writing an OS, and writing a compiler
> > are independent tasks.
> >
> And each is perhaps 5 orders of magnitude more effort than writing a
> little C++ class.

And I am doing the OS task above, and someone else is
doing the compiler task above.

> You have doubts that when people write "int8_t", they mean "an eight bit
> signed integer type" ?

I have doubts that that translates to a business requirement
or a logical need.

BFN. Paul.