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.

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

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

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

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

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

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.

Paul Edwards <mutazilah@gmail.com> writes:
>On Wednesday, July 26, 2023 at 10:35:15=E2=80=AFPM UTC+8, Ed Prochak wrote:

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

Actually, there is no reason that CP/M-80 cannot be written
in COBOL. I worked with a COBOL compiler that allowed
in-line assembler several decades ago, before CP/M even existed.

On Wed, 26 Jul 2023 15:24:38 +0000, Scott Lurndal wrote:

> Paul Edwards <mutazilah@gmail.com> writes:
>>On Wednesday, July 26, 2023 at 10:35:15=E2=80=AFPM UTC+8, Ed Prochak wrote:
>
>>> Ignoring the differences, both languages are Turing complete,=20
>>> so any program that can be written with PL/M can be written=20
>>> in C and vice versa.
>>
>>Assuming sufficient memory. You can probably write in
>>Cobol too, but not write CP/M-80 in Cobol.
>
> Actually, there is no reason that CP/M-80 cannot be written
> in COBOL. I worked with a COBOL compiler that allowed
> in-line assembler several decades ago, before CP/M even existed.

Two factoids, for what they are worth...

First, long ago, I worked on a communications protocol package entirely
written in COBOL. While COBOL may be wordy to write, it /can/
perform complex low-level functions in (depending on the compiler)
a reduced executable footprint.

Second, the GNU COBOL compiler translates COBOL into C, then invokes
the GNU C compiler to generate the executable code. So, for at least
one COBOL compiler, the end result /is/ C code.

--
Lew Pitcher
"In Skills We Trust"

On Wed, 26 Jul 2023 07:49:38 -0700 (PDT)
Ed Prochak <edprochak@gmail.com> wrote:
> Except watch out, those error messages can quickly
> be confusing.
>
> Here's an example from my experience:
> Source code has structures but no code of the style:
> structureB = structureA;
>
> yet the C cross compiler produces the error message:
> "Structure assignments not available."
>
> After much consternation and discussions with the
> compiler writers, we learned the error referred to a
> function call:
> funcA(..., structureA, ...);
> which should have been:
> funcA(..., &structureA, ...);

Didn't the error message mention line number ?

> (This was just a chance for me to vent one of my
> pet peeves that error messages are often written
> from the view of the developer, not of the end user.
> But it is the end user that has to understand them!)

Paul Edwards <mutazilah@gmail.com> writes:

> And in fact, C evolved through BPCL and B too.

BCPL: mid 1960s, first published 1967. The date of B is a little later,
maybe 1970.

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

I'm not sure what "starting in 1960" refers to. It can't refer to BCPL
or B and certainly not C. C started out as "new B" in about 1971 but
was only really something we'd call C by about 1974.

The 360 series was developed in the early 1960s (first sold in 1965) so
so "IBM could have used C" is an odd thing to say. Some later versions
in C (like C90) were technically suitable, but the job had already been
done.

--
Ben.

On Thursday, July 27, 2023 at 3:24:24 AM UTC+8, Ben Bacarisse wrote:

> I'm not sure what "starting in 1960" refers to. It can't refer to BCPL
> or B and certainly not C. C started out as "new B" in about 1971 but
> was only really something we'd call C by about 1974.
>
> The 360 series was developed in the early 1960s (first sold in 1965) so
> so "IBM could have used C" is an odd thing to say. Some later versions
> in C (like C90) were technically suitable, but the job had already been
> done.

Yeah, it's more a question of "if we had our time again".

I have basically spent my life probing systems from the safety
of a C90 compiler. Forcing the mountain to come to Mohammad
I guess.

And with an underlying assumption that the C90 people knew
what they were doing. In fact, ISO actually delayed ANSI's
release by a year or something because they were going to
reject it otherwise. ANSI added a locale system and that was
apparently good enough for it to be adopted unchanged
(although I have no idea why they felt the need to change
the section numbers).

Anyway, now that I have a V20 chip in a new computer (a
Book 8088), I can now probe the 8080. I've been vlogging
about that at the bottom of http://pdos.org

And I'm wondering how on earth to fit 300k of code into 64k.

I could potentially eliminate the C library, but the main source
file is:

2023-07-27 07:39 62,401 pdos.obj

That's 7400 lines of C code. Built with Open Watcom. Admittedly
I am using huge memory model.

Small memory model gives:

2023-07-27 07:42 45,487 pdos.obj

In actual fact I have more-or-less given up on the 8086 as it
really only gives enough memory for PDOS/86 to load itself.

I can probably load a CP/M-80 emulator too.

But otherwise I had decided that I needed an 80286 with
2 MB of memory to do anything.

Visual C++ 1.52C gives:

2023-07-27 07:47 52,501 pdos.obj
and
2023-07-27 07:48 41,752 pdos.obj

BFN. Paul.

Paul Edwards <mutazilah@gmail.com> writes:

> On Thursday, July 27, 2023 at 3:24:24 AM UTC+8, Ben Bacarisse wrote:
>
>> I'm not sure what "starting in 1960" refers to. It can't refer to BCPL
>> or B and certainly not C. C started out as "new B" in about 1971 but
>> was only really something we'd call C by about 1974.
>>
>> The 360 series was developed in the early 1960s (first sold in 1965) so
>> so "IBM could have used C" is an odd thing to say. Some later versions
>> in C (like C90) were technically suitable, but the job had already been
>> done.
>
> Yeah, it's more a question of "if we had our time again".

Enjoy.

--
Ben.

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