CP/M-80 was written in PL/M.

Is there any technical reason why it couldn't have
been written in C90 instead (if the language had
existed at the time)?

ie does C produce code too inefficiently or not
provide the ability to do something that PL/M
provides?

I wasn't aware that these small machines could
handle being programmed in a language other
than assembler (at least for something critical
like the OS).

MSDOS wasn't written in PL/M - why not?

Thanks. Paul.

On Wed, 19 Jul 2023 15:56:16 -0700 (PDT), muta...@gmail.com wrote:

> CP/M-80 was written in PL/M.
>
> Is there any technical reason why it couldn't have been written in C90
> instead (if the language had existed at the time)?
>
> ie does C produce code too inefficiently or not provide the ability to
> do something that PL/M provides?
>
> I wasn't aware that these small machines could handle being programmed
> in a language other than assembler (at least for something critical like
> the OS).
>
> MSDOS wasn't written in PL/M - why not?
>
> Thanks. Paul.

CP/M was first released in 1974, sixteen years before C90 was finalized.
The first version of K&R C was released in 1978. PL/M was the primary
language on the mini computer Gary Kildall used to develop his OS. The
syntax and vocabulary of PL/M is very similar to C, so if you can read
one, you can figure out both.

Bob McConnell

On 19/07/2023 23:56, muta...@gmail.com wrote:
> CP/M-80 was written in PL/M.
>
> Is there any technical reason why it couldn't have
> been written in C90 instead (if the language had
> existed at the time)?
>
> ie does C produce code too inefficiently or not
> provide the ability to do something that PL/M
> provides?

What year was it written?

My company wrote a CP/M clone, they did so using Z80 assembly (this was
around 1982). One constraint was that the OS had to operate within 4-8KB
of memory.

I'd imagine that C compilers of that time, especially for 8080, were not
that sophisticated nor did they optimise. (They would have taken ages to
develop with too; maybe PL/M was simpler and faster to work with.)

BTW which CP/M are we talking about? I can find sources for CP/M 1, 2
and 3, which appear to mix ASM and PL/M. The PL/M looks surprisingly good.

I didn't use it myself, but had used another machine-oriented language.
It was simpler and lower-level than C, if you can imagine that, but was
definitely not assembly.

A C compiler now for those devices, run as a cross-compiler on a modern
PC, would likely do a better job.

On Thursday, July 20, 2023 at 8:42:33 AM UTC+8, Bart wrote:

> > ie does C produce code too inefficiently or not
> > provide the ability to do something that PL/M
> > provides?

> What year was it written?

1974 or something.

> My company wrote a CP/M clone, they did so using Z80 assembly (this was
> around 1982). One constraint was that the OS had to operate within 4-8KB
> of memory.

Yeah - this is what I expected - assembler as the only choice.

> I'd imagine that C compilers of that time, especially for 8080, were not
> that sophisticated nor did they optimise. (They would have taken ages to
> develop with too; maybe PL/M was simpler and faster to work with.)

How did PL/M achieve either of these things?

> BTW which CP/M are we talking about? I can find sources for CP/M 1, 2
> and 3, which appear to mix ASM and PL/M. The PL/M looks surprisingly good..

1 I guess. I just looked at a little bit of one of them and confirmed
that it was in a high level language that looked similar to PL/1.

> I didn't use it myself, but had used another machine-oriented language.
> It was simpler and lower-level than C, if you can imagine that, but was
> definitely not assembly.

That's exactly the problem - I can't imagine that.

> A C compiler now for those devices, run as a cross-compiler on a modern
> PC, would likely do a better job.

I see. Ok, so the problem has been solved.

But if C had been invented at the same time as PL/M and
had the same amount of effort put into it, would it have
always been the equal of PL/M?

Or is there something special about PL/M?

Thanks. Paul.

On 20/07/2023 09:24, Paul Edwards wrote:
> On Thursday, July 20, 2023 at 8:42:33 AM UTC+8, Bart wrote:
>
>>> ie does C produce code too inefficiently or not
>>> provide the ability to do something that PL/M
>>> provides?
>
>> What year was it written?
>
> 1974 or something.
>
>> My company wrote a CP/M clone, they did so using Z80 assembly (this was
>> around 1982). One constraint was that the OS had to operate within 4-8KB
>> of memory.
>
> Yeah - this is what I expected - assembler as the only choice.
>
>> I'd imagine that C compilers of that time, especially for 8080, were not
>> that sophisticated nor did they optimise. (They would have taken ages to
>> develop with too; maybe PL/M was simpler and faster to work with.)
>
> How did PL/M achieve either of these things?

The implementations used a mix of PL/M and assembly. Some CP/M routines
would have been independent programs, not resident, so less pressure on
space.

And if it was in 1974, probably they used a cross-compiler; I don't
know. But at that time, it sounds unlikely there was even a C
cross-compiler, for these early microprocessors. The ones from nearly a
decade later seemed bad enough.

The 'M' in PL/M means the language was specially designed for
microprocessors. According to Wikipedia, it had facilities for dealing
with interrupts, accessing cpu flags, and for accessing I/O ports.

>> BTW which CP/M are we talking about? I can find sources for CP/M 1, 2
>> and 3, which appear to mix ASM and PL/M. The PL/M looks surprisingly
good.
>
> 1 I guess. I just looked at a little bit of one of them and confirmed
> that it was in a high level language that looked similar to PL/1.
>
>> I didn't use it myself, but had used another machine-oriented language.
>> It was simpler and lower-level than C, if you can imagine that, but was
>> definitely not assembly.
>
> That's exactly the problem - I can't imagine that.

There are various simplifications that are possible. For example, PL/M
only had two primitive types, equivalent to `u8` and `u16` (BYTE and
ADDRESS).

The u16 type served also as a pointer type.

(My first language for microprocessors in '81 had types equivalent to
u8, i16 and f24. I can't remember how I handled pointers. It was on a
smaller scale than PL/M, and much smaller than C (now it's overtaken C).

It ran directly on the device, and I used it for 3D vector graphics and
for some image processing, obviously in a crude way with a low-res display.)

On Thursday, July 20, 2023 at 4:24:31 AM UTC-4, Paul Edwards wrote:
[]
> But if C had been invented at the same time as PL/M and
> had the same amount of effort put into it, would it have
> always been the equal of PL/M?
>
> Or is there something special about PL/M?
>
> Thanks. Paul.

PL/M was an Intel variation of PL/1 from IBM. PL/M toolset was optimized for
the Intel Processors, especially the 8080 family. You had much better control over
memory usage as the sizes of Integers, pointers and character variables were well defined.

I used PL/M for a debugger tool on the 8086. I thought it was a good language
and fought for PL/M versus C when the selection was being made for the next
generation of products at that company. This was around 1984/1985.

I still like PL/M, but ending up using C at many other places I worked. I like C as well.

Enjoy,
Ed

On Friday, July 21, 2023 at 4:48:38 AM UTC+8, Ed Prochak wrote:

> > But if C had been invented at the same time as PL/M and
> > had the same amount of effort put into it, would it have
> > always been the equal of PL/M?
> >
> > Or is there something special about PL/M?

> PL/M was an Intel variation of PL/1 from IBM. PL/M toolset was optimized for
> the Intel Processors, especially the 8080 family. You had much better control over
> memory usage as the sizes of Integers, pointers and character variables were well defined.

Surely that "issue" in C is easily mitigated by having a "flavor"
of C (if you need to go that far) that has very well-defined
16-bit addresses and 8-bit unsigned chars?

Sure - if you write code according to those assumptions it
won't be portable (not a lot of code is), but it's likely to be
far less work to port it to another environment than if you
threw the baby out with the bathwater and opted for
PL/M instead.

BFN. Paul.

Paul Edwards <mutazilah@gmail.com> wrote:
> On Friday, July 21, 2023 at 4:48:38?AM UTC+8, Ed Prochak wrote:
>
>> PL/M was an Intel variation of PL/1 from IBM. PL/M toolset was
>> optimized for the Intel Processors, especially the 8080 family. You
>> had much better control over memory usage as the sizes of Integers,
>> pointers and character variables were well defined.
>
> Surely that "issue" in C is easily mitigated by having a "flavor" of
> C (if you need to go that far) that has very well-defined 16-bit
> addresses and 8-bit unsigned chars?

Not entirely. PL/M has a simpler type system than C, for example very
little in the way of promotion rules. It makes for fairly efficient
code on a pure 8-bit processor without a heavyweight optimizer. And
the language is simple enough that the compiler can fit in memory and
be reasonably fast.

Andrew.

On Saturday, July 22, 2023 at 9:33:20 AM UTC-4, a...@littlepinkcloud.invalid wrote:
> Paul Edwards <muta...@gmail.com> wrote:
> > On Friday, July 21, 2023 at 4:48:38?AM UTC+8, Ed Prochak wrote:
> >
> >> PL/M was an Intel variation of PL/1 from IBM. PL/M toolset was
> >> optimized for the Intel Processors, especially the 8080 family. You
> >> had much better control over memory usage as the sizes of Integers,
> >> pointers and character variables were well defined.
> >
> > Surely that "issue" in C is easily mitigated by having a "flavor" of
> > C (if you need to go that far) that has very well-defined 16-bit
> > addresses and 8-bit unsigned chars?
> Not entirely. PL/M has a simpler type system than C, for example very
> little in the way of promotion rules. It makes for fairly efficient
> code on a pure 8-bit processor without a heavyweight optimizer. And
> the language is simple enough that the compiler can fit in memory and
> be reasonably fast.
>
> Andrew.

Andrew, Yes "reasonably fast"! On the INTEL blue boxes where we ran the PL/M compiler
there was dual 8inch floppy drives. I don't remember how much RAM. The compile of
that debugger took close to an hour to produce just the load image. I had to run a
second pass to produce the assembler listing because you could not fit both on the
output floppy! (Later a 5 meg hard drive was added and the build time for the
debugger went from over an hour to about 5 minutes to produce both image and listing!)

When we did get the C cross compiler, it ran on a DEC VAX!

We did take advantage of C's portability on the next project, debugging the logic
of our embedded software on the VAX before compiling them for the target 8086 boards.
So Paul, don't get me wrong. In the end I liked C and have used it a LOT.

Enjoy
Ed

On 22/07/2023 20:00, Ed Prochak wrote:
> On Saturday, July 22, 2023 at 9:33:20 AM UTC-4,
a...@littlepinkcloud.invalid wrote:
>> Paul Edwards <muta...@gmail.com> wrote:
>>> On Friday, July 21, 2023 at 4:48:38?AM UTC+8, Ed Prochak wrote:
>>>
>>>> PL/M was an Intel variation of PL/1 from IBM. PL/M toolset was
>>>> optimized for the Intel Processors, especially the 8080 family. You
>>>> had much better control over memory usage as the sizes of Integers,
>>>> pointers and character variables were well defined.
>>>
>>> Surely that "issue" in C is easily mitigated by having a "flavor" of
>>> C (if you need to go that far) that has very well-defined 16-bit
>>> addresses and 8-bit unsigned chars?
>> Not entirely. PL/M has a simpler type system than C, for example very
>> little in the way of promotion rules. It makes for fairly efficient
>> code on a pure 8-bit processor without a heavyweight optimizer. And
>> the language is simple enough that the compiler can fit in memory and
>> be reasonably fast.
>>
>> Andrew.
>
> Andrew, Yes "reasonably fast"! On the INTEL blue boxes where we ran
the PL/M compiler
> there was dual 8inch floppy drives. I don't remember how much RAM.
The compile of
> that debugger took close to an hour to produce just the load image.

That sounds extremely slow even for 8080 running on floppies (what was
the size of the image produced?).

Was this 'blue box' an emulator for 8080 running on an 8080? That seems
to be the gist of what is written about this 'Intel MDS 80'. If so that
might explain the speed, although not why it was necessary to use such
an emulator.

I ran my own compiler directly on Z80, at perhaps double the clock
speed, and using 5" floppies that could have been double the capacity of
8" ones (320KB vs 160KB or something).

It only took seconds to build a program. The limiting factor was the
time to read files off disk, at 20KB/sec or some such value, but the
largest program that could be loaded was only 60KB anyway.

> I had to run a
> second pass to produce the assembler listing because you could not
fit both on the
> output floppy!

I've heard of such listings but it's not something I ever bothered with.
It sounds a bit of a luxury on such devices.

On Saturday, July 22, 2023 at 9:33:20 PM UTC+8, a...@littlepinkcloud.invalid wrote:

> >> PL/M was an Intel variation of PL/1 from IBM. PL/M toolset was
> >> optimized for the Intel Processors, especially the 8080 family. You
> >> had much better control over memory usage as the sizes of Integers,
> >> pointers and character variables were well defined.
> >
> > Surely that "issue" in C is easily mitigated by having a "flavor" of
> > C (if you need to go that far) that has very well-defined 16-bit
> > addresses and 8-bit unsigned chars?

> Not entirely. PL/M has a simpler type system than C, for example very
> little in the way of promotion rules. It makes for fairly efficient
> code on a pure 8-bit processor without a heavyweight optimizer. And
> the language is simple enough that the compiler can fit in memory and
> be reasonably fast.

Can a subset of C be used to match both of those things?

Or a slight variant?

I'm talking about with the same effort that was put into PL/M
at the time (1970s) - ie NOT relying on modern heavyweight
optimization of C from 2023.

Basically if the language C90 had existed in say 1950, 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?

Thanks. Paul.

Paul Edwards <mutazilah@gmail.com> wrote:
> On Saturday, July 22, 2023 at 9:33:20?PM UTC+8, a...@littlepinkcloud.invalid wrote:
>> PL/M has a simpler type system than C, for example very
>> little in the way of promotion rules. It makes for fairly efficient
>> code on a pure 8-bit processor without a heavyweight optimizer. And
>> the language is simple enough that the compiler can fit in memory and
>> be reasonably fast.
>
> Can a subset of C be used to match both of those things?
>
> Or a slight variant?

I guess so, sure, if you ditch the integer promotion rules and end up
with something that corresponds more-or-less to the PL/M feature set
but with C's syntax.

> I'm talking about with the same effort that was put into PL/M
> at the time (1970s) - ie NOT relying on modern heavyweight
> optimization of C from 2023.
>
> Basically if the language C90 had existed in say 1950,

Be realistic: 1960. The first functioning stored-program computers
became available around 1950.

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

Well, yes, if by "C" you mean a sort of Tiny C subset that corresponds
to PL/M.

Andrew.

On 24/07/2023 15:07, aph@littlepinkcloud.invalid wrote:
> Paul Edwards <mutazilah@gmail.com> wrote:
>> On Saturday, July 22, 2023 at 9:33:20?PM UTC+8, a...@littlepinkcloud.invalid wrote:
>>> PL/M has a simpler type system than C, for example very
>>> little in the way of promotion rules. It makes for fairly efficient
>>> code on a pure 8-bit processor without a heavyweight optimizer. And
>>> the language is simple enough that the compiler can fit in memory and
>>> be reasonably fast.
>>
>> Can a subset of C be used to match both of those things?
>>
>> Or a slight variant?
>
> I guess so, sure, if you ditch the integer promotion rules and end up
> with something that corresponds more-or-less to the PL/M feature set
> but with C's syntax.
>
>> I'm talking about with the same effort that was put into PL/M
>> at the time (1970s) - ie NOT relying on modern heavyweight
>> optimization of C from 2023.
>>
>> Basically if the language C90 had existed in say 1950,
>
> Be realistic: 1960. The first functioning stored-program computers
> became available around 1950.
>
>> 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?
>
> Well, yes, if by "C" you mean a sort of Tiny C subset that corresponds
> to PL/M.

Tiny C actually implements a substantial subset of C99. I think only
Complex support is missing (or that I'm aware of).

My own C compiler does a smaller subset (leaving out also VLAs,
designated initialisers, compound literals among others), but even that
implements a massively bigger language that than used by PL/M.

There will likely be many toy 'C' compilers at that level (though
probably not that generate code for 8080).

Personally I would just keep that PL/M code as PL/M.

However, I've long lost track of what the OP is trying to achieve. Is
the aim to have a compiler that /runs on/ the 8080? The PL/M sources I
saw were written in Fortran, and presumably were for a cross-compiler.

On Monday, July 24, 2023 at 10:49:57 PM UTC+8, Bart wrote:

> There will likely be many toy 'C' compilers at that level (though
> probably not that generate code for 8080).
>
> Personally I would just keep that PL/M code as PL/M.

I'm not attempting to change the existing PL/M code.
I want to compete with it, in C, on a level playing field.

> However, I've long lost track of what the OP is trying to achieve. Is
> the aim to have a compiler that /runs on/ the 8080?

Not necessarily. CP/M was written via cross-compilation,
so I am happy to do that too.

But I know there are C compilers that run on the 8080,
one of them (BDS C) was actually released to the
public domain. It's written in 8080 assembler.

So if I can run the compiler on the 8080, cool, but I
believe you have to make compromises to fit into
64k. Even SubC has exceeded 64k of code in small
memory model 8086 and hasn't even reached C90
yet. Nevermind data.

And I don't want to make compromises to the source
code of the C compiler due to ridiculous memory
constraints.

So cross-compiling is probably the only option.

BFN. Paul.

On Monday, July 24, 2023 at 10:07:50 PM UTC+8, a...@littlepinkcloud..invalid wrote:

> >> PL/M has a simpler type system than C, for example very
> >> little in the way of promotion rules. It makes for fairly efficient
> >> code on a pure 8-bit processor without a heavyweight optimizer. And
> >> the language is simple enough that the compiler can fit in memory and
> >> be reasonably fast.
> >
> > Can a subset of C be used to match both of those things?
> >
> > Or a slight variant?

> I guess so, sure, if you ditch the integer promotion rules and end up
> with something that corresponds more-or-less to the PL/M feature set
> but with C's syntax.

Ok, I've been programming in C for about 35 years, but
some aspects I have never had to delve into too deeply,
and promotion rules is one of them.

Is this something you could elaborate or is it too much work?

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)

> > I'm talking about with the same effort that was put into PL/M
> > at the time (1970s) - ie NOT relying on modern heavyweight
> > optimization of C from 2023.
> >
> > Basically if the language C90 had existed in say 1950,

> Be realistic: 1960. The first functioning stored-program computers
> became available around 1950.

Ok.

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

> Well, yes, if by "C" you mean a sort of Tiny C subset that corresponds
> to PL/M.

Ok, great - this sounds exactly what I'm after.

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

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.

But for the 8080, apparently type promotion interfered with
writing an OS. And maybe the same issue happened with
writing QDOS/86DOS/MSDOS 1.0 for the 8086?

So I need a suitable subset of C. Note that the Sub C C
compiler has a subset of C too - but that's due to it taking
a long time to find someone to write the necessary code.

And SubC has an evolution too - the older versions don't
have struct, and a version with struct has been written
without using struct. So there are a series of stepping
stones. And it only supports char (which is unsigned)
and int. So maybe it is already the PL/M equivalent, and
exactly SubC was needed to write a CP/M equivalent?

I don't like the requirement of C90 for "long" to be 32-bits
either. That seems onerous for an 8-bit system to me.

Are you aware of Sector C? A C subset that is less than
512 bytes of 8086 assembler. I converted that to C and
called it Multisector C, and targeted the mainframe too.

I don't know if it is technically possible to start with
Sector C/Multisector C and then - purely writing in
valid C90 code (subset) - aside from things that need to
be in assembler - you can eventually produce a full C90
compiler. ie a series of stepping stones.

And I don't know if the PL/M equivalent would be part
of that stepping stone process, or a side-track.

Basically I'm trying to rationalize my use of C. Sort of
like I know English, but need to adjust to Glaswegian
accent. Or Indian accent.

Thanks. Paul.

On Wednesday, July 26, 2023 at 8:32:02 AM UTC+8, Paul Edwards wrote:

> Basically I'm trying to rationalize my use of C. Sort of
> like I know English, but need to adjust to Glaswegian
> accent. Or Indian accent.

There was something similar attempted with English.
They wanted an "international business English" or
something. You were allowed to say "close" to close a
tap, but you weren't allowed to say "get close to the
object".

It didn't work, because natives could never remember
which words they weren't supposed to use.

But in this case the compiler will quickly inform you
which syntax is not supported by a particular dialect
or subset of C for "small memory use" (or whatever
this is called - primitive compiler technology use?).

BFN. Paul.

On Tuesday, July 25, 2023 at 8:32:02 PM UTC-4, Paul Edwards wrote:
> On Monday, July 24, 2023 at 10:07:50 PM UTC+8, a...@littlepinkcloud.invalid wrote:
>
> > >> PL/M has a simpler type system than C, for example very
> > >> little in the way of promotion rules. It makes for fairly efficient
> > >> code on a pure 8-bit processor without a heavyweight optimizer. And
> > >> the language is simple enough that the compiler can fit in memory and
> > >> be reasonably fast.
> > >
> > > Can a subset of C be used to match both of those things?
> > >
> > > Or a slight variant?
>
> > I guess so, sure, if you ditch the integer promotion rules and end up
> > with something that corresponds more-or-less to the PL/M feature set
> > but with C's syntax.
> Ok, I've been programming in C for about 35 years, but
> some aspects I have never had to delve into too deeply,
> and promotion rules is one of them.
>
> Is this something you could elaborate or is it too much work?
>
> 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. As I mentioned, where I worked, PL/M
was dropped for application development. It did require a
cross compiler running on a larger machine (VAX), but gave
an advantage of debugging the logic of the c programs on
the VAX.

> > > I'm talking about with the same effort that was put into PL/M
> > > at the time (1970s) - ie NOT relying on modern heavyweight
> > > optimization of C from 2023.
> > >
> > > Basically if the language C90 had existed in say 1950,
>
> > Be realistic: 1960. The first functioning stored-program computers
> > became available around 1950.
> Ok.
> > > 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.

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.

>
> > Well, yes, if by "C" you mean a sort of Tiny C subset that corresponds
> > to PL/M.
> Ok, great - this sounds exactly what I'm after.
>
> And in fact, C evolved through BPCL and B too.
>
> 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. This "use C for any OS" mantra is nice, but
not useful. There are still parts that have to be written in assembly.
Other languages like PL/S provide different features that may
be more useful for the specific goals of a specific OS.

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.

Ed

On Tuesday, July 25, 2023 at 11:02:18 PM UTC-4, Paul Edwards wrote:
> On Wednesday, July 26, 2023 at 8:32:02 AM UTC+8, Paul Edwards wrote:
>
> > Basically I'm trying to rationalize my use of C. Sort of
> > like I know English, but need to adjust to Glaswegian
> > accent. Or Indian accent.
> There was something similar attempted with English.
> They wanted an "international business English" or
> something. You were allowed to say "close" to close a
> tap, but you weren't allowed to say "get close to the
> object".
>
> It didn't work, because natives could never remember
> which words they weren't supposed to use.
>
> But in this case the compiler will quickly inform you
> which syntax is not supported by a particular dialect
> or subset of C for "small memory use" (or whatever
> this is called - primitive compiler technology use?).
>
> BFN. Paul.

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

(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!)

TTFN
Ed

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.