Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #170939 > unrolled thread

PL/M

Back to article view | Back to comp.lang.c

Contents

  PL/M "muta...@gmail.com" <mutazilah@gmail.com> - 2023-07-19 15:56 -0700
    Re: PL/M Bob McConnell <rmcconne@lightlink.com> - 2023-07-20 00:37 +0000
    Re: PL/M Bart <bc@freeuk.com> - 2023-07-20 01:42 +0100
      Re: PL/M Paul Edwards <mutazilah@gmail.com> - 2023-07-20 01:24 -0700
        Re: PL/M Bart <bc@freeuk.com> - 2023-07-20 12:03 +0100
        Re: PL/M Ed Prochak <edprochak@gmail.com> - 2023-07-20 13:48 -0700
          Re: PL/M Paul Edwards <mutazilah@gmail.com> - 2023-07-20 16:17 -0700
            Re: PL/M aph@littlepinkcloud.invalid - 2023-07-22 13:32 +0000
              Re: PL/M Ed Prochak <edprochak@gmail.com> - 2023-07-22 12:00 -0700
                Re: PL/M Bart <bc@freeuk.com> - 2023-07-22 23:24 +0100
              Re: PL/M Paul Edwards <mutazilah@gmail.com> - 2023-07-22 16:59 -0700
                Re: PL/M aph@littlepinkcloud.invalid - 2023-07-24 14:07 +0000
                  Re: PL/M Bart <bc@freeuk.com> - 2023-07-24 15:49 +0100
                    Re: PL/M Paul Edwards <mutazilah@gmail.com> - 2023-07-25 17:12 -0700
                  Re: PL/M Paul Edwards <mutazilah@gmail.com> - 2023-07-25 17:31 -0700
                    Re: PL/M Paul Edwards <mutazilah@gmail.com> - 2023-07-25 20:02 -0700
                      Re: PL/M Ed Prochak <edprochak@gmail.com> - 2023-07-26 07:49 -0700
                        Re: PL/M Spiros Bousbouras <spibou@gmail.com> - 2023-07-26 16:21 +0000
                    Re: PL/M Ed Prochak <edprochak@gmail.com> - 2023-07-26 07:35 -0700
                      Re: PL/M Paul Edwards <mutazilah@gmail.com> - 2023-07-26 08:15 -0700
                        Re: PL/M scott@slp53.sl.home (Scott Lurndal) - 2023-07-26 15:24 +0000
                          Re: PL/M Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-07-26 15:35 +0000
                        Re: PL/M David Brown <david.brown@hesbynett.no> - 2023-07-27 13:41 +0200
                          Re: PL/M Paul Edwards <mutazilah@gmail.com> - 2023-07-27 06:00 -0700
                            Re: PL/M David Brown <david.brown@hesbynett.no> - 2023-07-27 15:43 +0200
                              Re: PL/M scott@slp53.sl.home (Scott Lurndal) - 2023-07-27 14:15 +0000
                                Re: PL/M Paul Edwards <mutazilah@gmail.com> - 2023-07-27 16:37 -0700
                                  Re: PL/M Vir Campestris <vir.campestris@invalid.invalid> - 2023-07-31 21:32 +0100
                                    Re: PL/M gazelle@shell.xmission.com (Kenny McCormack) - 2023-07-31 22:04 +0000
                                      Re: PL/M Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-31 22:22 +0000
                              Re: PL/M Paul Edwards <mutazilah@gmail.com> - 2023-07-28 17:15 -0700
                                Re: PL/M Bart <bc@freeuk.com> - 2023-07-29 02:09 +0100
                                  Re: PL/M Joe Monk <joemonk64@gmail.com> - 2023-07-28 18:18 -0700
                                Re: PL/M David Brown <david.brown@hesbynett.no> - 2023-08-02 00:03 +0200
                                  Re: PL/M Paul Edwards <mutazilah@gmail.com> - 2023-08-10 04:22 -0700
                        Re: PL/M Ed Prochak <edprochak@gmail.com> - 2023-07-28 14:32 -0700
                          Re: PL/M Paul Edwards <mutazilah@gmail.com> - 2023-07-28 16:29 -0700
                            Re: PL/M Ed Prochak <edprochak@gmail.com> - 2023-07-30 20:54 -0700
                              Re: PL/M aph@littlepinkcloud.invalid - 2023-07-31 09:13 +0000
                                Re: PL/M Joe Monk <joemonk64@gmail.com> - 2023-07-31 05:10 -0700
                              Re: PL/M Paul Edwards <mutazilah@gmail.com> - 2023-08-10 04:03 -0700
                          Re: PL/M Vir Campestris <vir.campestris@invalid.invalid> - 2023-07-31 21:38 +0100
                            Re: PL/M Bart <bc@freeuk.com> - 2023-07-31 22:25 +0100
                        Re: PL/M Bart <bc@freeuk.com> - 2023-07-29 01:04 +0100
                          Re: PL/M Paul Edwards <mutazilah@gmail.com> - 2023-07-28 17:28 -0700
                            Re: PL/M Ed Prochak <edprochak@gmail.com> - 2023-07-30 21:12 -0700
                              Re: PL/M Paul Edwards <mutazilah@gmail.com> - 2023-08-10 04:11 -0700
                                Re: PL/M Ed Prochak <edprochak@gmail.com> - 2023-08-13 13:47 -0700
                                  Re: PL/M Paul Edwards <mutazilah@gmail.com> - 2023-08-14 01:14 -0700
                                    Re: PL/M jak <nospam@please.ty> - 2023-08-14 10:50 +0200
                                    Re: PL/M jak <nospam@please.ty> - 2023-08-14 11:32 +0200
                    Re: PL/M Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-26 20:24 +0100
                      Re: PL/M Paul Edwards <mutazilah@gmail.com> - 2023-07-26 16:50 -0700
                        Re: PL/M Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-27 01:00 +0100

Page 1 of 3  [1] 2 3  Next page →

#170939 — PL/M

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.

[toc] | [next] | [standalone]

#170944

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

[toc] | [prev] | [next] | [standalone]

#170945

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.

[toc] | [prev] | [next] | [standalone]

#170949

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.

[toc] | [prev] | [next] | [standalone]

#170962

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

[toc] | [prev] | [next] | [standalone]

#170991

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

[toc] | [prev] | [next] | [standalone]

#170995

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.

[toc] | [prev] | [next] | [standalone]

#171066

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.

[toc] | [prev] | [next] | [standalone]

#171110

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

[toc] | [prev] | [next] | [standalone]

#171122

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.

[toc] | [prev] | [next] | [standalone]

#171132

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.

[toc] | [prev] | [next] | [standalone]

#171210

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.

[toc] | [prev] | [next] | [standalone]

#171215

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.

[toc] | [prev] | [next] | [standalone]

#171261

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.

[toc] | [prev] | [next] | [standalone]

#171262

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.

[toc] | [prev] | [next] | [standalone]

#171264

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.

[toc] | [prev] | [next] | [standalone]

#171284

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

[toc] | [prev] | [next] | [standalone]

#171296

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

[toc] | [prev] | [next] | [standalone]

#171282

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

[toc] | [prev] | [next] | [standalone]

#171288

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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web