On Thursday, August 10, 2023 at 7:12:00 AM UTC-4, Paul Edwards wrote:
> On Monday, July 31, 2023 at 12:12:09 PM UTC+8, Ed Prochak wrote:
>
> > Okay. I am trying to make sure I don't offend you here,
> > but
> > you do know that the OBJ file contains more than the
> > executable code and that even the code it contains
> > may not be in binary format,
> > RIGHT?
> Yes, I know that, but it's mostly binary code and
> here is the fat code in the PDOS/86 kernel:
>
> fat_TEXT CODE AUTO 33f2:0000 0000b222
>
> 45602 bytes. Compiled with Open Watcom.
>
> I checked the disassembly - it is all legitimate code.
>
> It could be the price of the huge memory model, which I
> wouldn't encounter on the 8080.
>
> BFN. Paul.

Last I checked 45602 is still less than 64K (65536).
Did you misread a decimal place?

But that doesn't mean all of that code needs to be in memory all the time.
(As pointed out by others in this conversation). In the old days of small
machines these were called overlays. It is more formally called virtual memory.

On small machines if slows things down but these are hardware solutions.

TTFN
Ed

On Monday, August 14, 2023 at 4:47:21 AM UTC+8, Ed Prochak wrote:
> On Thursday, August 10, 2023 at 7:12:00 AM UTC-4, Paul Edwards wrote:
> > On Monday, July 31, 2023 at 12:12:09 PM UTC+8, Ed Prochak wrote:
> >
> > > Okay. I am trying to make sure I don't offend you here,
> > > but
> > > you do know that the OBJ file contains more than the
> > > executable code and that even the code it contains
> > > may not be in binary format,
> > > RIGHT?
> > Yes, I know that, but it's mostly binary code and
> > here is the fat code in the PDOS/86 kernel:
> >
> > fat_TEXT CODE AUTO 33f2:0000 0000b222
> >
> > 45602 bytes. Compiled with Open Watcom.
> >
> > I checked the disassembly - it is all legitimate code.
> >
> > It could be the price of the huge memory model, which I
> > wouldn't encounter on the 8080.
> >
> > BFN. Paul.

> Last I checked 45602 is still less than 64K (65536).
> Did you misread a decimal place?

Here is what I originally reported:

this 8086 object code:

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

almost blowing away the entire 64k possible

Note the word "almost".

> But that doesn't mean all of that code needs to be in memory all the time..
> (As pointed out by others in this conversation). In the old days of small
> machines these were called overlays. It is more formally called virtual memory.
>
> On small machines if slows things down but these are hardware solutions.

Well - is that how CP/M managed to pull off the feat with PL/M?

PL/M does automatic overlays? Or were they manually done?

I guess dropping LFN and FAT32 would save space.

And as I mentioned - this is using the huge memory model.
Although I would have thought that the 8080 with 8-bit
registers and 16-bit addresses would be the equivalent of
huge memory model also.

Although that in itself is another design choice I made - I
wanted my code to be C90-compliant instead of having
"near" and "far" and "huge" keywords everywhere, so I
just chose to blanketly compile in true huge memory model
(all pointers huge). And if that doesn't leave enough room
for apps on an 8086 then upgrade to either a Turbo 186 or
an 80286 or above. Rather than change the OS source code.

I should be able to get another 64k on the Book 8088 by
using the region A0000-AFFFF and simply not use graphics,
but I haven't tried that yet. I'm not sure if I will find RAM or
a hole at B0000-B7FFF. If there is RAM there then I could
switch to using a VT100 terminal and get B0000-BFFFF.
Or fragmented memory would be OK too. But I won't bother
doing that until I have started reusing the kernel's C library
instead of each application having their own.

I think there's a ROM at C0000-FFFFF, without backing RAM
(on the Book 8088), even if it was possible to bank it out.

(note that this was just unrelated comments about the 8086
design - the original question is about 8080 - I'm just not
sure what's going to happen when I take the 8086 and 80386
design and try to implement it on the 8080 - or what the design
should be).

BFN. Paul.

Paul Edwards ha scritto:
> On Monday, August 14, 2023 at 4:47:21 AM UTC+8, Ed Prochak wrote:
>> On Thursday, August 10, 2023 at 7:12:00 AM UTC-4, Paul Edwards wrote:
>>> On Monday, July 31, 2023 at 12:12:09 PM UTC+8, Ed Prochak wrote:
>>>
>>>> Okay. I am trying to make sure I don't offend you here,
>>>> but
>>>> you do know that the OBJ file contains more than the
>>>> executable code and that even the code it contains
>>>> may not be in binary format,
>>>> RIGHT?
>>> Yes, I know that, but it's mostly binary code and
>>> here is the fat code in the PDOS/86 kernel:
>>>
>>> fat_TEXT CODE AUTO 33f2:0000 0000b222
>>>
>>> 45602 bytes. Compiled with Open Watcom.
>>>
>>> I checked the disassembly - it is all legitimate code.
>>>
>>> It could be the price of the huge memory model, which I
>>> wouldn't encounter on the 8080.
>>>
>>> BFN. Paul.
>
>> Last I checked 45602 is still less than 64K (65536).
>> Did you misread a decimal place?
>
> Here is what I originally reported:
>
> this 8086 object code:
>
> 2023-07-29 08:22 56,783 fat.obj
>
> almost blowing away the entire 64k possible
>
>
> Note the word "almost".
>
>> But that doesn't mean all of that code needs to be in memory all the time.
>> (As pointed out by others in this conversation). In the old days of small
>> machines these were called overlays. It is more formally called virtual memory.
>>
>> On small machines if slows things down but these are hardware solutions.
>
> Well - is that how CP/M managed to pull off the feat with PL/M?
>
> PL/M does automatic overlays? Or were they manually done?
>
> I guess dropping LFN and FAT32 would save space.
>
> And as I mentioned - this is using the huge memory model.
> Although I would have thought that the 8080 with 8-bit
> registers and 16-bit addresses would be the equivalent of
> huge memory model also.
>
> Although that in itself is another design choice I made - I
> wanted my code to be C90-compliant instead of having
> "near" and "far" and "huge" keywords everywhere, so I
> just chose to blanketly compile in true huge memory model
> (all pointers huge). And if that doesn't leave enough room
> for apps on an 8086 then upgrade to either a Turbo 186 or
> an 80286 or above. Rather than change the OS source code.
>
> I should be able to get another 64k on the Book 8088 by
> using the region A0000-AFFFF and simply not use graphics,
> but I haven't tried that yet. I'm not sure if I will find RAM or
> a hole at B0000-B7FFF. If there is RAM there then I could
> switch to using a VT100 terminal and get B0000-BFFFF.
> Or fragmented memory would be OK too. But I won't bother
> doing that until I have started reusing the kernel's C library
> instead of each application having their own.
>
> I think there's a ROM at C0000-FFFFF, without backing RAM
> (on the Book 8088), even if it was possible to bank it out.
>

There was the rom for services. For example, at C800:5 you could find
the low-level formatting program for hard-disks. At the DOS period, to
use it it was sufficient to launch debug.exe and to its prompt to give
the command "G C800: 5" :^)

> (note that this was just unrelated comments about the 8086
> design - the original question is about 8080 - I'm just not
> sure what's going to happen when I take the 8086 and 80386
> design and try to implement it on the 8080 - or what the design
> should be).
>
> BFN. Paul.
>

Paul Edwards ha scritto:
> On Monday, August 14, 2023 at 4:47:21 AM UTC+8, Ed Prochak wrote:
>> On Thursday, August 10, 2023 at 7:12:00 AM UTC-4, Paul Edwards wrote:
>>> On Monday, July 31, 2023 at 12:12:09 PM UTC+8, Ed Prochak wrote:
>>>
>>>> Okay. I am trying to make sure I don't offend you here,
>>>> but
>>>> you do know that the OBJ file contains more than the
>>>> executable code and that even the code it contains
>>>> may not be in binary format,
>>>> RIGHT?
>>> Yes, I know that, but it's mostly binary code and
>>> here is the fat code in the PDOS/86 kernel:
>>>
>>> fat_TEXT CODE AUTO 33f2:0000 0000b222
>>>
>>> 45602 bytes. Compiled with Open Watcom.
>>>
>>> I checked the disassembly - it is all legitimate code.
>>>
>>> It could be the price of the huge memory model, which I
>>> wouldn't encounter on the 8080.
>>>
>>> BFN. Paul.
>
>> Last I checked 45602 is still less than 64K (65536).
>> Did you misread a decimal place?
>
> Here is what I originally reported:
>
> this 8086 object code:
>
> 2023-07-29 08:22 56,783 fat.obj
>
> almost blowing away the entire 64k possible
>
>
> Note the word "almost".
>
>> But that doesn't mean all of that code needs to be in memory all the time.
>> (As pointed out by others in this conversation). In the old days of small
>> machines these were called overlays. It is more formally called virtual memory.
>>
>> On small machines if slows things down but these are hardware solutions.
>
> Well - is that how CP/M managed to pull off the feat with PL/M?
>
> PL/M does automatic overlays? Or were they manually done?
>
> I guess dropping LFN and FAT32 would save space.
>
> And as I mentioned - this is using the huge memory model.
> Although I would have thought that the 8080 with 8-bit
> registers and 16-bit addresses would be the equivalent of
> huge memory model also.
>
> Although that in itself is another design choice I made - I
> wanted my code to be C90-compliant instead of having
> "near" and "far" and "huge" keywords everywhere, so I
> just chose to blanketly compile in true huge memory model
> (all pointers huge). And if that doesn't leave enough room
> for apps on an 8086 then upgrade to either a Turbo 186 or
> an 80286 or above. Rather than change the OS source code.
>
> I should be able to get another 64k on the Book 8088 by
> using the region A0000-AFFFF and simply not use graphics,
> but I haven't tried that yet. I'm not sure if I will find RAM or
> a hole at B0000-B7FFF. If there is RAM there then I could
> switch to using a VT100 terminal and get B0000-BFFFF.

The memory of the monochromatic graphic cards in text mode is mapped to
the address B0000, as well as at the address B8000 for the color graphic
cards. These memory areas also exist in RAM but are not used (some
memory managers made it available to use them in Dos. The name of the
most famous was Qemm).

> Or fragmented memory would be OK too. But I won't bother
> doing that until I have started reusing the kernel's C library
> instead of each application having their own.
>
> I think there's a ROM at C0000-FFFFF, without backing RAM
> (on the Book 8088), even if it was possible to bank it out.
>
> (note that this was just unrelated comments about the 8086
> design - the original question is about 8080 - I'm just not
> sure what's going to happen when I take the 8086 and 80386
> design and try to implement it on the 8080 - or what the design
> should be).
>
> BFN. Paul.
>

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

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

That's what I'm trying to understand.

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

I didn't notice any limitation in the language.

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

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

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

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

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

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

On the C64.

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

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

The 80286 is 16-bit register size.

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

BFN. Paul.

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

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

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

fat_TEXT CODE AUTO 33f2:0000 0000b222

45602 bytes. Compiled with Open Watcom.

I checked the disassembly - it is all legitimate code.

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

BFN. Paul.

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

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

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

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

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

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

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

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

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

BFN. Paul.

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