smaller c preprocessor

[muta...@gmail.com]

Hi Alexey.

I had another crack at using Smaller C to build
PDOS, and after rebuilding (with Borland C) with
larger defines, I was able to get past all the
constraints. There was just one place that took
quite a while to figure out. I'm not used to
debugging at that level.

If you look here:

C:\devel\pdos\src>smlrpp -o temp.e temp.c

C:\devel\pdos\src>type temp.c
fatfile->lastBytes = (unsigned int)
(fatfile->fileSize
% ((unsigned long)fat->sectors_per_cluster
* (unsigned long)fat->sector_size));

C:\devel\pdos\src>type temp.e
#line 1 "temp.c"
fatfile->lastBytes = (unsigned int)
(fatfile->fileSize
((unsigned long)fat->sectors_per_cluster
* (unsigned long)fat->sector_size));


You can see the "%" has disappeared. All the
preprocessor needed to do was copy input to
output, instead of mangling it. I was previously
compiling with Cygwin gcc (just by running
"make"), but I switched to Borland C to see if
it was a compiler issue.

bcc32 -DSTAND_ALONE -DSTD_MACROS=0 -DSTD_ASSERT=0 -DUCPP_CONFIG cpp.c mem.c nhash.c lexer.c assert.c macro.c eval.c arith.c

But it had the same issue. I took a look at lexer.c
and it was way too complicated for me to understand.

But I actually have another preprocessor-only program,
which is public domain, so I switched to that. That
showed an unrelated problem with the PD version, so I
have asked the author to see if he can fix that.

I used this for Smaller C BTW:

bcc32 -DMAX_IDENT_TABLE_LEN=20000 -DSYNTAX_STACK_MAX=10000 -DSTACK_SIZE=500 smlrc.c

Anyway, with all that done, the only thing that
Smaller C can't cope with is some floating point
stuff in PDPCLIB.

One of them is this:
smlrc -huge -I . math.e math.s
Error in "math.c" (720:18)
Compound assignment not supported with floats

I simplified it to:

__PDPCLIB_API__ double modf(double value, double *iptr)

value -= 5.0;

If I change that to:

value = value - 5.0;

it is accepted. Is the original syntax difficult to support?

Thanks. Paul.

[muta...@gmail.com]

Apologies all. Wrong group.

[muta...@gmail.com]

On Saturday, April 3, 2021 at 4:51:24 PM UTC+11, muta...@gmail.com wrote:

> > Anyway, with all that done, the only thing that
> > Smaller C can't cope with is some floating point
> > stuff in PDPCLIB.
> >
> > One of them is this:
> > smlrc -huge -I . math.e math.s
> > Error in "math.c" (720:18)
> > Compound assignment not supported with floats
> >
> > I simplified it to:
> >
> > __PDPCLIB_API__ double modf(double value, double *iptr)
> >
> > value -= 5.0;
> >
> > If I change that to:
> >
> > value = value - 5.0;
> >
> > it is accepted. Is the original syntax difficult to support?

The group may be interested in the reply to this.

Here is what Alexey said:

It's not the syntax itself, but what it entails.

a += b;
is equivalent to
a = a + b;

Which generally expands into:
a = (type_of_a)((common_type_between_a_and_b)a +
(common_type_between_a_and_b)b);

So, to support this operator with floats you need to break down
+= into separate = and + and be able to insert up to 2 casts in 3 places
in that.

Smaller C represents expressions internally not as trees but in
reverse Polish notation and that, unlike trees, is often inconvenient
to manipulate with.
But if I restrict += to integers and pointers, it's much easier to do.
So, I didn't implement += and such for floating types.

You did just the right (and trivial) workaround.


I don't actually understand that, but this is the sort of
real-world constraint that ISO should be taking into
account and adjusting the C90 standard *down* to
disallow this use of floats.

BFN. Paul.

[Bart]

I don't agree. Syntax trees are almost univerally used within compilers,
so why should a language accommodate primitive ones?

In any case, Tiny C doesn't use a syntax tree either, and is also single
pass, but it supports this.

Now, there are some complications with += :

a += b += c;

Here, a, b, c can be all mixed types. It is not that clear which type
should be used for the result of (b +=c ) to add to a. The results can
be different if these were split up.

For that reason, my language doens't allow += operators to return a
value, so that you can't chain them like this.

In C however the language allows it, although an individual compiler may
choose to omit whatever features it likes, making it less conforming.

A language might make some features optional if they are particularly
difficult; I think that happened with C99's VLAs. But augmented
assignment is not too hard.

[David Brown]

Let me get this right. You have a compiler that has an unusually
restricted internal structure for holding expressions, and that makes it
difficult for you to implement some operations in C efficiently. You
think ISO should therefore /ban/ this particular expression - one that
might be used in countless existing C programs and supported by every
other C compiler - to make the language easier for /your/ compiler?

[muta...@gmail.com]

On Sunday, April 4, 2021 at 9:02:38 PM UTC+10, Bart wrote:

> > I don't actually understand that, but this is the sort of
> > real-world constraint that ISO should be taking into
> > account and adjusting the C90 standard *down* to
> > disallow this use of floats.

> I don't agree. Syntax trees are almost univerally used within compilers,
> so why should a language accommodate primitive ones?

For exactly that reason - so a primitive implementation
can be done.

Smaller C has done something miraculous in 14,000
lines of code.

> In any case, Tiny C doesn't use a syntax tree either, and is also single
> pass, but it supports this.

Thanks for the tip!

I downloaded the Tiny C source code wondering
whether I could use my 32-bit gcc compiler to
create a 64-bit compiler. I'm not sure if it is
technically possible to use a 32-bit C90-only
compiler (any) to create a 64-bit PE executable.

Although there was no restriction mentioned in
Tiny C, and no compile error, I ended up with yet
another 32-bit compiler on my system, and this
one doesn't seem to be able to create relocatable
executables.

> A language might make some features optional if they are particularly
> difficult; I think that happened with C99's VLAs. But augmented
> assignment is not too hard.

Smaller C fills a crucial gap in x86 real mode.
A 32-bit size_t to span the 1 MiB region.

I was able happy to adjust my PDPCLIB code in
a few places to expand -= when dealing with
floats in order to accommodate the real-world
compiler restriction. I didn't need to make any
changes to the PDOS code. This compiler covers
all of my important source code. Tens of thousands
of source lines that had been written with the
assumption of a 100% C90-compliant C compiler
being available without restriction.

If my natural C90 coding style is basically covered
by Smaller C, and Smaller C fills a crucial gap, then
Smaller C's subset of C90 is a viable alternative to
C90.

I'm guessing it is for this reason I took so long to
take a look at Smaller C. I knew it wasn't C90-compliant
so I had zero interest in it.

It is only when I found out about the 32-bit size_t
in real mode that I realized I needed to know exactly
what in C90 I was going to lose.

And it is only recently that I realized my problems
would be solved with a 32-bit size_t and magical
huge pointers.

BFN. Paul.

[muta...@gmail.com]

On Sunday, April 4, 2021 at 9:25:06 PM UTC+10, David Brown wrote:

> > I don't actually understand that, but this is the sort of
> > real-world constraint that ISO should be taking into
> > account and adjusting the C90 standard *down* to
> > disallow this use of floats.
> >
> Let me get this right. You have a compiler that has an unusually
> restricted internal structure for holding expressions, and that makes it
> difficult for you to implement some operations in C efficiently. You

Well, it's not my compiler. Just the one I am using.

And note that I'm not expecting that ISO could have
known this in 1990. That someone would like to use
a restrictive internal structure. (I doubt that they did
that just to be annoying).

> think ISO should therefore /ban/ this particular expression - one that
> might be used in countless existing C programs and supported by every
> other C compiler - to make the language easier for /your/ compiler?

Yes, this is the technology they didn't think of in 1990 -
reverse polish notation.

Note that they deprecated gets() too.

BFN. Paul.

[muta...@gmail.com]

The basic problem is this.

You have a C90-compliant application to perform
some business application, and your initial client
was an Amiga 500 user. It needs a 70k buffer to
operate on, to hold the customer data or whatever.

It works fine on the Amiga 500. Allocating a 70k
buffer is fine.

Your client now tells you he needs it to run under
ordinary MSDOS.

The machines all have 640k, slightly more than the
Amiga 500 (512k), so all should be cool.

He dumps US$20,000 on your desk and tells you
to get new executables to him in 2 weeks time.
He is not interested in crap like "size_t is only
64k on all existing C90-compliant MSDOS compilers".
He's got 640k. He's got cash. Get it done.

All you need to solve this problem is a C compiler
with a -model=magical-huge option. That's what
Smaller C gives you. So long as someone warned
you in advance not to use -= and += etc on floats
in your otherwise Smaller-C-compliant code.

I've just warned you. Next step is to get ISO to
issue an APB.

BFN. Paul.

[Bart]

All-Points Bulletin?

I don't understand what it is that you want.

C90 is a 30-year-old standard. Do you think they should restrospectively
tear it up and issue a cut-down version?

If they can do that, perhaps they should fix the C language too! And
reprint K&R ands K&R2.

There many, many C compilers even smaller than Smaller C (possibly there
are more amateur compilers for C than for any other language, other than
Lisp).

What should the standard do about those? Some of them don't have floats,
or structs.

[muta...@gmail.com]

On Monday, April 5, 2021 at 2:29:14 AM UTC+10, Bart wrote:

> I don't understand what it is that you want.
>
> C90 is a 30-year-old standard. Do you think they should restrospectively
> tear it up and issue a cut-down version?

I think they should make very slight changes to it,
now that we have 30 years of hindsight and know
what worked and what didn't.

They issued two TC as well.

> If they can do that, perhaps they should fix the C language too!

If they can fix it with slight and PRACTICAL changes, that is fine.

> And reprint K&R ands K&R2.

No. Each document should be preserved exactly.

> There many, many C compilers even smaller than Smaller C (possibly there
> are more amateur compilers for C than for any other language, other than
> Lisp).
>
> What should the standard do about those? Some of them don't have floats,
> or structs.

I don't think we can live without structs, but some consideration
should be given to getting rid of floating point. Some processors
can't do floating point, and many applications don't need it, so I
think there should be some hedging there, similar to the whole
"freestanding" consideration - they tell you what functions are
still available.

And why do we have math.h? How did a function like sin()
become a requirement?

And Smaller C doesn't support 32-bit longs when generating
16-bit code. (note that it DOES when doing the magical-huge
thing, which is what I'm mostly interested in).

But why can't "long" have a minimum of 16 bits instead of
32 bits? Why force the 32-bit requirement?

BFN. Paul.

[muta...@gmail.com]

On Monday, April 5, 2021 at 2:41:36 AM UTC+10, muta...@gmail.com wrote:

> > What should the standard do about those? Some of them don't have floats,
> > or structs.

> I don't think we can live without structs, but some consideration
> should be given to getting rid of floating point.

Note that the SQL standard had 3 levels too. Maybe
we need a 3rd level for C90?

BFN. Paul.

[muta...@gmail.com]

I don't know who created size_t, but it seems to me that
that is the natural size for many (all?) variables, so why
didn't they provide a way to get that value from the user
and print it out?

I don't think there is a need to print out a ptrdiff_t though.

Also, I heard that airlines don't allow malloc(). I think that
deserves a mention too.

BFN. Paul.

[Scott Lurndal]

"muta...@gmail.com" <muta...@gmail.com> writes:
>On Sunday, April 4, 2021 at 9:25:06 PM UTC+10, David Brown wrote:
>
>> > I don't actually understand that, but this is the sort of
>> > real-world constraint that ISO should be taking into
>> > account and adjusting the C90 standard *down* to
>> > disallow this use of floats.
>> >
>> Let me get this right. You have a compiler that has an unusually
>> restricted internal structure for holding expressions, and that makes it
>> difficult for you to implement some operations in C efficiently. You

>> think ISO should therefore /ban/ this particular expression - one that
>> might be used in countless existing C programs and supported by every
>> other C compiler - to make the language easier for /your/ compiler?
>
>Yes, this is the technology they didn't think of in 1990 -
>reverse polish notation.

Yeah, because it was obsolete technology before 1980. People
who wrote compilers for a living discovered that processing
the grammar through a compiler generator allowed much more
flexible and extensible grammar processing.

>
>Note that they deprecated gets() too.

As did POSIX. For very good reasons. However, 'deprecate' is not 'ban'.

[muta...@gmail.com]

On Monday, April 5, 2021 at 4:35:19 AM UTC+10, Scott Lurndal wrote:

> >> > I don't actually understand that, but this is the sort of
> >> > real-world constraint that ISO should be taking into
> >> > account and adjusting the C90 standard *down* to
> >> > disallow this use of floats.
> >> >
> >> Let me get this right. You have a compiler that has an unusually
> >> restricted internal structure for holding expressions, and that makes it
> >> difficult for you to implement some operations in C efficiently. You
> >> think ISO should therefore /ban/ this particular expression - one that
> >> might be used in countless existing C programs and supported by every
> >> other C compiler - to make the language easier for /your/ compiler?
> >
> >Yes, this is the technology they didn't think of in 1990 -
> >reverse polish notation.

> Yeah, because it was obsolete technology before 1980. People
> who wrote compilers for a living discovered that processing
> the grammar through a compiler generator allowed much more
> flexible and extensible grammar processing.

C's grammar apparently doesn't require more than
reverse polish notation. It seems silly to invalidate
an entire class of compilers just so that you can
do unitary operations on floats.

I'm assuming that reverse polish notation has some
benefits such as it is simpler to write a compiler.

> >Note that they deprecated gets() too.

> As did POSIX. For very good reasons. However, 'deprecate' is not 'ban'.

Apologies, I misspoke. Perhaps a warning "unitary
operations on floating point are not part of the
C90- standard" would be fine. Unless someone
goes to all the effort of writing "-c90- -pedantic-errors".

BFN. Paul.

[Bart]

On 04/04/2021 22:45, muta...@gmail.com wrote:
> On Monday, April 5, 2021 at 4:35:19 AM UTC+10, Scott Lurndal wrote:
>


>> Yeah, because it was obsolete technology before 1980. People
>> who wrote compilers for a living discovered that processing
>> the grammar through a compiler generator allowed much more
>> flexible and extensible grammar processing.
>
> C's grammar apparently doesn't require more than
> reverse polish notation. It seems silly to invalidate
> an entire class of compilers just so that you can
> do unitary operations on floats.

It seems silly to keep something as a toy language so that people can
cut corners on compilers.

As I said TCC is one pass, and manages that feature. I also have a
smaller, simpler compiler called Pico C (an interpreter), about 7000
lines, and that manages += on floats.

I've used tree-based representations myself, on compilers that than on
64KB 8-bit machines; it is really not a bad deal.

That smaller C chose one kind of represention (which sounds more like
intermediate code) which made some kinds of code transformations harder.

You can't pick one arbitrary, limited compiler out of 100s, and say that
the entire C language should be simplified to that lowest level, while
also ignoring the ones that most people actually used. gcc existed in
1990; smaller C didn't.

> I'm assuming that reverse polish notation has some
> benefits such as it is simpler to write a compiler.

It's normally used to write simple calculator programs. Or as syntax for
limited languages (eg. Forth).

But that's an idea; why not use Forth? The compiler will be very small.

[muta...@gmail.com]

On Monday, April 5, 2021 at 2:41:36 AM UTC+10, muta...@gmail.com wrote:

> But why can't "long" have a minimum of 16 bits instead of
> 32 bits? Why force the 32-bit requirement?

I realized that you can't even read (or at least,
seek) a 360k floppy if you don't even support
32 bits for files.

So there's not much choice but for even the C64
to support 32-bit longs.

BFN. Paul.

[Richard Damon]

I think the key is that if you could live with just 16 bit numbers, you
would just use int. The only time code should be using long is when it
actually needs at least 32 bits, and I don't know of any processor that
couldn't actually do 32 bit math if it really needed to. It might take 4
x 8-bit add with carry instructions to do it, but it could.

[muta...@gmail.com]

On Monday, April 5, 2021 at 8:45:25 AM UTC+10, Bart wrote:

> > C's grammar apparently doesn't require more than
> > reverse polish notation. It seems silly to invalidate
> > an entire class of compilers just so that you can
> > do unitary operations on floats.

> It seems silly to keep something as a toy language so that people can
> cut corners on compilers.

It's not a toy language. Just one small change is
required. Don't mandate unitary operations on
floating points, so that people know they need to
avoid them.

> As I said TCC is one pass, and manages that feature. I also have a
> smaller, simpler compiler called Pico C (an interpreter), about 7000
> lines, and that manages += on floats.

That's all fine. Just don't mandate it.

> I've used tree-based representations myself, on compilers that than on
> 64KB 8-bit machines; it is really not a bad deal.

Your choice, fine.

> That smaller C chose one kind of represention (which sounds more like
> intermediate code) which made some kinds of code transformations harder.

> You can't pick one arbitrary, limited compiler out of 100s, and say that
> the entire C language should be simplified to that lowest level, while

It's only a slight limitation, and it (apparently) opens the
gates to a whole class of C compilers.

> also ignoring the ones that most people actually used. gcc existed in
> 1990; smaller C didn't.

In hindsight, before 1990, some government, any government,
or ISO, or anyone at all really, should have funded a 14,000 line
C compiler that supported magical huge pointers. This would
have shut down the need for "near" and "far" keywords and the
C90 language (minus unitary floats) could have been used for all
platforms, even MSDOS. Using an (apparently) simpler
reverse Polish notation is fine.

Before now, I never knew we were only 14,000 lines of code
away from what was required.

Actually, most of this near/far stuff could have been
shut down simply by compiling with an appropriate
memory model, and allowing absolute addresses
like 0xb8000UL to be gracefully converted into
0xb800:0x0. Most programs didn't need to exceed
size_t of 64k and require magical huge pointers.

I need magical huge pointers for both my loader
(IO.SYS) and my OS (MSDOS.SYS) since both
deal with >64k chunks of data (loading an
executable).

Actually, some more work is needed on the
executable format for MSDOS to allow for
independent conversion from 8086 target
(4 bit segment shift) to 8086+ target
(16 bit segment shift).

> > I'm assuming that reverse polish notation has some
> > benefits such as it is simpler to write a compiler.

> It's normally used to write simple calculator programs. Or as syntax for
> limited languages (eg. Forth).

C90- can be one of those limited languages. Buy some
time for more complicated languages that require trees.

> But that's an idea; why not use Forth? The compiler will be very small.

When I have exhausted C90, I may look into other languages
and see if the same thing (a complete OS/compiler/assembler/editor)
can be written in that language. So far I am exploring the world
of computers via C90. It's an iterative process. And I take one
small step at a time and leave time to reevaluate.

BFN. Paul.

[anti...@math.uni.wroc.pl]

muta...@gmail.com <muta...@gmail.com> wrote:
> On Monday, April 5, 2021 at 4:35:19 AM UTC+10, Scott Lurndal wrote:
>
> > >> > I don't actually understand that, but this is the sort of
> > >> > real-world constraint that ISO should be taking into
> > >> > account and adjusting the C90 standard *down* to
> > >> > disallow this use of floats.
> > >> >
> > >> Let me get this right. You have a compiler that has an unusually
> > >> restricted internal structure for holding expressions, and that makes it
> > >> difficult for you to implement some operations in C efficiently. You
> > >> think ISO should therefore /ban/ this particular expression - one that
> > >> might be used in countless existing C programs and supported by every
> > >> other C compiler - to make the language easier for /your/ compiler?
> > >
> > >Yes, this is the technology they didn't think of in 1990 -
> > >reverse polish notation.
>
> > Yeah, because it was obsolete technology before 1980. People
> > who wrote compilers for a living discovered that processing
> > the grammar through a compiler generator allowed much more
> > flexible and extensible grammar processing.
>
> C's grammar apparently doesn't require more than
> reverse polish notation. It seems silly to invalidate
> an entire class of compilers just so that you can
> do unitary operations on floats.
>
> I'm assuming that reverse polish notation has some
> benefits such as it is simpler to write a compiler.

Well, the explanation you quoted is rather unclear. AFAICS
there are two classes of compiler: simple ones, that
generate code "just" after recognizing some construct
and more complicated ones which use some intermediate
representation. Now, "reverse polish notation" is
sometimes abused as name of parsing technology, but
in such use it is realy bad name. Anyway, simplest
compiler will generate code as "actions" after
recognizing specific syntactic construct. You need
to keep extra information (say in global variables)
but there is no extra difficulty for floating point
'+='. I mean, if you support floating point and
'+=' for integers, then floating point version
appears very naturaly.

Reverse polish may also mean intermediate representation
in the compiler. In the second use it contains equvalent
information as parse tree, but usual trees are easy to
transform while reverse polish structure is much less
flexible. So if Smaller C would like to handle '+=' by
tree transformation, then the is a problem. But
there is no need to use tree transformations for
handling '+='.

So, if you plan from start to implement C, there is
really no excuse for such misfeature. OTOH, if you
decided from start to implement only a subset, then
getting to "full" language may require nontrivial
effort, as various shortcut depending on working with
subset turn out to be invalid. But here is practical
role of standard: standard say you which things
are required. Some vendors (in the past Borland
was famous for such practices) may still try to
push subsets. Remeber, that with rare exceptions
standard is not a law. Rather, vendors look
at benefits and effects. Similarly, users look
at availabilty of features and benefits from
using them. Some standards essentially died
because vendors and users decided that
nonstandard approach was better. Comparing
with other standards, C standard is quite
sucessful. Big part of C success is that
old programs after minor adjustments still work.
Expecting C standard will declare a lot of
programs invalid just to simplify implementing
compilers is quite naive. There are several
C compilers and the tendency is to put more
requirements on compilers as standard develops.

One more thing: it is clear to everybody but you
that standard body does not care about availability
of "public domain" compilers. They do care
about compilers, some care about "free compilers"
but "public domain" is simply not ISO goal.
I would say it stronger: if you want "public domain"
then forget about ISO, they will not help you.

--
Waldek Hebisch

[anti...@math.uni.wroc.pl]

muta...@gmail.com <muta...@gmail.com> wrote:

> In hindsight, before 1990, some government, any government,
> or ISO, or anyone at all really, should have funded a 14,000 line
> C compiler that supported magical huge pointers. This would
> have shut down the need for "near" and "far" keywords and the
> C90 language (minus unitary floats) could have been used for all
> platforms, even MSDOS. Using an (apparently) simpler
> reverse Polish notation is fine.

What you mean by "magical huge pointers"?. 16-bit x86
compilers that I know supported "huge model", there
all pointers (without any explicit declaration) were
huge pointers. I was rarely used, because it slowed
down programs quite a lot.

Concerning "funding a compiler", that would require
some political change. In 1969 IBM was forbidden
(by US court) from giving away "public domain" programs.
And if you want to change policy, better talk to
your local member of parlament.

> Before now, I never knew we were only 14,000 lines of code
> away from what was required.
>
> Actually, most of this near/far stuff could have been
> shut down simply by compiling with an appropriate
> memory model, and allowing absolute addresses
> like 0xb8000UL to be gracefully converted into
> 0xb800:0x0. Most programs didn't need to exceed
> size_t of 64k and require magical huge pointers.

Note that absolute addresses already make your program
nonstandard.

> I need magical huge pointers for both my loader
> (IO.SYS) and my OS (MSDOS.SYS) since both
> deal with >64k chunks of data (loading an
> executable).

Well, that is highly system dependent stuff. On
Unix, normally you would use "mmap", which is
much more efficient than reading executable.

From efficiency point of view it makes
sense to split loading of MSDOS executable
into hunks, each smaller than 64k.

--
Waldek Hebisch

[muta...@gmail.com]

On Monday, April 5, 2021 at 2:00:45 PM UTC+10, anti...@math.uni.wroc.pl wrote:

> > In hindsight, before 1990, some government, any government,
> > or ISO, or anyone at all really, should have funded a 14,000 line
> > C compiler that supported magical huge pointers. This would
> > have shut down the need for "near" and "far" keywords and the
> > C90 language (minus unitary floats) could have been used for all
> > platforms, even MSDOS. Using an (apparently) simpler
> > reverse Polish notation is fine.

> What you mean by "magical huge pointers"?. 16-bit x86
> compilers that I know supported "huge model", there
> all pointers (without any explicit declaration) were
> huge pointers. I was rarely used, because it slowed
> down programs quite a lot.

Huge model just gives you more than 64k of static
data. What I need is a 32-bit size_t and for pointers
to ignore 64k boundaries so that they can address
the entire 1 MiB.

> > Actually, most of this near/far stuff could have been
> > shut down simply by compiling with an appropriate
> > memory model, and allowing absolute addresses
> > like 0xb8000UL to be gracefully converted into
> > 0xb800:0x0. Most programs didn't need to exceed
> > size_t of 64k and require magical huge pointers.

> Note that absolute addresses already make your program
> nonstandard.

True. But the non-standard program can be made to
work in both real mode and protected mode using
that absolute address, if we have graceful conversion.

> > I need magical huge pointers for both my loader
> > (IO.SYS) and my OS (MSDOS.SYS) since both
> > deal with >64k chunks of data (loading an
> > executable).

> Well, that is highly system dependent stuff. On
> Unix, normally you would use "mmap", which is
> much more efficient than reading executable.
>
> From efficiency point of view it makes
> sense to split loading of MSDOS executable
> into hunks, each smaller than 64k.

MSDOS's memory allocation is required to return
more than 64k of data in a single chunk to
applications. So my OS (a replacement for MSDOS)
needs to do that too.

My OS is an executable more than 64k in size, so my
loader also needs to deal with a chunk more than
64k in size.

In both of these situations I had to do some really
horrible hacking to make it work.

With a suitable C compiler with magical huge pointers
that address the full 1 MiB using a 32-bit size_t, I can
have a much cleaner implementation. I only recently
found out that Smaller C was able to do this, as my
only choice.

I'm now trying to marry it up with PDPCLIB. Basically
I need some assembler startup/support code.

BFN. Paul.

[David Brown]

I once had to use a "C" compiler for an 8-bit CISC microcontroller which
supported arrays, and supported structs, but did not support arrays of
structs or structs containing arrays. (It had countless other known
limitations, and uncountably many unknown bugs and limitations.) It was
not an amateur compiler - it was an expensive tool, sold by the
microcontroller manufacturer.

[David Brown]

On 04/04/2021 18:41, muta...@gmail.com wrote:
> On Monday, April 5, 2021 at 2:29:14 AM UTC+10, Bart wrote:
>
>> I don't understand what it is that you want.
>>
>> C90 is a 30-year-old standard. Do you think they should restrospectively
>> tear it up and issue a cut-down version?
>
> I think they should make very slight changes to it,
> now that we have 30 years of hindsight and know
> what worked and what didn't.
>
> They issued two TC as well.

These are, in effect, bug fixes. The C (and C++, and presumably other
standards) issue these every now and again when enough defect reports
have built up, if there is no new full version of the standard issued.
They don't make major changes here - the defect reports are typically
clarifications of the language of the standard.

>
>> If they can do that, perhaps they should fix the C language too!
>

(Most C users will agree that C - any standard - is imperfect, but
you'll never reach agreement on /what/ is imperfect. Some people are
convinced that their particular set of perceived flaws are "obvious" and
"objective" - they are not. They are all subjective, and their fixes
would be new flaws to others. This is inevitable for any language of
wide usage. So please let's not have a repeat discussion of what can be
"fixed" in C.)

> If they can fix it with slight and PRACTICAL changes, that is fine.
>
>> And reprint K&R ands K&R2.
>
> No. Each document should be preserved exactly.
>
>> There many, many C compilers even smaller than Smaller C (possibly there
>> are more amateur compilers for C than for any other language, other than
>> Lisp).
>>
>> What should the standard do about those? Some of them don't have floats,
>> or structs.
>
> I don't think we can live without structs, but some consideration
> should be given to getting rid of floating point. Some processors
> can't do floating point, and many applications don't need it, so I
> think there should be some hedging there, similar to the whole
> "freestanding" consideration - they tell you what functions are
> still available.
>

I wonder if you have any understanding about what C actually is, how it
is defined, and why it has been so popular and successful?

C defines a /standard/. That is precisely /not/ a collection of ideas
from someone who knows vaguely about an old version and thinks they know
how to change the world, past and present. It forms a base of common
features that let people write C code and compile it on C compilers,
without having to adapt to the details of the tool in use.

That does not mean every C compiler has to follow the standard exactly.
Most real-world compilers have extensions of some sort, or accept code
that is a little non-standard, or provide guaranteed behaviour beyond
the requirements of the standard. Most also have some limitations or
minor missing features.

And some C compilers are significantly non-standard. Some are made for
special purposes (like being really small, or written by one person for
that person's requirements) - it's natural that they don't strive for
standards conformance. The same applies to compilers targeting small
embedded processors - it's not uncommon for them not to support 64-bit
doubles. (They generally all support 32-bit floating point, using
software routines as needed.)

But that does not mean it is useful for anyone - programmers or compiler
writers - to change the standards to match the non-standard compilers.
That would be a mockery of the whole concept of "standard", and we might
as well have a free-for-all where everyone makes their own language and
tools to suit their processor and OS. (Ever wonder why C is more
popular than Pascal? This might be a big part of the answer.)

> And why do we have math.h? How did a function like sin()
> become a requirement?
>

They are useful functions that are difficult for most users to implement
themselves (especially if they want to follow the IEEE standards), but
relatively simple for library writers to implement once. It doesn't
matter if the code is too big and slow for a small microcontroller -
it's not a function you would use on such a device. (And these
functions are not a requirement for freestanding implementations anyway.)

> And Smaller C doesn't support 32-bit longs when generating
> 16-bit code. (note that it DOES when doing the magical-huge
> thing, which is what I'm mostly interested in).
>

OK, so "Smaller C" is not a conforming C compiler. That's probably okay
for the kind of use people have for it.

> But why can't "long" have a minimum of 16 bits instead of
> 32 bits? Why force the 32-bit requirement?
>

Because it is useful to all but a few users doing something completely
bizarre, such as trying to recreate environments that the rest of the
world thankfully left behind 30 years ago.

[David Brown]

On 04/04/2021 19:23, muta...@gmail.com wrote:
> I don't know who created size_t, but it seems to me that
> that is the natural size for many (all?) variables, so why
> didn't they provide a way to get that value from the user
> and print it out?
>

First, your assumption is wrong. size_t is intended to represent the
maximum size of objects in the C implementation. That may be bigger or
smaller than the natural size for "int", which is intended to be the
most efficient signed arithmetic integer type of at least 16-bit size.
On 32-bit and smaller systems, it is common for size_t to match the size
of int (though size_t is always unsigned, and int is always signed).
But a 16-bit system with extended memory features might have 16-bit int
and 32-bit size_t. And 64-bit systems generally have 32-bit int
(because it is usually faster than 64-bit int, due to more efficient
cache usage and other related effects) but 64-bit size_t.

Second, printf /does/ have a specifier for printing size_t variables -
"%zu".

> I don't think there is a need to print out a ptrdiff_t though.

Other people do, which is why there is a specifier for that too.

>
> Also, I heard that airlines don't allow malloc(). I think that
> deserves a mention too.
>

I wouldn't place too much emphasis on things you have heard. Airlines
use an enormous array of different types of code in different places,
with different requirements. In safety-critical code, it is common
practice to disallow dynamic memory allocation - but perhaps 99.99% of
all code lines used by an airline (excluding generic code) will /not/ be
safety-critical code. (And at least 99% of it is not in C either.)

As someone who has written safety-critical code, and other
high-reliability code, I can assure you that there is vastly more
involved than just not using malloc(). (And indeed, sometimes malloc()
is fine - perhaps with specialised versions of the function.) One thing
that would not help in the slightest would be to remove (or make
optional) malloc() from the C standard library.

[David Brown]

On 04/04/2021 23:45, muta...@gmail.com wrote:
> On Monday, April 5, 2021 at 4:35:19 AM UTC+10, Scott Lurndal wrote:
>
>>>>> I don't actually understand that, but this is the sort of
>>>>> real-world constraint that ISO should be taking into
>>>>> account and adjusting the C90 standard *down* to
>>>>> disallow this use of floats.
>>>>>
>>>> Let me get this right. You have a compiler that has an unusually
>>>> restricted internal structure for holding expressions, and that makes it
>>>> difficult for you to implement some operations in C efficiently. You
>>>> think ISO should therefore /ban/ this particular expression - one that
>>>> might be used in countless existing C programs and supported by every
>>>> other C compiler - to make the language easier for /your/ compiler?
>>>
>>> Yes, this is the technology they didn't think of in 1990 -
>>> reverse polish notation.
>
>> Yeah, because it was obsolete technology before 1980. People
>> who wrote compilers for a living discovered that processing
>> the grammar through a compiler generator allowed much more
>> flexible and extensible grammar processing.
>
> C's grammar apparently doesn't require more than
> reverse polish notation. It seems silly to invalidate
> an entire class of compilers just so that you can
> do unitary operations on floats.
>

Have you actually given this any thought? On the one hand, you say C's
grammar doesn't need more than RPN. On the other hand, you say you want
to change the C standard because it can't be implemented using RPN.
Regardless of any supposed advantages of RPN for making a simple
compiler, you can't have this argument both ways.

[David Brown]

On 05/04/2021 01:39, muta...@gmail.com wrote:
> On Monday, April 5, 2021 at 8:45:25 AM UTC+10, Bart wrote:
>
>>> C's grammar apparently doesn't require more than
>>> reverse polish notation. It seems silly to invalidate
>>> an entire class of compilers just so that you can
>>> do unitary operations on floats.
>
>> It seems silly to keep something as a toy language so that people can
>> cut corners on compilers.
>
> It's not a toy language.

It's a toy implementation of a limited part of an outdated version of a
real language. It's a toy. Some toys can still have occasional very
niche uses, and can be fun to play with, but they are still toys.

> Just one small change is
> required. Don't mandate unitary operations on
> floating points, so that people know they need to
> avoid them.
>

Let's pick some numbers out of the air, and guess there are and have
been 10 million C programmers over the last 50 years since C was first
developed. And we can be generous and suppose there are 10 people who
are interested in using "Smaller C" for writing code on targets that are
not covered by non-toy compilers. Do you really think the standards for
C should be changed, rending 50 years of work by 10 million people
invalid, just because of those 10 users of "Smaller C" ?

Is this all just something to put on your "egocentric of the year"
application form?

If "Smaller C" doesn't support floating point compound assignment
operators, then don't use them when writing code for use with the
Smaller C toolchain. It is not as if anyone else is going to write code
for that compiler or your environment, so no one else needs to be
bothered by its limitations.

>> As I said TCC is one pass, and manages that feature. I also have a
>> smaller, simpler compiler called Pico C (an interpreter), about 7000
>> lines, and that manages += on floats.
>
> That's all fine. Just don't mandate it.
>
>> I've used tree-based representations myself, on compilers that than on
>> 64KB 8-bit machines; it is really not a bad deal.
>
> Your choice, fine.
>
>> That smaller C chose one kind of represention (which sounds more like
>> intermediate code) which made some kinds of code transformations harder.
>
>> You can't pick one arbitrary, limited compiler out of 100s, and say that
>> the entire C language should be simplified to that lowest level, while
>
> It's only a slight limitation, and it (apparently) opens the
> gates to a whole class of C compilers.

A whole class that doesn't exist except in one toy.

[David Brown]

On 05/04/2021 05:30, anti...@math.uni.wroc.pl wrote:

> One more thing: it is clear to everybody but you
> that standard body does not care about availability
> of "public domain" compilers. They do care
> about compilers, some care about "free compilers"
> but "public domain" is simply not ISO goal.
> I would say it stronger: if you want "public domain"
> then forget about ISO, they will not help you.
>

The working groups for language standards such as C and C++ are
interested in "major toolchains" - generally they try to avoid adding
new features to the language unless it has been tested on a "major
toolchain" for a while. (That's good practice, and reduces the risk of
unforeseen complications in a feature.)

They don't particularly care about licencing models - just that the
tools should be generally available to the public (free or at a
reasonable cost).

It would not make sense for an international organisation to concern
themselves about licensing details, since those can vary from country to
country (in some countries you could not even have such a thing as a
public domain compiler).

[Richard Damon]

On 4/5/21 2:10 AM, muta...@gmail.com wrote:
> On Monday, April 5, 2021 at 2:00:45 PM UTC+10, anti...@math.uni.wroc.pl wrote:
>
>>> In hindsight, before 1990, some government, any government,
>>> or ISO, or anyone at all really, should have funded a 14,000 line
>>> C compiler that supported magical huge pointers. This would
>>> have shut down the need for "near" and "far" keywords and the
>>> C90 language (minus unitary floats) could have been used for all
>>> platforms, even MSDOS. Using an (apparently) simpler
>>> reverse Polish notation is fine.
>
>> What you mean by "magical huge pointers"?. 16-bit x86
>> compilers that I know supported "huge model", there
>> all pointers (without any explicit declaration) were
>> huge pointers. I was rarely used, because it slowed
>> down programs quite a lot.
>
> Huge model just gives you more than 64k of static
> data. What I need is a 32-bit size_t and for pointers
> to ignore 64k boundaries so that they can address
> the entire 1 MiB.

My memory was that Large gave you more than 64k of static, the 64k limit
became per TU, and you could specifically mark given items with the
'far' attribute to put them outside that files static segment so they
didn't count.

Huge allowed arrays to span the 64k boundary, each base element needing
to be with 64k, but the segment register was setup so each item as it
was addressed was all in a segment (it might have required marking that
array/pointer as huge)

[anti...@math.uni.wroc.pl]

muta...@gmail.com <muta...@gmail.com> wrote:
> On Monday, April 5, 2021 at 2:00:45 PM UTC+10, anti...@math.uni.wroc.pl wrote:
>
> > > In hindsight, before 1990, some government, any government,
> > > or ISO, or anyone at all really, should have funded a 14,000 line
> > > C compiler that supported magical huge pointers. This would
> > > have shut down the need for "near" and "far" keywords and the
> > > C90 language (minus unitary floats) could have been used for all
> > > platforms, even MSDOS. Using an (apparently) simpler
> > > reverse Polish notation is fine.
>
> > What you mean by "magical huge pointers"?. 16-bit x86
> > compilers that I know supported "huge model", there
> > all pointers (without any explicit declaration) were
> > huge pointers. I was rarely used, because it slowed
> > down programs quite a lot.
>
> Huge model just gives you more than 64k of static
> data. What I need is a 32-bit size_t and for pointers
> to ignore 64k boundaries so that they can address
> the entire 1 MiB.

I do nor remember size_t in huge model. But the whole
point of huge model was that you could use arrays
bigger than 64k. In particular incrementing huge pointer
lead to "carry" from offset part to segment part.
Specific compiler may have weird limitations (like
floating point '+=' issue in Smaller C), but the idea
of huge model was that you just compile program and it will
work with minimal changes (unlike usually more substantial
changes needed when you opted for explicit modifiers
on pointers).

> > > I need magical huge pointers for both my loader
> > > (IO.SYS) and my OS (MSDOS.SYS) since both
> > > deal with >64k chunks of data (loading an
> > > executable).
>
> > Well, that is highly system dependent stuff. On
> > Unix, normally you would use "mmap", which is
> > much more efficient than reading executable.
> >
> > From efficiency point of view it makes
> > sense to split loading of MSDOS executable
> > into hunks, each smaller than 64k.
>
> MSDOS's memory allocation is required to return
> more than 64k of data in a single chunk to
> applications. So my OS (a replacement for MSDOS)
> needs to do that too.

Well, if it is your own OS, then you do not need
to bother with what MSDOS did. If you want to
run unmodifed MSDOS binaries, then size_t is
not a problem: MSDOS knows nothing about size_t.

But assuming that _you_ want 32-bit size_t, then
with most compilers you just replace 'malloc'
and few other library functions by your own
(IIUC you have your own C library) and provide
header file which defines size_t as approprite
32-bit integer time (AFAIK all resonably popular
compilers for MSDOS had 32-bit long).

> My OS is an executable more than 64k in size, so my
> loader also needs to deal with a chunk more than
> 64k in size.
>
> In both of these situations I had to do some really
> horrible hacking to make it work.

I am not sure what you mean by "horrible hacking".
If compiler supports appropriate extentions spliting
load into hunks is just few lines of extra code. Of
course you need to allocate a single block of memory,
but if you use MSDOS, then you can use MSDOS memory
alloc, if you have your own OS, then is trivial to
implement such an alloc. Nothing complicated compared
to other stuff needed by MSDOS format

--
Waldek Hebisch

[anti...@math.uni.wroc.pl]

muta...@gmail.com <muta...@gmail.com> wrote:
> The basic problem is this.
>
> You have a C90-compliant application to perform
> some business application, and your initial client
> was an Amiga 500 user. It needs a 70k buffer to
> operate on, to hold the customer data or whatever.
>
> It works fine on the Amiga 500. Allocating a 70k
> buffer is fine.
>
> Your client now tells you he needs it to run under
> ordinary MSDOS.
>
> The machines all have 640k, slightly more than the
> Amiga 500 (512k), so all should be cool.
>
> He dumps US$20,000 on your desk and tells you
> to get new executables to him in 2 weeks time.
> He is not interested in crap like "size_t is only
> 64k on all existing C90-compliant MSDOS compilers".
> He's got 640k. He's got cash. Get it done.
>
> All you need to solve this problem is a C compiler
> with a -model=magical-huge option.

Well, one of simplest things is to require at least 386
and use DOS extender. But IIUC your client is shrine
of holy 8088 and they will not allow blasphemy like 386.
I still have my 16-bit compilers and they all support
huge model, so not problem due to 70k buffer. But
your "640k is more than 512k" is quite naive. Namely
program also takes space and different compilers
can produce quite different code size. AFAIK gcc
for 68000 produced quite good (that is small) code.
Old 16-bit compiler tended to be much worse. And
huge pointers lead to particularly bad code, both
much slower and much larger than 32-bit code. So
it is possible that after compilation program will
be too big to fit (together with data) into 640k,
even if version for 68000 fit in 512k.

--
Waldek Hebisch

[Scott Lurndal]

"muta...@gmail.com" <muta...@gmail.com> writes:
>On Monday, April 5, 2021 at 4:35:19 AM UTC+10, Scott Lurndal wrote:

>> Yeah, because it was obsolete technology before 1980. People
>> who wrote compilers for a living discovered that processing
>> the grammar through a compiler generator allowed much more
>> flexible and extensible grammar processing.
>
>C's grammar apparently doesn't require more than
>reverse polish notation. It seems silly to invalidate
>an entire class of compilers just so that you can
>do unitary operations on floats.
>
>I'm assuming that reverse polish notation has some
>benefits such as it is simpler to write a compiler.

The general technique is called "Recursive Descent"
parsing, and was quite common until yacc et alia
were developed.

RD parsers difficult to maintain and difficult to extend
albeit straightforward to write.

[Scott Lurndal]

anti...@math.uni.wroc.pl writes:

>muta...@gmail.com <muta...@gmail.com> wrote:
>

>Concerning "funding a compiler", that would require
>some political change. In 1969 IBM was forbidden
>(by US court) from giving away "public domain" programs.
>And if you want to change policy, better talk to
>your local member of parlament.

You misrepresent the terms of the unbundling consent decree.

Public domain had nothing to do with it.

[Keith Thompson]

And there is some popular public domain software, though it's a small
fraction of open source. Sqlite3 is perhaps the most prominent example.
(The project also sells licenses for those who might need them for some
reason.)

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[Scott Lurndal]

>anti...@math.uni.wroc.pl writes:
>>muta...@gmail.com <muta...@gmail.com> wrote:
>>
>

>>Concerning "funding a compiler", that would require
>>some political change. In 1969 IBM was forbidden
>>(by US court) from giving away "public domain" programs.
>>And if you want to change policy, better talk to
>>your local member of parlament.

The only local member of parliament around here would be George Clinton.

[muta...@gmail.com]

On Tuesday, April 6, 2021 at 2:26:40 AM UTC+10, Scott Lurndal wrote:

> >I'm assuming that reverse polish notation has some
> >benefits such as it is simpler to write a compiler.

> The general technique is called "Recursive Descent"
> parsing, and was quite common until yacc et alia
> were developed.

Thanks for the info.

> RD parsers difficult to maintain and difficult to extend
> albeit straightforward to write.

Can you elaborate on this "difficult to maintain"?
Is this if there is a bug found or something?

I like this "straightforward to write" option. Now that
I know it's actually possible.

I don't think I care about extending. I'm only interested
in C90 or close.

I would like a version that produces S/370 code and
z/Arch too, but for the latter, not using newer
instructions unless necessary. Basically I'm hoping
that AR R3,R4 will become AGR R3,R4, and that's
about it. I'm happy to give up 32-bit data types in
the z/Arch flavor too, to try to simplify things.

BFN. Paul.

[Scott Lurndal]

"muta...@gmail.com" <muta...@gmail.com> writes:
>On Tuesday, April 6, 2021 at 2:26:40 AM UTC+10, Scott Lurndal wrote:
>
>> >I'm assuming that reverse polish notation has some
>> >benefits such as it is simpler to write a compiler.
>
>> The general technique is called "Recursive Descent"
>> parsing, and was quite common until yacc et alia
>> were developed.
>
>Thanks for the info.
>
>> RD parsers difficult to maintain and difficult to extend
>> albeit straightforward to write.
>
>Can you elaborate on this "difficult to maintain"?
>Is this if there is a bug found or something?
>
>I like this "straightforward to write" option. Now that
>I know it's actually possible.

I suggest you pick up a copy of the Dragon book. The authors
were recently awarded the Turing Prize by the ACM.

[muta...@gmail.com]

On Monday, April 5, 2021 at 7:38:41 PM UTC+10, David Brown wrote:

> Let's pick some numbers out of the air, and guess there are and have
> been 10 million C programmers over the last 50 years since C was first
> developed. And we can be generous and suppose there are 10 people who
> are interested in using "Smaller C" for writing code on targets that are
> not covered by non-toy compilers. Do you really think the standards for
> C should be changed, rending 50 years of work by 10 million people
> invalid, just because of those 10 users of "Smaller C" ?
>
> Is this all just something to put on your "egocentric of the year"
> application form?
>
> If "Smaller C" doesn't support floating point compound assignment
> operators, then don't use them when writing code for use with the
> Smaller C toolchain. It is not as if anyone else is going to write code
> for that compiler or your environment, so no one else needs to be
> bothered by its limitations.

I think what I can do is make sure my own code conforms
to Smaller C limitations, plus any other code I am interested in.

Other code I am interested in is micro-emacs and GCC 3.2.3.

I found out that micro-emacs is using K&R-style functions
that Smaller C doesn't support. I am happy to change all
that code to C90-style. Not sure what the GCC 3.2.3
situation is.

So you could boot PDOS, have access to a Smaller-C-like
compiler, be able to compile GCC, which in turn can be
used to compile Linux.

BFN. Paul.

[Kaz Kylheku]

Recursive descent has some disadvantages:

- it is limited to LL grammars; so if your grammar is not that, you have
to refactor the grammar, and then the recursive descent parser's
structure doesn't reflect your original grammar.

- you don't have certain tools in recursive descent, unless you develop
them yourself, such as the ability to declaratively indicate
associativity and precedence between grammar rules. Or advanced
features like being able to express a semantic attribute grammar
directly.

- recursion means that the stack depth is proportional to the
level of nesting. A table-driven LR parser uses its own
stack, first of all, so there is the possibility of gracefully
recovering from a stack overflow without OS-specific hacks.
Secondly, a table-driven LR parser doesn't consume parser stack
on left-recursive rules. (However, in counterpoint, a recursive
descent parser may be able to use loops and tail calls in some cases.)

- a parser generator may give you the option to create a push
parser: a state machine to which you can feed tokens, rather
than a function that you call which retains control until parsing
the entire tree.

Just about everything else is a plus.

Just the fact that recursive descent parsing lets you put a debugger
breakpoint on a function, so you can see where in the parser you are
is an overwhelming advantage.

With a recursive-descent parser, if you have a minimal repro test
case for some parsing problem, you can just single step through it
to understand where/how a bad decision is being made.

If you work with a language that has non-local control transfers, you
can work complex backtracking into a recursive descent parser, which
extends the power of the technique. So that is to say, recursive descent
can speculatively parse the input one way, backtrack and try it another
way. This cannot be worked in to a generated parser, unless you hack
on the tool itself.

One of the most complicated languages on the planet is C++,
and it is constantly changing, requiring parser maintenance.

Yet, GNU C++ uses a recursive descent parser to handle C++. It was 1.5
megabytes of code in one source file, last time I looked. It used to be
C; now it is C-like C++.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

[muta...@gmail.com]

On Tuesday, April 6, 2021 at 7:35:20 AM UTC+10, muta...@gmail.com wrote:

> I found out that micro-emacs is using K&R-style functions
> that Smaller C doesn't support. I am happy to change all
> that code to C90-style. Not sure what the GCC 3.2.3
> situation is.

GCC 3.2.3 uses K&R-style. However, I have ported
GCC 3.4.6 too. It's not as stable on the i370 platform,
but it is good enough to rebuild itself, which means
that it can probably build GCC 3.2.3 too.

And I remembered some other software I am
interested in - SDCC. Hopefully I can build that too,
possibly by using GCC 3.2.3.

I would also like a wasm-compatible assembler, good
enough to handle the code generated from a
Smaller-C-like compiler (not Smaller C itself, which
uses nasm syntax).

Does recursive descent make writing an assembler
simpler, or does that issue not exist there?

I'll also need a librarian and a linker.

Note that a public domain C preprocessor was added
to PDOS a few hours ago:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdcc/

(written by someone from Slovakia)

BFN. Paul.

[Bart]

All those tools are extra dependencies, with a bewildering range of
choices (and they all have to be learnt).

Many might be Linux-centric, causing difficulties on Windows.

They may come as source code to be built, involving even more
dependencies and opportunities to go wrong.

Separate tools can cover tokenising and parsing, causing more confusion
(who/what takes care of tokenising if you only want the parser?).

If using the tool for parsing and you are compiling C, what will it know
about the preprocessor?

They require the grammar to be formally specified; so instead of writing
a parser in a language you know, you have to describe the syntax in a
language you don't.

It also has to be completely unambiguous, while a recursive descent
parser can have informal workarounds.

All the auxialliary tasks done by a parser, building symbol tables,
ASTs, building type tables, still have to be done, but now you have to
think as well about how to attach those actions to the output of the tool.

It's not clear when happens when you make a small change to the grammar
and rerun the tool; does it regenerate the code, to which you then have
to reassociate all the code you've attached to it?

The tools tend to generate source code of a specific language, but if
you are using another language (eg. your own), then it's not going to work.

Even if it does, if you want other people to build your project, then
/they/ will have the hassle of all the dependencies too.

(I specialise in making this stuff as simple as possible with as few
extraneous dependencies as possible. So if I want someone else to build
my C compiler from source, then first I do this:

C:\archive\cx>bb -ma cc
Compiling cc.m---------- to cc.ma

The entires sources [not in C], support files and system headers are in
one file cc.ma. The person building it needs that file, the compiler
bb.exe, and builds the compiler like this (it takes 0.2 seconds or less):

C:\archive\cx>bb cc.ma
Compiling cc.m---------- to cc.exe

They now have a C compiler (previously they only had the bb.exe
compiler) which they can try out:

C:\archive\cx>cc hello -run
Compiling hello.c to hello.exe
Hello, World!

Here are the sizes of those two files:

C:\archive\cx>dir \m\bb.exe
05/04/2021 17:29 568,320 bb.exe

C:\archive\cx>dir cc.ma
05/04/2021 23:47 1,323,645 cc.ma)

[David Brown]

Or I could boot Linux, run real gcc of a reasonable vintage, and compile
Linux and whatever else I want in the comfort of a good system using all
the hardware I have and all the software I want, and a top-rank compiler.

I regularly make software for systems smaller than the hardware you plan
to support (although one system I have now has 1 MB ram, 4 MB flash and
a 600 MHz processor - it's huge by my regular standards). I do it in
the way all sane developers write code for such systems - I write it on
a PC and use a cross-compiler.

[muta...@gmail.com]

On Tuesday, April 6, 2021 at 4:28:42 PM UTC+10, David Brown wrote:

> > So you could boot PDOS, have access to a Smaller-C-like
> > compiler, be able to compile GCC, which in turn can be
> > used to compile Linux.
> >
> Or I could boot Linux, run real gcc of a reasonable vintage, and compile
> Linux and whatever else I want in the comfort of a good system using all
> the hardware I have and all the software I want, and a top-rank compiler.
>
> I regularly make software for systems smaller than the hardware you plan
> to support (although one system I have now has 1 MB ram, 4 MB flash and
> a 600 MHz processor - it's huge by my regular standards). I do it in
> the way all sane developers write code for such systems - I write it on
> a PC and use a cross-compiler.

Yes, if you're happy to use copyrighted software and
modern hardware there is no need to care about the
progress of the public domain solutions.

But I was very happy to be able to replace copyrighted
ucpp with pdcc in the last 24 hours when I received a
needed bug fix.

Others are slapping copyrights on their works for
reasons that make sense to them.

I am sourcing copyright-free works for reasons that
make sense to me.

The two groups will never have a meeting of the minds.

The work of the former will eventually become the latter
though, maybe in 150 years or something. I just don't
want to wait that long.

BFN. Paul.

[David Brown]

On 06/04/2021 09:35, muta...@gmail.com wrote:
> On Tuesday, April 6, 2021 at 4:28:42 PM UTC+10, David Brown wrote:
>
>>> So you could boot PDOS, have access to a Smaller-C-like
>>> compiler, be able to compile GCC, which in turn can be
>>> used to compile Linux.
>>>
>> Or I could boot Linux, run real gcc of a reasonable vintage, and compile
>> Linux and whatever else I want in the comfort of a good system using all
>> the hardware I have and all the software I want, and a top-rank compiler.
>>
>> I regularly make software for systems smaller than the hardware you plan
>> to support (although one system I have now has 1 MB ram, 4 MB flash and
>> a 600 MHz processor - it's huge by my regular standards). I do it in
>> the way all sane developers write code for such systems - I write it on
>> a PC and use a cross-compiler.
>
> Yes, if you're happy to use copyrighted software and
> modern hardware there is no need to care about the
> progress of the public domain solutions.

You can't avoid copyright. Pretty much everything anyone writes or
creates, anywhere, is covered by copyright. The posts that you make to
Usenet are copyrighted - in most countries, you automatically own the
copyright to everything you write unless someone (such as an employer)
has greater rights. In some jurisdictions you can't avoid copyright or
"give something to public domain". In others, when you have labelled
something "public domain" there is little to stop someone else taking
the code and claiming it as theirs - certainly you'd have an uphill
battle in the courts to regain any kind of control.

Basically, unless you are using the kind of licensing and legal support
that the sqllite folk are doing, making code "public domain" is not far
off saying "This is worthless. I don't care what anyone does with it".
I really don't understand some people's obsession with public domain -
it is perhaps the most unhelpful way to release code, since it is so
unclear. It certainly does not mean the code will always be available,
or that anyone can use it as they want.

And yes, I greatly prefer to be able to use the hardware I can get now,
or have bought in recent years, to trying to dig out something 30 years
old from a landfill and hope that it might still work.

[muta...@gmail.com]

On Tuesday, April 6, 2021 at 6:58:02 PM UTC+10, David Brown wrote:
> On 06/04/2021 09:35, muta...@gmail.com wrote:
> > On Tuesday, April 6, 2021 at 4:28:42 PM UTC+10, David Brown wrote:
> >
> >>> So you could boot PDOS, have access to a Smaller-C-like
> >>> compiler, be able to compile GCC, which in turn can be
> >>> used to compile Linux.
> >>>
> >> Or I could boot Linux, run real gcc of a reasonable vintage, and compile
> >> Linux and whatever else I want in the comfort of a good system using all
> >> the hardware I have and all the software I want, and a top-rank compiler.
> >>
> >> I regularly make software for systems smaller than the hardware you plan
> >> to support (although one system I have now has 1 MB ram, 4 MB flash and
> >> a 600 MHz processor - it's huge by my regular standards). I do it in
> >> the way all sane developers write code for such systems - I write it on
> >> a PC and use a cross-compiler.
> >
> > Yes, if you're happy to use copyrighted software and
> > modern hardware there is no need to care about the
> > progress of the public domain solutions.

> You can't avoid copyright.

Yes you can.

> Pretty much everything anyone writes or
> creates, anywhere, is covered by copyright.

Yes, that is the default unless you explicitly release it
to the public domain.

> The posts that you make to Usenet are copyrighted

That is not clear.

> - in most countries, you automatically own the
> copyright to everything you write

Yes, but in most countries you can relinquish those
rights so that it is in the same state as Shakespeare's
"Hamlet".

> unless someone (such as an employer)
> has greater rights. In some jurisdictions you can't avoid copyright or
> "give something to public domain".

For those situations you can say "or use the CC0".
There is absolutely no need to "give up" and go to
the effort to write the word "copyright" instead.

> In others, when you have labelled
> something "public domain" there is little to stop someone else taking
> the code and claiming it as theirs

That's nonsense. You can take any code from anyone
at all and claim it as your own. Proving that you were
the original author, and thus it is public domain (or
your specific license) is a separate issue.

> - certainly you'd have an uphill
> battle in the courts to regain any kind of control.

There is no longer any control once it is released
to the public domain. Nobody bothers to dig up
Shakespeare to ask for his consent to copy large
chunks of "Hamlet".

> Basically, unless you are using the kind of licensing and legal support
> that the sqllite folk are doing, making code "public domain" is not far

Nonsense. You don't need legal support any more
than any other license you may wish to use.

> off saying "This is worthless.

If that's your attitude, that's up to you. Personally I was
delighted when "pdmake" arrived by email and a 30
year quest was over.

> I don't care what anyone does with it".

That is actually correct. Shakespeare is beyond caring too.

> I really don't understand some people's obsession with public domain -

I don't understand people's obsession with trying to
dismiss copyright-free code, with zero restrictions
whatsoever as being inferior to some stupid license
telling what you can or can't do. Obviously it's their
work and they are free to do what they want. But
that doesn't mean that restrictions are superior to
absence of restrictions.

> it is perhaps the most unhelpful way to release code, since it is so
> unclear.

No, there's nothing unclear. It's as clear as Shakespeare's
"Hamlet". That what it is. The only restriction (in *some*
countries) is that they don't recognize a right to do that.
So, use CC0 as a fallback.

> It certainly does not mean the code will always be available,
> or that anyone can use it as they want.

It means exactly that. That's as good as it gets. No
list of restrictions.

> And yes, I greatly prefer to be able to use the hardware I can get now,
> or have bought in recent years, to trying to dig out something 30 years
> old from a landfill and hope that it might still work.

And if I ever wanted to get to the top of Mount Everest,
I'd take a damned helicopter.

What other pointless activities do you personally do?
Ever gone skating? Skiing?

If you're content to let people tell you what you can or
can't do for the rest of your life, on your own damned
computer, go for it. Personally I'm planning on switching
to PDOS when it becomes viable. I'll probably be switching
to EBCDIC too. Even on the x64. I have been using
command line and micro-emacs my whole adult life in
preparation for the switch.

The state public domain software has reached to date
is interesting. As you noted, there's a viable SQL
database available. What else?

BFN. Paul.

[David Brown]

Well, I am not a lawyer - and certainly not fully versed in all
jurisdictions. However, you don't need a copyright statement or any
kind of registration to own copyright to something you produce - it
merely needs the work to be copyrightable material that you create. The
only possible point of question is how much of a post is your own
creation rather than other people's, and whether it is substantial
enough to count as copyrightable.

>
>> - in most countries, you automatically own the
>> copyright to everything you write
>
> Yes, but in most countries you can relinquish those
> rights so that it is in the same state as Shakespeare's
> "Hamlet".
>

And as I pointed out, in some countries you cannot.

>> unless someone (such as an employer)
>> has greater rights. In some jurisdictions you can't avoid copyright or
>> "give something to public domain".
>
> For those situations you can say "or use the CC0".
> There is absolutely no need to "give up" and go to
> the effort to write the word "copyright" instead.
>

Copyright is not "giving up". It is /owning/ up - it is saying "I made
this". Then you use the license you want to give people whatever rights
you want them to have.

>> In others, when you have labelled
>> something "public domain" there is little to stop someone else taking
>> the code and claiming it as theirs
>
> That's nonsense. You can take any code from anyone
> at all and claim it as your own. Proving that you were
> the original author, and thus it is public domain (or
> your specific license) is a separate issue.
>

As the saying goes, possession is nine tenths of the law. If you have
published code with copyright messages and dates, and someone else
claims it is theirs, then it is a relatively simple matter for you to
prove that you are in the right. If you have explicitly said "I don't
care what happens to this code or who takes it - it is not /my/ code",
then why would any court in the world rule against someone who said
"okay, if you don't want it, /I'll/ have it" ? I am not suggesting it
would be /legal/ for anyone to claim ownership of your public domain
code - I am suggesting that if anyone tried it, they'd have a good
chance of getting away with it (especially if they have a bigger bank
account than you ).

>> - certainly you'd have an uphill
>> battle in the courts to regain any kind of control.
>
> There is no longer any control once it is released
> to the public domain. Nobody bothers to dig up
> Shakespeare to ask for his consent to copy large
> chunks of "Hamlet".
>

They don't need his consent, or anyone else's. But no one can claim
ownership of his texts because the position is well established.

>> Basically, unless you are using the kind of licensing and legal support
>> that the sqllite folk are doing, making code "public domain" is not far
>
> Nonsense. You don't need legal support any more
> than any other license you may wish to use.
>
>> off saying "This is worthless.
>
> If that's your attitude, that's up to you. Personally I was
> delighted when "pdmake" arrived by email and a 30
> year quest was over.
>
>> I don't care what anyone does with it".
>
> That is actually correct. Shakespeare is beyond caring too.
>
>> I really don't understand some people's obsession with public domain -
>
> I don't understand people's obsession with trying to
> dismiss copyright-free code, with zero restrictions
> whatsoever as being inferior to some stupid license
> telling what you can or can't do. Obviously it's their
> work and they are free to do what they want. But
> that doesn't mean that restrictions are superior to
> absence of restrictions.

For a great many purposes, a clear license saying how code can be used
is vastly superior to code with no license that says nothing. A lot of
companies will not make use of code where the ownership, copyright and
licensing is not clear and explicit. The same applies (with different
details) to any self-respecting free or open source project. Your
"public domain" lack of license is likely to limit and restrict use of
your code far more than a liberal BSD-style license.

>
>> it is perhaps the most unhelpful way to release code, since it is so
>> unclear.
>
> No, there's nothing unclear. It's as clear as Shakespeare's
> "Hamlet". That what it is. The only restriction (in *some*
> countries) is that they don't recognize a right to do that.
> So, use CC0 as a fallback.

No one has the right to use CC0 on the code - only the copyright owner
can give that right.

>
>> It certainly does not mean the code will always be available,
>> or that anyone can use it as they want.
>
> It means exactly that. That's as good as it gets. No
> list of restrictions.
>
>> And yes, I greatly prefer to be able to use the hardware I can get now,
>> or have bought in recent years, to trying to dig out something 30 years
>> old from a landfill and hope that it might still work.
>
> And if I ever wanted to get to the top of Mount Everest,
> I'd take a damned helicopter.
>
> What other pointless activities do you personally do?
> Ever gone skating? Skiing?
>

As I have said repeatedly, there is nothing at all wrong with writing
code or making systems with these kinds of artificial restrictions if
you are doing it for fun, for the challenge, for learning or interest.
Those are perfectly good reasons for doing anything (anything legal,
anyway!). It is only the characterisation of it as being important or
useful to which I object.

> If you're content to let people tell you what you can or
> can't do for the rest of your life, on your own damned
> computer, go for it. Personally I'm planning on switching
> to PDOS when it becomes viable. I'll probably be switching
> to EBCDIC too. Even on the x64. I have been using
> command line and micro-emacs my whole adult life in
> preparation for the switch.
>

Well, enjoy yourself.

> The state public domain software has reached to date
> is interesting. As you noted, there's a viable SQL
> database available. What else?
>

No, there is not a viable SQL database available (AFAIK) - sqllite is
not an SQL database. It is a library providing a local file-based
storage for a single program at a time but with a limited form of
sql-like access to the data. It is a popular and useful library, but
not a database.

I think most people who publish code as "public domain" haven't really
thought about it and don't understand the ramifications - they just want
to say "people can use this code freely, either on its own or mixed with
their own code". I believe most people who publish code under the GPL
or BSD licenses mean that too - and are equally lax about the details.
(That's fair enough, of course - being interested in programming does
not mean a person is interested in software licenses. And for small
projects and little bits of code, it usually doesn't matter.)

[Kaz Kylheku]

On 2021-04-06, muta...@gmail.com <muta...@gmail.com> wrote:
> On Tuesday, April 6, 2021 at 4:28:42 PM UTC+10, David Brown wrote:
>
>> > So you could boot PDOS, have access to a Smaller-C-like
>> > compiler, be able to compile GCC, which in turn can be
>> > used to compile Linux.
>> >
>> Or I could boot Linux, run real gcc of a reasonable vintage, and compile
>> Linux and whatever else I want in the comfort of a good system using all
>> the hardware I have and all the software I want, and a top-rank compiler.
>>
>> I regularly make software for systems smaller than the hardware you plan
>> to support (although one system I have now has 1 MB ram, 4 MB flash and
>> a 600 MHz processor - it's huge by my regular standards). I do it in
>> the way all sane developers write code for such systems - I write it on
>> a PC and use a cross-compiler.
>
> Yes, if you're happy to use copyrighted software and
> modern hardware there is no need to care about the
> progress of the public domain solutions.
>
> But I was very happy to be able to replace copyrighted
> ucpp with pdcc in the last 24 hours when I received a
> needed bug fix.
>
> Others are slapping copyrights on their works for
> reasons that make sense to them.

Such as, oh, that being the law? In many jurisdictions, you cannot
repudiate copyright; a work can pass into the public domain when
copyright expires.

A statement like "I'm assigning this work to the public domain" as the
only license is of questionable legal status. Questionable enough
to prevent the software from being redistributed and used by some
people.

> I am sourcing copyright-free works for reasons that
> make sense to me.
>
> The two groups will never have a meeting of the minds.

Vacuously so, simply because it requires two functioning minds.

[Kaz Kylheku]

On 2021-04-06, muta...@gmail.com <muta...@gmail.com> wrote:
> On Tuesday, April 6, 2021 at 6:58:02 PM UTC+10, David Brown wrote:
>> Pretty much everything anyone writes or
>> creates, anywhere, is covered by copyright.
>
> Yes, that is the default unless you explicitly release it
> to the public domain.

It's painfully obvious you've not put in so much as two minutes of
research into this topic.

[muta...@gmail.com]

On Tuesday, April 6, 2021 at 10:45:05 PM UTC+10, David Brown wrote:

> >> The posts that you make to Usenet are copyrighted
> >
> > That is not clear.

> Well, I am not a lawyer - and certainly not fully versed in all
> jurisdictions. However, you don't need a copyright statement or any
> kind of registration to own copyright to something you produce - it
> merely needs the work to be copyrightable material that you create. The
> only possible point of question is how much of a post is your own
> creation rather than other people's, and whether it is substantial
> enough to count as copyrightable.

I have seen an actual lawyer explain that posts on
message boards are not subject to copyright, in his
opinion, but to know for sure you need a judge to
decide, and even then it's not totally clear, as it can
be appealed, overturned, and then there are more
than one jurisdiction.

> >> - in most countries, you automatically own the
> >> copyright to everything you write
> >
> > Yes, but in most countries you can relinquish those
> > rights so that it is in the same state as Shakespeare's
> > "Hamlet".
> >
> And as I pointed out, in some countries you cannot.

Yes, SOME. Which doesn't include the most important
market - the US. And I told you how to overcome the
problem in those SOME countries too.

> >> unless someone (such as an employer)
> >> has greater rights. In some jurisdictions you can't avoid copyright or
> >> "give something to public domain".
> >
> > For those situations you can say "or use the CC0".
> > There is absolutely no need to "give up" and go to
> > the effort to write the word "copyright" instead.
> >
> Copyright is not "giving up". It is /owning/ up - it is saying "I made
> this".

If you want to say "I made this" all you need to do is
say "written by Paul Edwards" or whatever. I do that
in all my code.

Slapping the word "copyright" on it is a separate act.
It is explicitly saying I am most definitely NOT giving
up my rights to this work that I produced, I am
retaining them. If you want to know what you can do
with MY COPYRIGHTED WORK, read on. Maybe ask
your lawyer to read it too.

Given that you have implicit copyright for the last
few decades, there is no need to emphasize that
fact and scare people off. What is needed is for
you to do your utmost to RELINQUISH that copyright.
And you do that with an explicit "released to the
public domain". That will cover MOST places, including
the important US market.

For the rest, simply say "or you may choose to follow CC0".

> Then you use the license you want to give people whatever rights
> you want them to have.

If you believe a license is required, then using CC0.
No need to write the word "copyright". CC0 is an
attempt to ensure people you are doing your best
to relinquish your implicit copyright.

> >> In others, when you have labelled
> >> something "public domain" there is little to stop someone else taking
> >> the code and claiming it as theirs
> >
> > That's nonsense. You can take any code from anyone
> > at all and claim it as your own. Proving that you were
> > the original author, and thus it is public domain (or
> > your specific license) is a separate issue.
> >
> As the saying goes, possession is nine tenths of the law. If you have
> published code with copyright messages and dates, and someone else
> claims it is theirs, then it is a relatively simple matter for you to
> prove that you are in the right.

Writing the word "copyright" instead of "public domain"
does ABSOLUTELY NOTHING to prove the above.

> If you have explicitly said "I don't
> care what happens to this code or who takes it - it is not /my/ code",
> then why would any court in the world rule against someone who said
> "okay, if you don't want it, /I'll/ have it" ?

That's not what "public domain" means. If there is a
dispute, and you can establish that you were the
author, then it's the authors wishes that count. If the
author wants you to pay $5 million for every line of
code you reuse, that's up to them. If they say "you
can do whatever you want", that's up to them too.

"public domain" doesn't mean "unowned", it means
"owned by the public".

> I am not suggesting it
> would be /legal/ for anyone to claim ownership of your public domain
> code - I am suggesting that if anyone tried it, they'd have a good
> chance of getting away with it (especially if they have a bigger bank
> account than you ).

Equally as true as if they had made it GPL v2 or any
other license.

> >> - certainly you'd have an uphill
> >> battle in the courts to regain any kind of control.
> >
> > There is no longer any control once it is released
> > to the public domain. Nobody bothers to dig up
> > Shakespeare to ask for his consent to copy large
> > chunks of "Hamlet".
> >
> They don't need his consent, or anyone else's. But no one can claim
> ownership of his texts because the position is well established.

You're conflating two separate things.

1. You don't need consent, because it is public domain.
2. No-one is disputing who the original author is.

> >> I really don't understand some people's obsession with public domain -
> >
> > I don't understand people's obsession with trying to
> > dismiss copyright-free code, with zero restrictions
> > whatsoever as being inferior to some stupid license
> > telling what you can or can't do. Obviously it's their
> > work and they are free to do what they want. But
> > that doesn't mean that restrictions are superior to
> > absence of restrictions.

> For a great many purposes, a clear license saying how code can be used
> is vastly superior to code with no license that says nothing. A lot of

It's not merely "no license", it's an explicit "released to
the public domain" (backed up by CC0 - a LICENSE - if
you want to cover SOME countries). If you don't say
anything at all, you are correct - if it was published in
the last few decades, the material is implicitly
copyrighted, so you have no idea what you can do
with it, and you should assume nothing. If you
actually worked for Microsoft and could see their
source code, I bet it just says "copyright Microsoft,
all rights reserved", and that's it. No license. You're
not allowed to use this code at all.

> companies will not make use of code where the ownership, copyright and
> licensing is not clear and explicit.

That's perfectly fine too. My public domain code is
very clear and explicit.

> The same applies (with different
> details) to any self-respecting free or open source project. Your
> "public domain" lack of license is likely to limit and restrict use of
> your code far more than a liberal BSD-style license.

Only if the people in the project think like you and have
some ulterior motive that they are trying to prevent public
domain code from being available.

Regardless, I saw explicit mention on the GNU website
that public domain code could be incorporated into a
GPL project (which is true - it can actually be
incorporated ANYWHERE - same as Shakespeare's
"Hamlet").

> >> it is perhaps the most unhelpful way to release code, since it is so
> >> unclear.
> >
> > No, there's nothing unclear. It's as clear as Shakespeare's
> > "Hamlet". That what it is. The only restriction (in *some*
> > countries) is that they don't recognize a right to do that.
> > So, use CC0 as a fallback.

> No one has the right to use CC0 on the code - only the copyright owner
> can give that right.

Of course. So if you are worried about covering the
SOME countries (ie not the US), you will need to
explicitly say CC0 fallback.

> > What other pointless activities do you personally do?
> > Ever gone skating? Skiing?
> >
> As I have said repeatedly, there is nothing at all wrong with writing
> code or making systems with these kinds of artificial restrictions if
> you are doing it for fun, for the challenge, for learning or interest.
> Those are perfectly good reasons for doing anything (anything legal,
> anyway!). It is only the characterisation of it as being important or
> useful to which I object.

Well that's unclear. If you wish to target modern
z/OS, what options do you have for C compiler
and C runtime library?

If you're creating a new platform and wish to
recoup any development costs by being the
sole provider of the software, at least to start
with, binary only, what OS can you use as a
starting base?

I'm not familiar enough with the market to know
what the possibilities are. That's someone else's
problem. Even when I was writing PDPCLIB, I was
asked why I was writing something that comes
free with every C compiler. It was only years later
when Hercules was written and MVS 3.8J was
revived that suddenly there was a very good answer
to that question.

I also don't even know who is currently using the
code. I know a company used my public domain
Zmodem code because they sent me some bug
fixes. But they didn't want any public recognition
of that work.

> I think most people who publish code as "public domain" haven't really
> thought about it and don't understand the ramifications - they just want

I think YOU either don't understand what public
domain means, or you understand perfectly but
have an ulterior motive to dissuade people from
making code available with no strings attached.

> to say "people can use this code freely, either on its own or mixed with
> their own code". I believe most people who publish code under the GPL
> or BSD licenses mean that too - and are equally lax about the details.

No, that's not true of GPL/BSD either. They have very
clear things they expect you to do. In the case of GPL
a very long list of things for your legal team to digest.

> (That's fair enough, of course - being interested in programming does
> not mean a person is interested in software licenses. And for small
> projects and little bits of code, it usually doesn't matter.)

If it doesn't matter, then don't write "copyright", write
"public domain", or the job will never be done - the
public will never own a piece of code that has that
functionality.

BFN. Paul.

[muta...@gmail.com]

On Wednesday, April 7, 2021 at 12:31:14 AM UTC+10, Kaz Kylheku wrote:
> > But I was very happy to be able to replace copyrighted
> > ucpp with pdcc in the last 24 hours when I received a
> > needed bug fix.
> >
> > Others are slapping copyrights on their works for
> > reasons that make sense to them.

> Such as, oh, that being the law?

No, there is no law requiring you to write the word "copyright"
on code that you produce.

> In many jurisdictions, you cannot
> repudiate copyright;

Some, not many, and not the most important market.
And you STILL don't need to write the word "copyright",
you can STILL write the words "released to the public
domain" to cover the important markets and you can
STILL use CC0 with no attempt to claim copyright.

> a work can pass into the public domain when
> copyright expires.

Sure.

> A statement like "I'm assigning this work to the public domain" as the
> only license is of questionable legal status.

Not in jurisdictions like the US. You're deliberately
engaging in scare-mongering to try to prevent
public domain code from being made available.

> Questionable enough
> to prevent the software from being redistributed and used by some
> people.

Only people who fall for your scare-mongering.

> > I am sourcing copyright-free works for reasons that
> > make sense to me.
> >
> > The two groups will never have a meeting of the minds.

> Vacuously so, simply because it requires two functioning minds.

Oh, we both have functioning minds. So did both sides
of the Cold War. One side was just peddling an evil
ideology.

>>> Pretty much everything anyone writes or
>>> creates, anywhere, is covered by copyright.

>> Yes, that is the default unless you explicitly release it
>> to the public domain.

> It's painfully obvious you've not put in so much as two minutes of
> research into this topic.

It's painfully obvious that you are making up complete
crap to try to prevent public domain code from being
made available.

What's your ulterior motive?

BFN. Paul.

[David Brown]

On 06/04/2021 22:47, muta...@gmail.com wrote:
> On Tuesday, April 6, 2021 at 10:45:05 PM UTC+10, David Brown wrote:
>
>>>
>> And as I pointed out, in some countries you cannot.
>
> Yes, SOME. Which doesn't include the most important
> market - the US. And I told you how to overcome the
> problem in those SOME countries too.
>

Is there anyone else interested in your project (excluding Chris
Thomasson, who seems happy to try absolutely anything - his enthusiasm
and curiosity knows no bounds)? If not, then I guess that attitude
makes sense - you need only care about your own country, since it is the
/only/ market. But I hope you realise that this is an international
newsgroup, and while there might be more here from the USA than any
other one country, a lot of the regulars are from many other places.
Telling us that the US is the "most important", that "American English"
is the universal language, that "American ASCII" is all we ever need on
a keyboard - it doesn't win friends.

(I'm snipping the stuff about public domain. I am convinced you don't
understand the issues involved, but I am equally convinced that you are
determined that you know all you need to know and have made all the
decisions you want to make. So there is no point in further discussion
there, especially not in this group. If you think your project here is
going to have any relevance to others, especially outside your country,
then I recommend you talk to a good lawyer who understands international
copyright laws and licencing laws. Other than that - it's your project,
you do as you want.)

>>>
>> As I have said repeatedly, there is nothing at all wrong with writing
>> code or making systems with these kinds of artificial restrictions if
>> you are doing it for fun, for the challenge, for learning or interest.
>> Those are perfectly good reasons for doing anything (anything legal,
>> anyway!). It is only the characterisation of it as being important or
>> useful to which I object.
>
> Well that's unclear. If you wish to target modern
> z/OS, what options do you have for C compiler
> and C runtime library?

I'd imagine people would use the z/OS C compiler from IBM. I am not at
all familiar with that OS or tools on it, but a few seconds of googling
suggests that good, modern C (i.e., not just an outdated version) and
C++ tools (amongst many other languages) are in standard use. Certainly
no one who spends their money on an IBM mainframe is going to piddle
around with "Smaller C", a decades old version of gcc, or whatever else
you are trying to use. (It looks to me like current gcc supports that
target, but again I am unfamiliar with such systems.)

And people who buy IBM mainframes are not allergic to running software
with copyright notices.

>
> If you're creating a new platform and wish to
> recoup any development costs by being the
> sole provider of the software, at least to start
> with, binary only, what OS can you use as a
> starting base?

I can't find any sense in that question.

>
> I think YOU either don't understand what public
> domain means, or you understand perfectly but
> have an ulterior motive to dissuade people from
> making code available with no strings attached.

Please do not accuse me of things you do not understand.

Public domain is sometimes okay for small bits of code - the kind of
thing anyone could have written, but getting it from somewhere else and
using it without acknowledgement or considering licences is quicker and
easier. It can also be a choice for reference or example code. It is
not suitable for software that is bigger, more important, or more unique.

>
>> to say "people can use this code freely, either on its own or mixed with
>> their own code". I believe most people who publish code under the GPL
>> or BSD licenses mean that too - and are equally lax about the details.
>
> No, that's not true of GPL/BSD either. They have very
> clear things they expect you to do. In the case of GPL
> a very long list of things for your legal team to digest.

I know that. I said that I believe most people who publish code under
the GPL or a BSD license do not understand the licenses fully.

>
>> (That's fair enough, of course - being interested in programming does
>> not mean a person is interested in software licenses. And for small
>> projects and little bits of code, it usually doesn't matter.)
>
> If it doesn't matter, then don't write "copyright", write
> "public domain", or the job will never be done - the
> public will never own a piece of code that has that
> functionality.
>

The public does not own code that is "public domain". /Nobody/ does.
The "public" cannot sell the code, or re-licence it - they don't own it.

[Keith Thompson]

David Brown <david...@hesbynett.no> writes:
[...]

> Public domain is sometimes okay for small bits of code - the kind of
> thing anyone could have written, but getting it from somewhere else and
> using it without acknowledgement or considering licences is quicker and
> easier. It can also be a choice for reference or example code. It is
> not suitable for software that is bigger, more important, or more unique.

The maintainers of SQLite, which they claim has over a trillion
databases in active use, might disagree with you.

Presumably they would do so in a forum that discusses intellectual
property rather than in comp.lang.c.

[muta...@gmail.com]

On Wednesday, April 7, 2021 at 8:17:05 AM UTC+10, David Brown wrote:

> > Yes, SOME. Which doesn't include the most important
> > market - the US. And I told you how to overcome the
> > problem in those SOME countries too.
> >
> Is there anyone else interested in your project (excluding Chris
> Thomasson, who seems happy to try absolutely anything - his enthusiasm
> and curiosity knows no bounds)? If not, then I guess that attitude
> makes sense - you need only care about your own country, since it is the
> /only/ market.

First of all, I'm a global citizen, but "my country" is
Australia, not the US.

Secondly, I have a number of projects, I assume you
are referring to just PDOS/PDPCLIB.

I don't know for sure who is using my software. I can
only report the cases I know of. PDPCLIB is both used
and modified by mainframe enthusiasts.

If you're talking about PDOS, besides myself, the most
major contributor was an 18-year-old girl from Slovakia
called Alica, who was phenomenally productive, and
then suddenly disappeared just as she was about to
spend a solid 2 months break on PDOS.

I jokingly said that she was assassinated by Microsoft's
goons, but it is quite disturbing that she disappeared.

Now the most major contributor is another person from
Slovakia, who provided pdmake and pdcc.

The most major contributor to the OS side of the MVS
port was from the US (I think he was born in Austria
though). Lovingly hand-crafted assembler from someone
who knew the lot. 5000 lines of code. He has since died,
but before he died he took the code in a direction I didn't
want to go in, so work had effectively stopped anyway.

Another person who submitted a lot of code to PDOS
was another Australian.

A German (I think) helped doing the testing of the
AmigaDOS port of PDPCLIB so that I didn't need to
even have an Amiga. He also gave advice on code
changes, and set up a non-gcc compiler.

It was an Australian who got the 80386 protected
mode switch code to work, decades ago. I was
stuck at the time, as I had no diagnosis information
as to why my code wasn't working.

A French guy provided vital S/370 assembler to get
the VSE port of PDPCLIB (and thus GCCVSE) to work.

A British guy got the CMS port of PDPCLIB (and thus
GCCCMS) to work. I think he burnt out 3 CPUs
endlessly rebuilding GCCCMS.

Another British guy got the MUSIC port of PDPCLIB
(and thus GCCMUS) to work. He has since died.

Numerous other people have provided technical
information I required to progress.

An American provided a crucial concept for the
future of MVS/380 - "separate memory".

A British guy (I think) provided a crucial concept of
intercepting SVC 120 in Hercules rather than the OS,
allowing VSE/380 to exist.

An American guy made great improvements to
CMS to allow nice parameters, which PDPCLIB
was then able to use. I think I made the actual
code changes, with him explaining what I needed
to do. He worked with me to make VM/380 too.

An American used GCCMVS to create KICKS, a
replacement for CICS. A massive amount of work.

> But I hope you realise that this is an international
> newsgroup, and while there might be more here from the USA than any
> other one country, a lot of the regulars are from many other places.
> Telling us that the US is the "most important",

It is where most commercial code comes from, and
thus it is indeed the most important market for me.

I don't want there to be any misunderstanding by
Americans that there is any restriction on this code.
That means "released to the public domain".

> that "American English" is the universal language,

You're not aware that English is considered to be a
global language? When I went to the Louvre, the
poor guy at the bag check-in said "Do you speak
English" and was relieved when I did.

You're not aware that English is *defined* by common
usage and that the Americans swamp the British,
Irish, Australians, Canadians and New Zealanders
combined?

> that "American ASCII" is all we ever need on
> a keyboard - it doesn't win friends.

It's a starting point. I'm happy for people to add
extra keys to their keyboards.

> (I'm snipping the stuff about public domain. I am convinced you don't
> understand the issues involved, but I am equally convinced that you are
> determined that you know all you need to know and have made all the
> decisions you want to make. So there is no point in further discussion
> there, especially not in this group.

You might want to look in the mirror.

> If you think your project here is
> going to have any relevance to others, especially outside your country,
> then I recommend you talk to a good lawyer who understands international
> copyright laws and licencing laws. Other than that - it's your project,
> you do as you want.)

Maybe you can not be a hypocrite and give the same
puerile advice to everyone else who has ever written
code.

> >> As I have said repeatedly, there is nothing at all wrong with writing
> >> code or making systems with these kinds of artificial restrictions if
> >> you are doing it for fun, for the challenge, for learning or interest.
> >> Those are perfectly good reasons for doing anything (anything legal,
> >> anyway!). It is only the characterisation of it as being important or
> >> useful to which I object.
> >
> > Well that's unclear. If you wish to target modern
> > z/OS, what options do you have for C compiler
> > and C runtime library?

> I'd imagine people would use the z/OS C compiler from IBM. I am not at
> all familiar with that OS or tools on it, but a few seconds of googling
> suggests that good, modern C (i.e., not just an outdated version) and
> C++ tools (amongst many other languages) are in standard use. Certainly
> no one who spends their money on an IBM mainframe is going to piddle
> around with "Smaller C", a decades old version of gcc, or whatever else
> you are trying to use. (It looks to me like current gcc supports that
> target, but again I am unfamiliar with such systems.)
>
> And people who buy IBM mainframes are not allergic to running software
> with copyright notices.

Not everyone wants to buy an IBM mainframe to
write IBM software. That's almost like a ... MONOPOLY.

> > If you're creating a new platform and wish to
> > recoup any development costs by being the
> > sole provider of the software, at least to start
> > with, binary only, what OS can you use as a
> > starting base?

> I can't find any sense in that question.

It's a potential use. You've designed a new computer
system. With a new processor perhaps.

Now you need an OS to run on that. It will require
customization at some level. OSes don't run out of
the box on new hardware.

You want to protect that investment in customization
by close-sourcing your commercial offering. Do you
write your OS from scratch or is there existing code
you can use to help you?

> > I think YOU either don't understand what public
> > domain means, or you understand perfectly but
> > have an ulterior motive to dissuade people from
> > making code available with no strings attached.

> Please do not accuse me of things you do not understand.

Take your own advice.

> Public domain is sometimes okay for small bits of code - the kind of
> thing anyone could have written, but getting it from somewhere else and
> using it without acknowledgement or considering licences is quicker and
> easier. It can also be a choice for reference or example code. It is
> not suitable for software that is bigger, more important, or more unique.

Nonsense. It is totally suitable, and your scaremongering
belies a probable ulterior motive.

> >> to say "people can use this code freely, either on its own or mixed with
> >> their own code". I believe most people who publish code under the GPL
> >> or BSD licenses mean that too - and are equally lax about the details.
> >
> > No, that's not true of GPL/BSD either. They have very
> > clear things they expect you to do. In the case of GPL
> > a very long list of things for your legal team to digest.

> I know that. I said that I believe most people who publish code under
> the GPL or a BSD license do not understand the licenses fully.

I suspect they do, and they subscribe to the underlying
philosophy.

> >> (That's fair enough, of course - being interested in programming does
> >> not mean a person is interested in software licenses. And for small
> >> projects and little bits of code, it usually doesn't matter.)
> >
> > If it doesn't matter, then don't write "copyright", write
> > "public domain", or the job will never be done - the
> > public will never own a piece of code that has that
> > functionality.
> >
> The public does not own code that is "public domain".

Yes they do.

> /Nobody/ does.
> The "public" cannot sell the code, or re-licence it - they don't own it.

Yes, any member of the public is free to sell it.

You can sell "Hamlet" for whatever price you want too.

If anyone doesn't know you can get it for free, that's
their problem.

You're not restricted to just charge for the printing costs
of "Hamlet". You can mark it up by $5 million per copy
if you want. Shakespeare won't complain. He's not legally
entitled to. Nor am I if you choose to make a pile of cash
from PDOS, with or without modification. Go for it. I'll
even send you a zip file with the source code if you don't
know how to use a browser.

BFN. Paul.

[David Brown]

On 07/04/2021 03:04, muta...@gmail.com wrote:
> On Wednesday, April 7, 2021 at 8:17:05 AM UTC+10, David Brown wrote:
>
>>> Yes, SOME. Which doesn't include the most important
>>> market - the US. And I told you how to overcome the
>>> problem in those SOME countries too.
>>>
>> Is there anyone else interested in your project (excluding Chris
>> Thomasson, who seems happy to try absolutely anything - his enthusiasm
>> and curiosity knows no bounds)? If not, then I guess that attitude
>> makes sense - you need only care about your own country, since it is the
>> /only/ market.
>
> First of all, I'm a global citizen, but "my country" is
> Australia, not the US.
>

I can only base replies on what you write here, and the impression that
gives. There has been little or nothing to indicate that what you are
doing is anything other than a single-person project, perhaps with
occasional small contributions from random other people. What I see
from your posts includes:

You want to use C90 everywhere, but don't know much about C90.

You want ISO to change its standards to suit a toy compiler for a long
outdated system, but don't understand what ISO is, what standards are,
or why they are important.

You want to write software that will be usable on systems like the
Commodore 64 that few people have touched in decades, and where the
hardware exists only in museums and attics. (There are still people who
enjoy Commodore 64 games, but they use emulators like Mame.) You want
your development tools to run on such machines - without understanding
that even in its heyday, serious developers did not run development
tools on those kinds of systems. They used cross-development tools
running on workstations (with Unix or VMS, I expect). But you want all
these tools to run on such systems, which you know little about, even
though no one is interested in using them. And you want to restrict and
limit all your tools and software (and even international language
standards) in order to do so.

You want to re-write everything - operating systems, development tools,
BIOS'es, and even new language variants - based on a religious beliefs
about C90, public domain software, and your conviction that the whole
software world has been "wrong" for decades, and only your vision will
fix it. (By "religious" I don't mean there are any gods involved - I
mean convictions that are based on faith alone, and where the prime
response to questioning or reasoning is to double-up on the faith.)


It now appears there are more people involved than the impression you
gave. That's good, but does not change the overall impression.


A lot of people work on projects like this - each with their own
personal strong convictions about what is important, and the driving
force for them. It might be religion, or nationalism, or licensing, or
efficiency, or security, or nostalgia. Some are reasonably successful,
most fail to be anything more than curiosities and abandoned github
projects.

What makes such projects succeed? It is not the driving force itself -
that, I think, is almost irrelevant. There are three key factors.

One is that there needs to be a project leadership that communicates
well and works well with others. Often the leader and founder is so
convinced of their own vision that they have trouble accepting anyone
else's view - even the slightest deviation is viewed as heretical and
wrong. This quickly alienates any others in the project.

Another is that there must be users for the project. FreeDOS, osFree
and ReactOS work because there are people other than the developers who
are interested in using the results to run old software on new hardware.
Others work because they inspire research or ideas. But unless you
have a body of people other than the developers who /want/ to use the
software, and /can/ use it, and find it better than alternatives, then
the project will go nowhere in the end. You might get a few curious
people to boot up the system, and say "Hey, that's cool!" - but they
won't use it for anything. Part of that involves running on relatively
modern hardware that people have.

The third factor is realistic ambition. It's fine to stretch a bit -
aim beyond the horizon, but not for the other side of the world. Target
/one/ system until that is working. Pick /one/ program to write at a
time. Base it on the developers' knowledge, interest, and abilities.
An OS designed to "run absolutely everywhere" is guaranteed to run
nowhere in practice.

>
>> I'd imagine people would use the z/OS C compiler from IBM. I am not at
>> all familiar with that OS or tools on it, but a few seconds of googling
>> suggests that good, modern C (i.e., not just an outdated version) and
>> C++ tools (amongst many other languages) are in standard use. Certainly
>> no one who spends their money on an IBM mainframe is going to piddle
>> around with "Smaller C", a decades old version of gcc, or whatever else
>> you are trying to use. (It looks to me like current gcc supports that
>> target, but again I am unfamiliar with such systems.)
>>
>> And people who buy IBM mainframes are not allergic to running software
>> with copyright notices.
>
> Not everyone wants to buy an IBM mainframe to
> write IBM software. That's almost like a ... MONOPOLY.
>

/Everyone/ who buys an IBM mainframe is happy to run IBM software
(though they will likely also run software from other companies). You
don't buy the hardware when you buy an IBM mainframe - you buy into the
ecosystem.

>>> If you're creating a new platform and wish to
>>> recoup any development costs by being the
>>> sole provider of the software, at least to start
>>> with, binary only, what OS can you use as a
>>> starting base?
>
>> I can't find any sense in that question.
>
> It's a potential use. You've designed a new computer
> system. With a new processor perhaps.
>
> Now you need an OS to run on that. It will require
> customization at some level. OSes don't run out of
> the box on new hardware.
>
> You want to protect that investment in customization
> by close-sourcing your commercial offering. Do you
> write your OS from scratch or is there existing code
> you can use to help you?
>

If you are talking about a general purpose computer, then you either
port Linux (you don't /need/ to close the source to protect your
investment), or a BSD. (Apple was quite successful at doing that.)

[muta...@gmail.com]

On Wednesday, April 7, 2021 at 7:04:03 PM UTC+10, David Brown wrote:

> You want to use C90 everywhere, but don't know much about C90.

Both things are correct to some degree.

> You want ISO to change its standards to suit a toy compiler for a long
> outdated system, but don't understand what ISO is, what standards are,
> or why they are important.

Well, it's the same approach I have to GCC 3.2.3
and Hercules 3.07. I want to carefully nurture
these things rather than chase the latest and
greatest versions of everything.

> You want to write software that will be usable on systems like the
> Commodore 64 that few people have touched in decades, and where the
> hardware exists only in museums and attics. (There are still people who
> enjoy Commodore 64 games, but they use emulators like Mame.) You want
> your development tools to run on such machines - without understanding
> that even in its heyday, serious developers did not run development
> tools on those kinds of systems. They used cross-development tools
> running on workstations (with Unix or VMS, I expect). But you want all
> these tools to run on such systems, which you know little about, even
> though no one is interested in using them. And you want to restrict and
> limit all your tools and software (and even international language
> standards) in order to do so.

Yes, this is basically correct.

I want an "escape plan" in case I am ever stuck on a C64,
for reasons which are not apparent to me at the moment.

Note that the C128 came with a Z80 coprocessor. My
current "escape plan" is to replace the Z80 with an
80386, and let THAT run PDOS, including FAT-32 etc,
and SDCC, and micro-emacs, all being channeled onto
the C64 screen, and allowing C64 applications (stored
as .exe files), to have the entire 64k, minus some stubs,
to themselves.

> You want to re-write everything - operating systems, development tools,
> BIOS'es, and even new language variants - based on a religious beliefs
> about C90, public domain software, and your conviction that the whole
> software world has been "wrong" for decades, and only your vision will
> fix it. (By "religious" I don't mean there are any gods involved - I
> mean convictions that are based on faith alone, and where the prime
> response to questioning or reasoning is to double-up on the faith.)

Not rewrite everything. Just the basics to get up and
running so that you are empowered to program your
way out of whatever predicament you find yourself in.

I'm not trying to write a GUI, or even bothering to look
for one.

> A lot of people work on projects like this - each with their own
> personal strong convictions about what is important, and the driving
> force for them. It might be religion, or nationalism, or licensing, or
> efficiency, or security, or nostalgia. Some are reasonably successful,
> most fail to be anything more than curiosities and abandoned github
> projects.

I have been working on mine since the mid-90s.
And working on other projects at the same time
and before.

> What makes such projects succeed? It is not the driving force itself -
> that, I think, is almost irrelevant. There are three key factors.

It depends what you mean by "succeed". I celebrated
a milestone a year or so ago when I was able to use
PDOS/386 to rebuild PDOS/386.

After what - 25 years?

> One is that there needs to be a project leadership that communicates
> well and works well with others. Often the leader and founder is so
> convinced of their own vision that they have trouble accepting anyone
> else's view - even the slightest deviation is viewed as heretical and
> wrong. This quickly alienates any others in the project.

When Alica from Slovakia came on board, I just stepped
aside and let her do whatever she wanted. She was the
one willing to devote the time. I wasn't.

She added virtual memory which I found a bit disturbing,
and I told her so, but she had her heart set on loading all
executables, even ones without relocation information,
so I just let her have her way.

She also added support for DLLs, which I didn't like.

I held her back from exposing PDOS to DBCS when
she developed LFN support.

If she hadn't been assassinated by Microsoft's goons,
I have no idea where we would have ended up.

Here's what I wrote to the new Slovakian guy on
2021-03-27:

I will be focusing on “generic”, so you can basically
do whatever you want in “src”. I’ll just make sure
that it compiles on my system.

> Another is that there must be users for the project. FreeDOS, osFree
> and ReactOS work because there are people other than the developers who
> are interested in using the results to run old software on new hardware.
> Others work because they inspire research or ideas. But unless you
> have a body of people other than the developers who /want/ to use the
> software, and /can/ use it, and find it better than alternatives, then
> the project will go nowhere in the end. You might get a few curious
> people to boot up the system, and say "Hey, that's cool!" - but they
> won't use it for anything. Part of that involves running on relatively
> modern hardware that people have.

Selling the product is beyond my scope. If someone
sees a market opportunity, they are free to use PDOS
as a base, slap whatever license they want on it, and
satisfy the perceived market demand.

> The third factor is realistic ambition. It's fine to stretch a bit -
> aim beyond the horizon, but not for the other side of the world. Target
> /one/ system until that is working. Pick /one/ program to write at a
> time. Base it on the developers' knowledge, interest, and abilities.
> An OS designed to "run absolutely everywhere" is guaranteed to run
> nowhere in practice.

I did pick one system. 8086. Because that's what I
had access to at the time. Later I supported 80386
with the same code base, wondering whether C90
was really portable or not.

Decades later, armed with a C compiler and a C
library under my control, I finally started learning
some information about the specific hardware
I was actually using (S/3X0) and wrote a new OS
for that, as a fresh rewrite. No existing PDOS
code was used.

And then I wondered why there was nothing at
all in common between the two systems.

And I paused.

Years later (just recently) I *believe* I have answered
that question, with PDOS-generic.

> >> I'd imagine people would use the z/OS C compiler from IBM. I am not at
> >> all familiar with that OS or tools on it, but a few seconds of googling
> >> suggests that good, modern C (i.e., not just an outdated version) and
> >> C++ tools (amongst many other languages) are in standard use. Certainly
> >> no one who spends their money on an IBM mainframe is going to piddle
> >> around with "Smaller C", a decades old version of gcc, or whatever else
> >> you are trying to use. (It looks to me like current gcc supports that
> >> target, but again I am unfamiliar with such systems.)
> >>
> >> And people who buy IBM mainframes are not allergic to running software
> >> with copyright notices.
> >
> > Not everyone wants to buy an IBM mainframe to
> > write IBM software. That's almost like a ... MONOPOLY.
> >
> /Everyone/ who buys an IBM mainframe is happy to run IBM software
> (though they will likely also run software from other companies). You
> don't buy the hardware when you buy an IBM mainframe - you buy into the
> ecosystem.

I think you misunderstood me.

I want to write IBM software.

I don't want to buy an IBM mainframe.

I don't want to buy an IBM OS.

I don't want to buy an IBM compiler.

> >>> If you're creating a new platform and wish to
> >>> recoup any development costs by being the
> >>> sole provider of the software, at least to start
> >>> with, binary only, what OS can you use as a
> >>> starting base?
> >
> >> I can't find any sense in that question.
> >
> > It's a potential use. You've designed a new computer
> > system. With a new processor perhaps.
> >
> > Now you need an OS to run on that. It will require
> > customization at some level. OSes don't run out of
> > the box on new hardware.
> >
> > You want to protect that investment in customization
> > by close-sourcing your commercial offering. Do you
> > write your OS from scratch or is there existing code
> > you can use to help you?
> >
> If you are talking about a general purpose computer, then you either
> port Linux (you don't /need/ to close the source to protect your
> investment),

I disagree. That's *exactly* what I would do to protect
my investment. If you disagree, you can do whatever
you want. But don't expect me, or everyone else in the
world, to agree with your position. We don't.

> or a BSD. (Apple was quite successful at doing that.)

That's their choice to use copyrighted software as a
base and follow the conditions.

Do you remember writing this?

> I once had to use a "C" compiler for an 8-bit CISC microcontroller which
> supported arrays, and supported structs, but did not support arrays of
> structs or structs containing arrays. (It had countless other known
> limitations, and uncountably many unknown bugs and limitations.) It was
> not an amateur compiler - it was an expensive tool, sold by the
> microcontroller manufacturer.

I assume this was a closed-source product.

Did you ever ask yourself "why didn't these people pick up
an existing public domain C compiler, make the changes
required to support their microcontroller, and then start
selling it? That way it wouldn't have had all these language
limitations, right from the start!"?

You know what the correct answer to that question is?

"There isn't an existing public domain C compiler."

Some/many companies would rather start from scratch
than follow someone else's stupid rules.

There's an existing public domain C runtime library though.
Hopefully my Slovakian friend will come through with a
C compiler one day. He's already made a start with pdcc,
and I was surprised how many lines of code were required
to just do preprocessing.

Regardless, the next company that comes along can start
with an existing C runtime library and preprocessor, even
if they have to write the rest themselves. No acknowledgement
is required. Some companies would presumably like to keep
it a secret that they're using and selling something they
downloaded from the internet. Now they can.

BFN. Paul.

[Bart]

On 07/04/2021 11:32, muta...@gmail.com wrote:

> I want an "escape plan" in case I am ever stuck on a C64,
> for reasons which are not apparent to me at the moment.
>
> Note that the C128 came with a Z80 coprocessor. My
> current "escape plan" is to replace the Z80 with an
> 80386,

The C64 used a 6502 I think. But C64s are rare. C128 (which I've never
heard of) must be rarer. As for ripping out a Z80 and replacing it with
an 80386 which is physically quite different, I think brain surgery
would be simpler!

If you are ever going to be 'stuck' with anything, then an IBM PC would
be the most likely, as so many were made.

[muta...@gmail.com]

On Wednesday, April 7, 2021 at 8:54:28 PM UTC+10, Bart wrote:

> > I want an "escape plan" in case I am ever stuck on a C64,
> > for reasons which are not apparent to me at the moment.
> >
> > Note that the C128 came with a Z80 coprocessor. My
> > current "escape plan" is to replace the Z80 with an
> > 80386,

> The C64 used a 6502 I think. But C64s are rare. C128 (which I've never
> heard of) must be rarer. As for ripping out a Z80 and replacing it with
> an 80386 which is physically quite different, I think brain surgery
> would be simpler!

I didn't mean that. I meant wait for the manufacturer
to do that when the 80386 (or some other suitable
processor) became available, assuming people were
still interested in the 6502.

Basically it's a variation on the theme David mentioned
about using a cross-compiler. The cross-compiler
would be built in, effectively.

It doesn't have to be the exact C64 situation. It's
more a class of problems. What options exist?
The same as "how do I make this machine use
EBCDIC instead of ASCII?". Basically I'm trying
to find out the technical barriers.

When I came across the technical barrier (16 MiB)
in S/370, that was preventing me from doing large
C compiles, I found a way to break the barrier.

It is only in the last week or so that I realized I
could ask a hardware manufacturer to add an
80386 (or 68000 etc) coprocessor to my C64.

I think it is reasonable that if I can find (or
write) so much public domain code that I come
up against a 64k limit (just for an executable)
that I should be able to ask for a coprocessor
and more memory.

> If you are ever going to be 'stuck' with anything, then an IBM PC would
> be the most likely, as so many were made.

While ever people are going to use 8-bit CPUs,
even in 2021, I would like a plan on what to do
if I'm placed in front of one with no other options,
because I was abducted by a psychopath or
any other reason I haven't thought of (e.g.
God turning up and zapping all 16-bit and
above CPUs because hey, absolute power
corrupts absolutely).

BFN. Paul.

[David Brown]

On 07/04/2021 12:32, muta...@gmail.com wrote:
> On Wednesday, April 7, 2021 at 7:04:03 PM UTC+10, David Brown wrote:
>
>
>> You want to write software that will be usable on systems like the
>> Commodore 64 that few people have touched in decades, and where the
>> hardware exists only in museums and attics. (There are still people who
>> enjoy Commodore 64 games, but they use emulators like Mame.) You want
>> your development tools to run on such machines - without understanding
>> that even in its heyday, serious developers did not run development
>> tools on those kinds of systems. They used cross-development tools
>> running on workstations (with Unix or VMS, I expect). But you want all
>> these tools to run on such systems, which you know little about, even
>> though no one is interested in using them. And you want to restrict and
>> limit all your tools and software (and even international language
>> standards) in order to do so.
>
> Yes, this is basically correct.
>
> I want an "escape plan" in case I am ever stuck on a C64,
> for reasons which are not apparent to me at the moment.
>

The remotest hints of this being at all realistic are not apparent to
me. If you could at least say that you /have/ a Commodore 64, there
could be some sense here. There are probably a hundred million working
PC's and laptops of various ages in your country, including those that
are outdated, retired, in landfills, etc. It's unlikely that there are
more than a hundred working C64's - along with that many working
old-fashioned TV's to work as displays and tape recorders for storage.
In what circumstances do you think you might have a desperate need for a
computer for doing C development, but a C64 is the only think you can get?

Some people prefer cars from the 1980's over modern ones, because they
can fix them themselves, and it's all mechanical and amenable to
emergency fixes with duct tape and string, unlike modern cars with
electronics everywhere. I can appreciate that attitude for cars. The
same does not apply to computers from the 1980's.

> Note that the C128 came with a Z80 coprocessor. My
> current "escape plan" is to replace the Z80 with an
> 80386, and let THAT run PDOS, including FAT-32 etc,
> and SDCC, and micro-emacs, all being channeled onto
> the C64 screen, and allowing C64 applications (stored
> as .exe files), to have the entire 64k, minus some stubs,
> to themselves.

I am an electronics engineer and an embedded programmer. Long ago, as a
teenager, I taught myself assembly on the Z80 and wrote my first
disassembler for a 6502 (the processor in a C64). Let me assure you
that your escape plan will not work. There are a large number of
reasons for this, but you could start with looking at pictures of Z80
and 80386 processors and noting that they are completely different shapes.

>>>> And people who buy IBM mainframes are not allergic to running software
>>>> with copyright notices.
>>>
>>> Not everyone wants to buy an IBM mainframe to
>>> write IBM software. That's almost like a ... MONOPOLY.
>>>
>> /Everyone/ who buys an IBM mainframe is happy to run IBM software
>> (though they will likely also run software from other companies). You
>> don't buy the hardware when you buy an IBM mainframe - you buy into the
>> ecosystem.
>
> I think you misunderstood me.

That might well be true.

>
> I want to write IBM software.

Only IBM write IBM software. If you want to write IBM software, get a
job working for them.

>
> I don't want to buy an IBM mainframe.
>
> I don't want to buy an IBM OS.
>
> I don't want to buy an IBM compiler.

Do you mean you want to write code that is compiled for IBM mainframes,
without using any IBM software or hardware? Why? Which owners of IBM
mainframes would be interested in running that software? You might well
write some C code that is portable enough to work on Z/OS systems - but
pretty much anyone wanting to use it would want to compile it with
standard toolchains (like IBM's, or gcc).

>
>>>>> If you're creating a new platform and wish to
>>>>> recoup any development costs by being the
>>>>> sole provider of the software, at least to start
>>>>> with, binary only, what OS can you use as a
>>>>> starting base?
>>>
>>>> I can't find any sense in that question.
>>>
>>> It's a potential use. You've designed a new computer
>>> system. With a new processor perhaps.
>>>
>>> Now you need an OS to run on that. It will require
>>> customization at some level. OSes don't run out of
>>> the box on new hardware.
>>>
>>> You want to protect that investment in customization
>>> by close-sourcing your commercial offering. Do you
>>> write your OS from scratch or is there existing code
>>> you can use to help you?
>>>
>> If you are talking about a general purpose computer, then you either
>> port Linux (you don't /need/ to close the source to protect your
>> investment),
>
> I disagree. That's *exactly* what I would do to protect
> my investment. If you disagree, you can do whatever
> you want. But don't expect me, or everyone else in the
> world, to agree with your position. We don't.
>

Lots of people make a lot of money with Linux-based systems, and other
free and open source software. For example, you could sell the new
computer system and processor - sell the hardware, not the software. By
having the software open source, if the hardware is popular you'll have
other people who want to improve the software, making the whole thing
better so that you sell more hardware.

>> or a BSD. (Apple was quite successful at doing that.)
>
> That's their choice to use copyrighted software as a
> base and follow the conditions.

Yes - and the conditions are not onerous.

>
> Do you remember writing this?
>
>> I once had to use a "C" compiler for an 8-bit CISC microcontroller which
>> supported arrays, and supported structs, but did not support arrays of
>> structs or structs containing arrays. (It had countless other known
>> limitations, and uncountably many unknown bugs and limitations.) It was
>> not an amateur compiler - it was an expensive tool, sold by the
>> microcontroller manufacturer.
>
> I assume this was a closed-source product.

Yes.

>
> Did you ever ask yourself "why didn't these people pick up
> an existing public domain C compiler, make the changes
> required to support their microcontroller, and then start
> selling it? That way it wouldn't have had all these language
> limitations, right from the start!"?

No - but I /did/ ask myself "why didn't these people pick up an existing
C compiler and port it to that microcontroller?"

I know why they would not have picked a public domain compiler - they
are a serious company, and could not afford the legal risks of basing
their commercial product on software of unknown or unclear provenance,
ownership and licensing. I know why they would not pick an open source
compiler (GPL or BSD) - there were no realistic bases to start from at
that time, which was many years ago. (If they were doing this now, SDCC
would have been the obvious choice - under the GPL.) What makes a lot
less sense is why they did not license a compiler base from one of the
many commercial closed-source compiler companies at that time, or
commission one of them to make a decent tool.

>
> You know what the correct answer to that question is?
>
> "There isn't an existing public domain C compiler."
>

I gave the correct answer above.

> Some/many companies would rather start from scratch
> than follow someone else's stupid rules.
>
> There's an existing public domain C runtime library though.
> Hopefully my Slovakian friend will come through with a
> C compiler one day. He's already made a start with pdcc,
> and I was surprised how many lines of code were required
> to just do preprocessing.
>
> Regardless, the next company that comes along can start
> with an existing C runtime library and preprocessor, even
> if they have to write the rest themselves. No acknowledgement
> is required. Some companies would presumably like to keep
> it a secret that they're using and selling something they
> downloaded from the internet. Now they can.
>

Companies that want to keep these things a secret can do so already -
they don't need public domain software. They can do so legally with
BSD-style licenses. That is one of the points of the BSD licenses - it
means companies /can/ use that code in closed-source work. They can do
it legally and safely, all clear and simple.

[David Brown]

On 07/04/2021 13:17, muta...@gmail.com wrote:
> On Wednesday, April 7, 2021 at 8:54:28 PM UTC+10, Bart wrote:
>
>>> I want an "escape plan" in case I am ever stuck on a C64,
>>> for reasons which are not apparent to me at the moment.
>>>
>>> Note that the C128 came with a Z80 coprocessor. My
>>> current "escape plan" is to replace the Z80 with an
>>> 80386,
>
>> The C64 used a 6502 I think. But C64s are rare. C128 (which I've never
>> heard of) must be rarer. As for ripping out a Z80 and replacing it with
>> an 80386 which is physically quite different, I think brain surgery
>> would be simpler!
>
> I didn't mean that. I meant wait for the manufacturer
> to do that when the 80386 (or some other suitable
> processor) became available, assuming people were
> still interested in the 6502.

So by "escape plan", you mean a parallel universe in the late 1980's ?
At the risk of making unjustified accusations, have you been licking
cane toads?

>
> Basically it's a variation on the theme David mentioned
> about using a cross-compiler. The cross-compiler
> would be built in, effectively.

No, it is not a variation on that theme.

>
> It doesn't have to be the exact C64 situation. It's
> more a class of problems. What options exist?
> The same as "how do I make this machine use
> EBCDIC instead of ASCII?". Basically I'm trying
> to find out the technical barriers.
>
> When I came across the technical barrier (16 MiB)
> in S/370, that was preventing me from doing large
> C compiles, I found a way to break the barrier.
>
> It is only in the last week or so that I realized I
> could ask a hardware manufacturer to add an
> 80386 (or 68000 etc) coprocessor to my C64.

And did you find one that is so strapped for work that they would take
you up on that? Noting that neither 80386 nor 68000 cpus have been made
for twenty years or so?

>
> I think it is reasonable that if I can find (or
> write) so much public domain code that I come
> up against a 64k limit (just for an executable)
> that I should be able to ask for a coprocessor
> and more memory.

Don't you think it is more reasonable just to use a computer that has
more than 64K memory?

>
>> If you are ever going to be 'stuck' with anything, then an IBM PC would
>> be the most likely, as so many were made.
>
> While ever people are going to use 8-bit CPUs,
> even in 2021, I would like a plan on what to do
> if I'm placed in front of one with no other options,
> because I was abducted by a psychopath or
> any other reason I haven't thought of (e.g.
> God turning up and zapping all 16-bit and
> above CPUs because hey, absolute power
> corrupts absolutely).
>

8-bit cpus are still very much in use, but in embedded systems - not for
"computers" and not for development.

Buy yourself an Arduino starter kit, and have some fun doing real 8-bit
development instead of trying to imagine the most nerdy nightmares possible.

[Kaz Kylheku]

On 2021-04-07, Bart <b...@freeuk.com> wrote:
> C128 (which I've never heard of)

That's amazing!

[Kaz Kylheku]

On 2021-04-06, muta...@gmail.com <muta...@gmail.com> wrote:

>> Questionable enough
>> to prevent the software from being redistributed and used by some
>> people.
>
> Only people who fall for your scare-mongering.

This is an idiotic way to debate; kindly refrain. I didn't create
this situation, and don't necessarily agree with it.

There is rational reason to harbor a fear.

I've run into the following situation.

I used a piece of someone's code in a program, and that code was
assigned to the public domain with no clear license.

This caused some OS distro people to raise a fuss over my (otherwise
properly licensed) program. I learned about the situation while
googling about the program.

If you don't want your code to face adoption barriers, you have
to license it in a way that paranoid people are happy with: paranoid
people like corporate legal departments and OS distro people.

Maybe they are wrong, but you can't fix those people and their beliefs.

So if you persist with this nonsense of assigning to the public
domain, you're potentially throwing up barriers against adoption of your
code, and possibly causing problems to people who use it, who are not
aware of the issues.

Don't be "that guy" playing cowboy with licensing.

[Bart]

On 07/04/2021 19:05, Kaz Kylheku wrote:
> On 2021-04-07, Bart <b...@freeuk.com> wrote:
>> C128 (which I've never heard of)
>
> That's amazing!

Well if I was aware of it once, then I've long forgotten it.

(I wasn't involved in that world, except that my job for a couple of
years included designing and prototyping dozens of my boss's ideas of a
low-cost competitor in that market.

We never ended up with a viable product, but we did sell business micros
like this one:
https://nosher.net/archives/computers/pcw_1982_12_006a?idx=OS.

It's quite likely however that I saw some of these machines lying in
pieces around his office.)

[Peter 'Shaggy' Haywood]

Groovy hepcat Scott Lurndal was jivin' in comp.lang.c on Tue, 6 Apr 2021
04:42 am. It's a cool scene! Dig it.

> The only local member of parliament around here would be George
> Clinton.

This convo just got Funkadelic!

--


----- Dig the NEW and IMPROVED news sig!! -----


-------------- Shaggy was here! ---------------
Ain't I'm a dawg!!

[muta...@gmail.com]

On Thursday, April 8, 2021 at 12:39:44 AM UTC+10, David Brown wrote:

> >> You want to write software that will be usable on systems like the
> >> Commodore 64 that few people have touched in decades, and where the
> >> hardware exists only in museums and attics. (There are still people who
> >> enjoy Commodore 64 games, but they use emulators like Mame.) You want
> >> your development tools to run on such machines - without understanding
> >> that even in its heyday, serious developers did not run development
> >> tools on those kinds of systems. They used cross-development tools
> >> running on workstations (with Unix or VMS, I expect). But you want all
> >> these tools to run on such systems, which you know little about, even
> >> though no one is interested in using them. And you want to restrict and
> >> limit all your tools and software (and even international language
> >> standards) in order to do so.
> >
> > Yes, this is basically correct.
> >
> > I want an "escape plan" in case I am ever stuck on a C64,
> > for reasons which are not apparent to me at the moment.
> >
> The remotest hints of this being at all realistic are not apparent to
> me.

I think the basic problem is that you seem to have some
confidence that you know the entire current marketplace,
and can predict the future marketplace, and are not
worried about the past.

I on the other hand openly admit that I don't know either
current, past or future.

Out of the blue something can happen like RISC, where
suddenly something as mundane as multiplication, a
single instruction, suddenly becomes expensive as it
requires a function call. Or if it wasn't multiplication it
was something else like that.

Maybe there will be Quantum computers that are a
million times faster than conventional processors,
but Quantum memory is limited to 32k because of
some quark issue.

Or maybe it will be an x64 processor has a 64k
processor cache, and someone realizes that they
can squeeze their application into 64k of memory,
by using 16-bit pointers in 16-bit protected mode,
and the processor allows you to fix the area of
memory that is cached, and everyone is scrambling
to fit into that limit to have their application run
10 times faster.

Or maybe someone will actually build a Babbage
machine. Guess what? They did.

There is a class of problem.

> If you could at least say that you /have/ a Commodore 64, there
> could be some sense here. There are probably a hundred million working
> PC's and laptops of various ages in your country, including those that
> are outdated, retired, in landfills, etc. It's unlikely that there are
> more than a hundred working C64's - along with that many working
> old-fashioned TV's to work as displays and tape recorders for storage.
> In what circumstances do you think you might have a desperate need for a
> computer for doing C development, but a C64 is the only think you can get?

It may not be exactly that. I just know that if the
situation ever arises that I need an OS for a
limited memory machine, that my OS is too big.
I don't know whether to #ifdef a whole lot of
stuff out, or whether there is some other solution.

Or even whether I will be forced to resort to assembler.
But I wouldn't have thought assembler would be
necessary so long as the compilers generate good
code. So do I need to give up my C library instead?
What options do I have?

It is only fairly recently that I realized I could add a
coprocessor.

> Some people prefer cars from the 1980's over modern ones, because they
> can fix them themselves, and it's all mechanical and amenable to
> emergency fixes with duct tape and string, unlike modern cars with
> electronics everywhere. I can appreciate that attitude for cars. The
> same does not apply to computers from the 1980's.

I don't need a physical computer to exist at all. I already
target the S/380, and I am interested in targeting the
8086+ with 16-bit segment shifts.

> > Note that the C128 came with a Z80 coprocessor. My
> > current "escape plan" is to replace the Z80 with an
> > 80386, and let THAT run PDOS, including FAT-32 etc,
> > and SDCC, and micro-emacs, all being channeled onto
> > the C64 screen, and allowing C64 applications (stored
> > as .exe files), to have the entire 64k, minus some stubs,
> > to themselves.

> I am an electronics engineer and an embedded programmer. Long ago, as a
> teenager, I taught myself assembly on the Z80 and wrote my first
> disassembler for a 6502 (the processor in a C64). Let me assure you
> that your escape plan will not work. There are a large number of
> reasons for this, but you could start with looking at pictures of Z80
> and 80386 processors and noting that they are completely different shapes.

Again, it's a theoretical machine.

But it can exist "for real" as an emulator, which is where
most people run their C64 software anyway. That's where
S/380 runs too.

I don't particularly care whether someone builds a real
machine or not. I'm not in the hardware business.

> >>>> And people who buy IBM mainframes are not allergic to running software
> >>>> with copyright notices.
> >>>
> >>> Not everyone wants to buy an IBM mainframe to
> >>> write IBM software. That's almost like a ... MONOPOLY.
> >>>
> >> /Everyone/ who buys an IBM mainframe is happy to run IBM software
> >> (though they will likely also run software from other companies). You
> >> don't buy the hardware when you buy an IBM mainframe - you buy into the
> >> ecosystem.
> >
> > I think you misunderstood me.

> That might well be true.
> >
> > I want to write IBM software.

> Only IBM write IBM software. If you want to write IBM software, get a
> job working for them.

Ok, if you want to be strict with terminology, I want to
write my own software to run on an IBM OS and hardware.

> > I don't want to buy an IBM mainframe.
> >
> > I don't want to buy an IBM OS.
> >
> > I don't want to buy an IBM compiler.

> Do you mean you want to write code that is compiled for IBM mainframes,
> without using any IBM software or hardware?

Yes.

> Why?

Because it's there. So was z/VSE. The blasted thing wouldn't
die, so I was required to learn it to some extent in order to
make C a universal language (by my definition).

> Which owners of IBM
> mainframes would be interested in running that software?

You'll have to speak to the marketing department
about that.

Perhaps ones who don't have an IBM C compiler.
I can remember one guy complaining that his
company had saved money by getting rid of the
IBM C compiler, and another guy saying why do
you keep complaining about that when there's
a free one available (ie mine), and he replied that
he had difficulty installing it.

Whether that is smoke indicating fire, I don't know,
and I don't particularly care. Marketing is not my job.

> You might well
> write some C code that is portable enough to work on Z/OS systems - but
> pretty much anyone wanting to use it would want to compile it with
> standard toolchains (like IBM's, or gcc).

If they want to go those alternate routes, that's fine
by me.

> >>>>> If you're creating a new platform and wish to
> >>>>> recoup any development costs by being the
> >>>>> sole provider of the software, at least to start
> >>>>> with, binary only, what OS can you use as a
> >>>>> starting base?
> >>>
> >>>> I can't find any sense in that question.
> >>>
> >>> It's a potential use. You've designed a new computer
> >>> system. With a new processor perhaps.
> >>>
> >>> Now you need an OS to run on that. It will require
> >>> customization at some level. OSes don't run out of
> >>> the box on new hardware.
> >>>
> >>> You want to protect that investment in customization
> >>> by close-sourcing your commercial offering. Do you
> >>> write your OS from scratch or is there existing code
> >>> you can use to help you?
> >>>
> >> If you are talking about a general purpose computer, then you either
> >> port Linux (you don't /need/ to close the source to protect your
> >> investment),
> >
> > I disagree. That's *exactly* what I would do to protect
> > my investment. If you disagree, you can do whatever
> > you want. But don't expect me, or everyone else in the
> > world, to agree with your position. We don't.
> >
> Lots of people make a lot of money with Linux-based systems, and other
> free and open source software.

And lots more make money from closed-source
systems.

Again, if you are expecting everyone to agree with
you, it will never happen. You'll never convince me,
for starters.

And apparently I'll never convince you either.

> For example, you could sell the new
> computer system and processor - sell the hardware, not the software. By

Or I could sell both. My choice.

> having the software open source, if the hardware is popular you'll have
> other people who want to improve the software, making the whole thing
> better so that you sell more hardware.

If I think that way, that's what I will do. It will depend on
what the marketing department says will make my
company the most money.

Public domain software allows me to go whichever
route *I* wish to go.

> >> or a BSD. (Apple was quite successful at doing that.)
> >
> > That's their choice to use copyrighted software as a
> > base and follow the conditions.

> Yes - and the conditions are not onerous.

I disagree. And Apple may well realize that when they
get taken to court and sued for $5 trillion by some
BSD jackass whose name was omitted from the
documentation because an Apple software engineer
missed it.

No such problem with public domain software.

> > Do you remember writing this?
> >
> >> I once had to use a "C" compiler for an 8-bit CISC microcontroller which
> >> supported arrays, and supported structs, but did not support arrays of
> >> structs or structs containing arrays. (It had countless other known
> >> limitations, and uncountably many unknown bugs and limitations.) It was
> >> not an amateur compiler - it was an expensive tool, sold by the
> >> microcontroller manufacturer.
> >
> > I assume this was a closed-source product.

> Yes.
> >
> > Did you ever ask yourself "why didn't these people pick up
> > an existing public domain C compiler, make the changes
> > required to support their microcontroller, and then start
> > selling it? That way it wouldn't have had all these language
> > limitations, right from the start!"?

> No - but I /did/ ask myself "why didn't these people pick up an existing
> C compiler and port it to that microcontroller?"

That's a separate question, and requires a separate answer.

> I know why they would not have picked a public domain compiler - they

No, you don't know that at all. You just completely made
that up.

> are a serious company, and could not afford the legal risks of basing
> their commercial product on software of unknown or unclear provenance,
> ownership and licensing.

No, that is you scaremongering again, trying to cover up
your ulterior motive to try to prevent the public gaining
access to technology.

> I know why they would not pick an open source
> compiler (GPL or BSD) - there were no realistic bases to start from at
> that time, which was many years ago. (If they were doing this now, SDCC
> would have been the obvious choice - under the GPL.) What makes a lot

OR, even if it did, the company may have thought the
same way that I do, and doesn't want to end up being
taken to court by some GPL jackass saying "this is
my copyrighted code (true) and in my interpretation,
and certainly my intent, of rule number 563, you can't
do what you just did, and you owe me $50 trillion,
the same as that BSD jackass got".

And the company has to face a judge who says "you
can see there is a very clear copyright here, the onus
is on you to prove you didn't violate the intent of this
long list of rules written in Swahili - you have 30 seconds
to convince me - BTW, what is software anyway? - your
time starts now". With a pack of lawyers on both sides.

> less sense is why they did not license a compiler base from one of the
> many commercial closed-source compiler companies at that time, or
> commission one of them to make a decent tool.

Perhaps because they were charging extortionate
prices and the company figured they could write
their own, and pass the costs on to the consumer.

If public domain software had been able to lower
the input costs, hopefully capitalism would have
passed those onto the consumer.

Of course if your ulterior motive is that you're a
commie and trying to take down evil companies,
well, just say so instead of pretending there is
something unclear about "public domain".

> > You know what the correct answer to that question is?
> >
> > "There isn't an existing public domain C compiler."
> >
> I gave the correct answer above.

No, you didn't.

> > Some/many companies would rather start from scratch
> > than follow someone else's stupid rules.
> >
> > There's an existing public domain C runtime library though.
> > Hopefully my Slovakian friend will come through with a
> > C compiler one day. He's already made a start with pdcc,
> > and I was surprised how many lines of code were required
> > to just do preprocessing.
> >
> > Regardless, the next company that comes along can start
> > with an existing C runtime library and preprocessor, even
> > if they have to write the rest themselves. No acknowledgement
> > is required. Some companies would presumably like to keep
> > it a secret that they're using and selling something they
> > downloaded from the internet. Now they can.
> >
> Companies that want to keep these things a secret can do so already -
> they don't need public domain software. They can do so legally with
> BSD-style licenses. That is one of the points of the BSD licenses - it
> means companies /can/ use that code in closed-source work. They can do
> it legally and safely, all clear and simple.

https://en.wikipedia.org/wiki/BSD_licenses

All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the <copyright holder>.


So one single advert by Apple in the New York Times that
says "buy OS X, it's finger-lickin good!" and the entire BSD
clan gets to sue for $50 trillion each.

Enough with your lies about BSD and other virus-licensed
software, and your lies about public domain.

Just spit out your ulterior motive so we can both move on
to our respective campaigns. Mine to donate source code
to the public rather than be a dog in a manger. Yours, god
knows what.

BFN. Paul.

[muta...@gmail.com]

On Thursday, April 8, 2021 at 12:49:28 AM UTC+10, David Brown wrote:

> On 07/04/2021 13:17, muta...@gmail.com wrote:
> > On Wednesday, April 7, 2021 at 8:54:28 PM UTC+10, Bart wrote:
> >
> >>> I want an "escape plan" in case I am ever stuck on a C64,
> >>> for reasons which are not apparent to me at the moment.
> >>>
> >>> Note that the C128 came with a Z80 coprocessor. My
> >>> current "escape plan" is to replace the Z80 with an
> >>> 80386,
> >
> >> The C64 used a 6502 I think. But C64s are rare. C128 (which I've never
> >> heard of) must be rarer. As for ripping out a Z80 and replacing it with
> >> an 80386 which is physically quite different, I think brain surgery
> >> would be simpler!
> >
> > I didn't mean that. I meant wait for the manufacturer
> > to do that when the 80386 (or some other suitable
> > processor) became available, assuming people were
> > still interested in the 6502.

> So by "escape plan", you mean a parallel universe in the late 1980's ?

It's just a possibility - maybe for some reason the
80386 was as cheap as chips (made in the USSR)
but the 6502 was expensive (made in Switzerland),
so you had a viable situation.

Even though that never happened in the 1980s,
maybe it will be repeated in 2030s. I can't predict,
even if you have a crystal ball.

> At the risk of making unjustified accusations, have you been licking
> cane toads?

I just think differently from most people. That's why
S/380 wasn't invented by Mick Jagger.

> > Basically it's a variation on the theme David mentioned
> > about using a cross-compiler. The cross-compiler
> > would be built in, effectively.

> No, it is not a variation on that theme.

Quibbling.

> > It doesn't have to be the exact C64 situation. It's
> > more a class of problems. What options exist?
> > The same as "how do I make this machine use
> > EBCDIC instead of ASCII?". Basically I'm trying
> > to find out the technical barriers.
> >
> > When I came across the technical barrier (16 MiB)
> > in S/370, that was preventing me from doing large
> > C compiles, I found a way to break the barrier.
> >
> > It is only in the last week or so that I realized I
> > could ask a hardware manufacturer to add an
> > 80386 (or 68000 etc) coprocessor to my C64.

> And did you find one that is so strapped for work that they would take
> you up on that? Noting that neither 80386 nor 68000 cpus have been made
> for twenty years or so?

It can be an x64 instead. It's a theoretical problem.
CPU A can address 64k. CPU B can address 16 MiB.
There is some obscure reason (e.g. fast multiply,
or cheap, or legacy software) why CPU A is still
being used. How do you avoid CP/M licensing
charges? You can install PDOS-generic.

> > I think it is reasonable that if I can find (or
> > write) so much public domain code that I come
> > up against a 64k limit (just for an executable)
> > that I should be able to ask for a coprocessor
> > and more memory.

> Don't you think it is more reasonable just to use a computer that has
> more than 64K memory?

I don't know. Why not just use a Cray for everything?

I think I remember a story of someone in IBM saying
that they would only ever sell 7 computers or
something, which would cover the globe. No other
computers required.

I can also remember Gates saying that 640k was
enough for everyone.

Things that make sense at one point in time are
not always accurate in the future.

It took centuries before someone found something
inadequate in Newtonian law.

> >> If you are ever going to be 'stuck' with anything, then an IBM PC would
> >> be the most likely, as so many were made.
> >
> > While ever people are going to use 8-bit CPUs,
> > even in 2021, I would like a plan on what to do
> > if I'm placed in front of one with no other options,
> > because I was abducted by a psychopath or
> > any other reason I haven't thought of (e.g.
> > God turning up and zapping all 16-bit and
> > above CPUs because hey, absolute power
> > corrupts absolutely).
> >
> 8-bit cpus are still very much in use, but in embedded systems - not for
> "computers" and not for development.

They could be used for development. Maybe someone
would get some benefit from that. I don't know.

Maybe the x64 doesn't have a graphics card (blew out)
but the 8-bit CPU (like the C64) can output to a TV, so
you can continue writing your C code, continue compiling
at exactly the same speed, and the only thing strange is
that you're using a smaller screen. Better than no screen.

I don't know how that translates to CPUs that aren't part
of an actual computer system. Maybe output ANSI codes
via a serial port. I really don't know the exact circumstances.

I didn't set out to invent S/380 either. It just happened
while I was pushing the limits of S/370. Ditto AM32.

> Buy yourself an Arduino starter kit, and have some fun doing real 8-bit
> development instead of trying to imagine the most nerdy nightmares possible.

No, I'm not interested in that.

I am interested in modifying Hercules/380 so that I
can effectively have a S/380 and 80386 coprocessor
and run software targeting either processor at native
speed depending on what actual hardware I happen
to be on.

BFN. Paul.

[muta...@gmail.com]

On Thursday, April 8, 2021 at 4:27:26 AM UTC+10, Kaz Kylheku wrote:

> On 2021-04-06, muta...@gmail.com <muta...@gmail.com> wrote:
> >> Questionable enough
> >> to prevent the software from being redistributed and used by some
> >> people.
> >
> > Only people who fall for your scare-mongering.

> This is an idiotic way to debate; kindly refrain. I didn't create
> this situation, and don't necessarily agree with it.
>
> There is rational reason to harbor a fear.

There's more rational reason to harbor fear of non-PD
software. Someone is explicitly refusing to relinquish
their rights. Be afraid. Be very afraid.

> I've run into the following situation.
>
> I used a piece of someone's code in a program, and that code was
> assigned to the public domain with no clear license.

Scaremongering. That IS a clear "license" - it's an
explicit repudiation of any license.

> This caused some OS distro people to raise a fuss over my (otherwise
> properly licensed) program. I learned about the situation while
> googling about the program.
>
> If you don't want your code to face adoption barriers, you have
> to license it in a way that paranoid people are happy with: paranoid
> people like corporate legal departments and OS distro people.
>
> Maybe they are wrong, but you can't fix those people and their beliefs.

My target audience isn't the jackasses you associate with.

My target audience is a US company who refuses to
use any code that doesn't have an explicit "released
to the public domain" notice.

Exactly as I would do if I were a US company. Or
Australian company for that matter.

My target audience is also Alica from Slovakia who
turned on her new computer, was faced with a
message saying "greetings peasant. here is a long
list of things you can or can't do on your own damned
computer. you either click "agree to be a sheep" or
click "go fuck yourself Microsoft/Linus/Stallman, I'm
an ace programmer and I'll write my own damned
operating system rather than have you jackasses
tell me what I can or can't do".

She was an ace programmer, but she didn't know
how to get started. So she instead wondered surely
someone else must have been in the same situation,
and googled "public domain OS" and up popped
PDOS, and that is how we met.

I'd rather have one of her than 4 trillion virus-license
jackasses. People who know the definition of
"freedom", which isn't Stallman's sick twisted
definition. The commies had a sick, twisted
definition of "freedom" too. You know, I wouldn't
have minded the 100 million dead from communism
if they had just produced a public domain operating
system from the ashes. But all they ever managed
to do was steal from the capitalists.

> So if you persist with this nonsense of assigning to the public
> domain, you're potentially throwing up barriers against adoption of your
> code, and possibly causing problems to people who use it, who are not
> aware of the issues.
>
> Don't be "that guy" playing cowboy with licensing.

Don't be "that guy" peddling lies about public domain code.

BFN. Paul.

[David Brown]

You can't predict what will happen in 2030's, but you can make a pretty
good guess that neither the 80386 nor the 6502 will ever be relevant
again. And you /can/ learn that none of this happened in the 1980's.

It simply does not make any sense to be concerned about situations that
are so absurdly implausible. If you are worried about being kidnapped
by Dr. Who and taken back to the 1980's, it would make more sense to
spend your time on developing anti-Dalek weapons than to think about
transplanting cpus on a Commodore 64.

>
>> At the risk of making unjustified accusations, have you been licking
>> cane toads?
>
> I just think differently from most people. That's why
> S/380 wasn't invented by Mick Jagger.
>
>>> Basically it's a variation on the theme David mentioned
>>> about using a cross-compiler. The cross-compiler
>>> would be built in, effectively.
>
>> No, it is not a variation on that theme.
>
> Quibbling.

I am quibbling because it is not the same.

>
>>> It doesn't have to be the exact C64 situation. It's
>>> more a class of problems. What options exist?
>>> The same as "how do I make this machine use
>>> EBCDIC instead of ASCII?". Basically I'm trying
>>> to find out the technical barriers.
>>>
>>> When I came across the technical barrier (16 MiB)
>>> in S/370, that was preventing me from doing large
>>> C compiles, I found a way to break the barrier.
>>>
>>> It is only in the last week or so that I realized I
>>> could ask a hardware manufacturer to add an
>>> 80386 (or 68000 etc) coprocessor to my C64.
>
>> And did you find one that is so strapped for work that they would take
>> you up on that? Noting that neither 80386 nor 68000 cpus have been made
>> for twenty years or so?
>
> It can be an x64 instead. It's a theoretical problem.
> CPU A can address 64k. CPU B can address 16 MiB.
> There is some obscure reason (e.g. fast multiply,
> or cheap, or legacy software) why CPU A is still
> being used. How do you avoid CP/M licensing
> charges? You can install PDOS-generic.
>

It's a "theoretical problem" in the same sense as being asked the best
way to hunt a brontosaurus when you are provided with a bazooka, a sharp
stone, and tin of beige paint. Talking about processors and memories
does not make your "problem" any less surrealistic.

>>> I think it is reasonable that if I can find (or
>>> write) so much public domain code that I come
>>> up against a 64k limit (just for an executable)
>>> that I should be able to ask for a coprocessor
>>> and more memory.
>
>> Don't you think it is more reasonable just to use a computer that has
>> more than 64K memory?
>
> I don't know. Why not just use a Cray for everything?
>

Because I don't have a Cray, but I /do/ have a computer with more than
64K memory? Just like practically everyone else? How many people do
you think there whoe are interested in programming but only have access
to computers with 64K or less memory?

> I think I remember a story of someone in IBM saying
> that they would only ever sell 7 computers or
> something, which would cover the globe. No other
> computers required.

Yes, that's the story. Somewhere between the 1950's and now, reality
turned out differently. And if ever the world ends up with a mere 7
computers again, whether it is a Cray or a Commodore 64, or the licenses
for the software, will be the least of our concerns.

>
> I can also remember Gates saying that 640k was
> enough for everyone.

And he was wrong. Lots of people say stupid things when they should
know better. (And in both these cases, most other people in the
industry knew they were stupid things to say.) None of this means that
if /you/ predict something even stupider, it is likely to come true.

>
> Things that make sense at one point in time are
> not always accurate in the future.
>
> It took centuries before someone found something
> inadequate in Newtonian law.

Next you'll be telling us that you did poorly at school, and Einstein
did poorly at school, and therefore you too are likely to be a genius.

Please watch this: <https://www.youtube.com/watch?v=yp_l5ntikaU>. Then
cut out any ideas that might come from the same kind of "logic".

>
>>>> If you are ever going to be 'stuck' with anything, then an IBM PC would
>>>> be the most likely, as so many were made.
>>>
>>> While ever people are going to use 8-bit CPUs,
>>> even in 2021, I would like a plan on what to do
>>> if I'm placed in front of one with no other options,
>>> because I was abducted by a psychopath or
>>> any other reason I haven't thought of (e.g.
>>> God turning up and zapping all 16-bit and
>>> above CPUs because hey, absolute power
>>> corrupts absolutely).
>>>
>> 8-bit cpus are still very much in use, but in embedded systems - not for
>> "computers" and not for development.
>
> They could be used for development. Maybe someone
> would get some benefit from that. I don't know.

If you don't know, then trust people who might know a little better.
No, development is not done on 8-bit processors now, and has not been
done for a long time. Even for hobby and home usage the use of 8-bit
systems as development platforms was gone by the early nineties. 16-bit
DOS and Windows survived far longer than could be justified, but by the
turn of the century development work and programming was done almost
exclusively in 32-bit (or larger) environments. I can't rule out very
niche use-cases, or the odd enthusiast who preferred their old BBC Micro
to any x86 PC, but these would definitely have been outliers.

8-bit cpus are, as I said, still in common use in embedded systems.
Their market share is dropping fast in new products - a 32-bit
microcontroller can be bought for about a third of a dollar. But many
embedded systems are slow to change, and 8-bit (and even 4-bit)
microcontrollers are produced in vast numbers. However, no one does
development /on/ those devices - they do the development on PC's and
transfer the binaries for testing, debugging, and running.

>
> Maybe the x64 doesn't have a graphics card (blew out)
> but the 8-bit CPU (like the C64) can output to a TV, so
> you can continue writing your C code, continue compiling
> at exactly the same speed, and the only thing strange is
> that you're using a smaller screen. Better than no screen.

You are going to enormous efforts to prepare for something that is
utterly unrealistic. It makes more sense to practice writing with your
feet in case you lose both your hands in an accident.

>
> I don't know how that translates to CPUs that aren't part
> of an actual computer system. Maybe output ANSI codes
> via a serial port. I really don't know the exact circumstances.
>

The whole thing is vastly more involved, and less realisable, than you
seem to think. The electrical signals involved are totally different.
You have been watching too much TV, where electronics systems are
repaired by teenagers flashing a welding torch at them then sticking
bits together with duct tape and chewing gum. Reality is not like that.

> I didn't set out to invent S/380 either. It just happened
> while I was pushing the limits of S/370. Ditto AM32.

To my knowledge, there never was an S/380.

>
>> Buy yourself an Arduino starter kit, and have some fun doing real 8-bit
>> development instead of trying to imagine the most nerdy nightmares possible.
>
> No, I'm not interested in that.
>
> I am interested in modifying Hercules/380 so that I
> can effectively have a S/380 and 80386 coprocessor
> and run software targeting either processor at native
> speed depending on what actual hardware I happen
> to be on.
>

This would be on S/380 hardware that has never existed, with an 80386
processor that hasn't been produced for decades, combined in a way that
is not possible and which no one would want even if it /were/ possible?
All so that you could run code natively on either processor - code you
want to write in a portable language that can target any machine,
combined with development tools that will run on any machine, so that
the results will be the same regardless of what processor it runs on?

I am sure you can have some fun gluing the Hercules S/370 emulator onto
Bochs or QEMU for x86 emulation. But I can't imagine how it could be
anything other than a fun challenge.

[David Brown]

On 08/04/2021 10:23, muta...@gmail.com wrote:
> On Thursday, April 8, 2021 at 12:39:44 AM UTC+10, David Brown wrote:
>
>>>> You want to write software that will be usable on systems like the
>>>> Commodore 64 that few people have touched in decades, and where the
>>>> hardware exists only in museums and attics. (There are still people who
>>>> enjoy Commodore 64 games, but they use emulators like Mame.) You want
>>>> your development tools to run on such machines - without understanding
>>>> that even in its heyday, serious developers did not run development
>>>> tools on those kinds of systems. They used cross-development tools
>>>> running on workstations (with Unix or VMS, I expect). But you want all
>>>> these tools to run on such systems, which you know little about, even
>>>> though no one is interested in using them. And you want to restrict and
>>>> limit all your tools and software (and even international language
>>>> standards) in order to do so.
>>>
>>> Yes, this is basically correct.
>>>
>>> I want an "escape plan" in case I am ever stuck on a C64,
>>> for reasons which are not apparent to me at the moment.
>>>
>> The remotest hints of this being at all realistic are not apparent to
>> me.
>
> I think the basic problem is that you seem to have some
> confidence that you know the entire current marketplace,
> and can predict the future marketplace, and are not
> worried about the past.

No, I don't claim to know all that. I merely claim to have a fairly
realistic idea of some aspects of it.

>
> I on the other hand openly admit that I don't know either
> current, past or future.

I know that computers that are only available as collectors' pieces are
in the past.

I think you might be projecting your ignorance to others.

There are plenty of aspects of the computer world where I know little -
especially of the mainframe world, and my knowledge of computing before
the late 1980's is primarily limited to home computing.

>
> Out of the blue something can happen like RISC, where
> suddenly something as mundane as multiplication, a
> single instruction, suddenly becomes expensive as it
> requires a function call. Or if it wasn't multiplication it
> was something else like that.

On most RISC systems, multiplication has always been a single
instruction - usually single cycle (for integer operations, at least).
On smaller or more limited RISC systems it might be done in software
(inline using shifts and adds, or with a function call). But the same
applies to CISC systems. And even on CISC systems where it was one
instruction, it used to be implemented as a multi-cycle operation
perhaps involving microcode sequences.

It is not unusual for (smaller or older) RISC cpus to have no division
instruction - but it is not unusual for their software implementations
to be faster than the hardware in equivalent CISC cpus. I believe that
in one of the 68k family members it was discovered that a software
division routine worked faster than the hardware instruction.

>
> Maybe there will be Quantum computers that are a
> million times faster than conventional processors,
> but Quantum memory is limited to 32k because of
> some quark issue.

When you have /no/ idea what you are talking about, it really does not
make sense to make up random numbers.

>
> Or maybe it will be an x64 processor has a 64k
> processor cache, and someone realizes that they
> can squeeze their application into 64k of memory,
> by using 16-bit pointers in 16-bit protected mode,
> and the processor allows you to fix the area of
> memory that is cached, and everyone is scrambling
> to fit into that limit to have their application run
> 10 times faster.
>

You are in the wrong profession. With that imagination, you should be a
science fiction writer, or a politician, or something where a wild
fantasy is more useful.

> Or maybe someone will actually build a Babbage
> machine. Guess what? They did.

Please try to think /why/ this was done. Do you think it was to
generate tables for aiming cannons, as this was one of Babbage's
original aims? Do you think it was for running C compilers after
someone stole the builders' PC's? Or do you think it was a historical
project, to get a better understanding of the mechanical and
manufacturing capabilities of that time, combined with a curiosity as to
how well the machine could really work?

>
> There is a class of problem.
>
>> If you could at least say that you /have/ a Commodore 64, there
>> could be some sense here. There are probably a hundred million working
>> PC's and laptops of various ages in your country, including those that
>> are outdated, retired, in landfills, etc. It's unlikely that there are
>> more than a hundred working C64's - along with that many working
>> old-fashioned TV's to work as displays and tape recorders for storage.
>> In what circumstances do you think you might have a desperate need for a
>> computer for doing C development, but a C64 is the only think you can get?
>
> It may not be exactly that. I just know that if the
> situation ever arises that I need an OS for a
> limited memory machine, that my OS is too big.
> I don't know whether to #ifdef a whole lot of
> stuff out, or whether there is some other solution.

The solution is to get a bit of /realism/ in your life.

Sure, there is plenty of scope for a small OS - I used several far
smaller than the ones you are imagining. But these are not for
development work - they are for embedded systems.

(snipping for brevity)

Of course I expect people to agree with me - because I am giving simple,
clear facts. Note that I am not saying that you can /only/ make money
with closed source software, or should /only/ use Linux, or anything of
that sort. I am saying that some people make money using Linux-based
systems. And some people make money using BSD-based systems. Some make
money when using or writing open source software, some make money when
using or writing closed source software. There really isn't anything to
argue against here.

>
> And apparently I'll never convince you either.
>
>> For example, you could sell the new
>> computer system and processor - sell the hardware, not the software. By
>
> Or I could sell both. My choice.

Sure, there's no problem in that. And no requirement for "public
domain" software at any stage.

>
>> having the software open source, if the hardware is popular you'll have
>> other people who want to improve the software, making the whole thing
>> better so that you sell more hardware.
>
> If I think that way, that's what I will do. It will depend on
> what the marketing department says will make my
> company the most money.
>
> Public domain software allows me to go whichever
> route *I* wish to go.

Public domain software allows some options, and disallows others. The
same goes for other kinds of licences. I would not expect one license
to cover everyone's needs, any more than I would expect one OS, one
compiler or one programming language to cover everyone's needs (or even
every need for one person).

Again, I request you stop making accusations like that. I know - not
guess - I /know/ that commercial companies are often reluctant to use
"public domain" software in their own products because of unclear legal
situations. I /know/ that many open source projects will not accept
"public domain" contributions and insist on clear copyright information.
(Your earlier comment about mixing GPL and PD software was entirely
ass-backwards, showing your lack of understanding of the issues involved.)

I am fully in favour of sharing software and technology in appropriate
ways. I am fully in favour of doing it with /clear/ and /explicit/
copyright and licensing, in a way that people can be comfortable with if
everything goes sour and ends up in court, and that is understandable
for all involved from the programmer to the PHB via the company lawyer
and tax accountant trying to figure out the value of the code.

Serious groups who want to give out code as "public domain", and where
the code is heavily used, make a point of explaining exactly what they
mean, and explicitly stating what rights they are giving to others, and
what this all means legally. The best example here would be SQLite:

<https://www.sqlite.org/copyright.html>

I am not against "public domain" as such - I am against an attitude of
"Do what you want with this code - I don't care" and slapping on a
license (including "public domain") without thought or understanding,
and without considering if it really does what you think it does. For
example, for your usage I believe the Creative Commons CC0 would be more
appropriate.

>
>> I know why they would not pick an open source
>> compiler (GPL or BSD) - there were no realistic bases to start from at
>> that time, which was many years ago. (If they were doing this now, SDCC
>> would have been the obvious choice - under the GPL.) What makes a lot
>
> OR, even if it did, the company may have thought the
> same way that I do, and doesn't want to end up being
> taken to court by some GPL jackass saying "this is
> my copyrighted code (true) and in my interpretation,
> and certainly my intent, of rule number 563, you can't
> do what you just did, and you owe me $50 trillion,
> the same as that BSD jackass got".

The GPL is quite well understood - the company involved would have been
able to fulfil their obligations under that license (or if they decided
they did not want to follow it, they would not use GPL'ed code). The
same company currently sells other compilers based on GPL'ed compiler
code - perfectly legally, and with no fear of court cases.

>
> And the company has to face a judge who says "you
> can see there is a very clear copyright here, the onus
> is on you to prove you didn't violate the intent of this
> long list of rules written in Swahili - you have 30 seconds
> to convince me - BTW, what is software anyway? - your
> time starts now". With a pack of lawyers on both sides.
>

Again, your imagination is somewhat distant from reality. I'm not
suggesting that all judges and lawyers get these things right, or that
ridiculous lawsuits don't always get thrown out before reaching court.
But things go a lot smoother with a clear legal license than no
information at all.

>> less sense is why they did not license a compiler base from one of the
>> many commercial closed-source compiler companies at that time, or
>> commission one of them to make a decent tool.
>
> Perhaps because they were charging extortionate
> prices and the company figured they could write
> their own, and pass the costs on to the consumer.
>

Possibly.

> If public domain software had been able to lower
> the input costs, hopefully capitalism would have
> passed those onto the consumer.

The market for embedded development tools has certainly changed in the
last three decades, and the time of expensive but crappy tools is gone.
There are still some expensive tools around, but these tend to be very
high quality and come with other lawyer-friendly features such as
certifications and guarantees. There are "cheap-and-cheerful"
toolchains that offer simplicity of use and helpful support. And there
are free toolchains, based on gcc, llvm or sdcc (GPL, BSD and GPL
respectively).

Freely available, high quality toolchains have without doubt changed the
market situation here, to the benefit of the consumer.

There are no "public domain" toolchains of any relevance for any targets
- there is no benefit in it for either the compiler writers or the users.

If you read a little further down, you will see that that only applies
to the original 4-clause BSD license. In most cases, a "BSD-style"
license does not include an advertising clause.

>
> So one single advert by Apple in the New York Times that
> says "buy OS X, it's finger-lickin good!" and the entire BSD
> clan gets to sue for $50 trillion each.
>

As I have pointed out before, you do not know what you are talking
about. You don't even seem to have the ability to read a few paragraphs
of a Wikipedia page.

> Enough with your lies about BSD and other virus-licensed
> software, and your lies about public domain.
>
> Just spit out your ulterior motive so we can both move on
> to our respective campaigns. Mine to donate source code
> to the public rather than be a dog in a manger. Yours, god
> knows what.
>

This will be the last time I respond to a post of yours that accuses me
of lying and/or of having an "ulterior motive". Take your conspiracy
theories and your rapid fanaticism elsewhere.

[Keith Thompson]

David Brown <david...@hesbynett.no> writes:
[...]

> This will be the last time I respond to a post of yours that accuses me
> of lying and/or of having an "ulterior motive". Take your conspiracy
> theories and your rapid fanaticism elsewhere.

Given the almost complete lack of C content in this thread, why are you
responding at all? There are places to talk about public domain.
Please stop feeding the troll. (Everyone: I will not argue about the
exact meaning of "troll".)

[muta...@gmail.com]

I don't make that leap of faith. It may not even be a
full-featured 80386 with V8086. It may be the
80386EX. Maybe someone will see that it is useful
in embedded systems because there is a large
amount of public domain software available for it.

And it may not be exactly 80386. It may be some
other processor that has something useful about
it (similar to RISC). Maybe energy-savings can be
had if we return to a lower amount of supported
RAM. I heard that pacemakers were written in
assembler to squeeze everything out of it because
when you run out of battery, it requires an actual
human to be cut open. Maybe someone will invent
a pacemaker battery that lasts 100 years, but only
if you use 16k of memory.

Maybe one of these tinpot dictators like Mao will
close off their country and go for the whole
"self-reliance" thing again. Including CPUs. Maybe
it will be an African country. Maybe producing
32-bit CPUs will be a struggle. Maybe producing
RAM will be a struggle.

> And you /can/ learn that none of this happened in the 1980's.

Are you sure you know what the North Koreans
got up to in the 1980s? I've never attempted to
investigate, and even if I did, I wouldn't be
confident I had it right.

> It simply does not make any sense to be concerned about situations that
> are so absurdly implausible. If you are worried about being kidnapped
> by Dr. Who and taken back to the 1980's, it would make more sense to
> spend your time on developing anti-Dalek weapons than to think about
> transplanting cpus on a Commodore 64.

Daleks are complete fantasy. CP/M was a thing.
PDOS is bigger than CP/M. It simply won't fit in
16k. And if the computer itself is 16k, how do
you fit both an OS and applications into that
space? I guess even those computers allowed
a separate ROM, which gives the OS some space
for its own code. I haven't given any consideration
to putting PDOS on a ROM.

But these are the things I am interested in.

> >> At the risk of making unjustified accusations, have you been licking
> >> cane toads?
> >
> > I just think differently from most people. That's why
> > S/380 wasn't invented by Mick Jagger.
> >
> >>> Basically it's a variation on the theme David mentioned
> >>> about using a cross-compiler. The cross-compiler
> >>> would be built in, effectively.
> >
> >> No, it is not a variation on that theme.
> >
> > Quibbling.

> I am quibbling because it is not the same.

They are not identical, they are similar.

> > It can be an x64 instead. It's a theoretical problem.
> > CPU A can address 64k. CPU B can address 16 MiB.
> > There is some obscure reason (e.g. fast multiply,
> > or cheap, or legacy software) why CPU A is still
> > being used. How do you avoid CP/M licensing
> > charges? You can install PDOS-generic.
> >
> It's a "theoretical problem" in the same sense as being asked the best
> way to hunt a brontosaurus when you are provided with a bazooka, a sharp
> stone, and tin of beige paint. Talking about processors and memories
> does not make your "problem" any less surrealistic.

There is no technical barrier to creating a machine
with a 6502 and 68000 as above. Or a S/370
instead of 68000.

If there was a way of reviving brontosauruses, we
would indeed need a way of killing them, but I would
leave that task to someone else.

I'll be in charge of creating an OS for a 6502 processor.

And if my name was Babbage, I would have been
writing the OS down on paper, waiting for the
hardware to arrive.

> >>> I think it is reasonable that if I can find (or
> >>> write) so much public domain code that I come
> >>> up against a 64k limit (just for an executable)
> >>> that I should be able to ask for a coprocessor
> >>> and more memory.
> >
> >> Don't you think it is more reasonable just to use a computer that has
> >> more than 64K memory?
> >
> > I don't know. Why not just use a Cray for everything?
> >
> Because I don't have a Cray, but I /do/ have a computer with more than
> 64K memory? Just like practically everyone else? How many people do
> you think there whoe are interested in programming but only have access
> to computers with 64K or less memory?

I was certainly one of them at one time. I could
have actually begun writing a C runtime library
for the 6502 at that point in time. But I'm now
thinking that is a job for a coprocessor. They
eventually allowed bolting on a Z80 coprocessor,
and eventually the whole thing was more-or-less
abandoned, but just because they didn't produce
an exact piece of hardware doesn't mean the
problem doesn't exist.

They didn't produce S/380 either, but the problem
exists.

> > I think I remember a story of someone in IBM saying
> > that they would only ever sell 7 computers or
> > something, which would cover the globe. No other
> > computers required.

> Yes, that's the story. Somewhere between the 1950's and now, reality
> turned out differently. And if ever the world ends up with a mere 7
> computers again, whether it is a Cray or a Commodore 64, or the licenses
> for the software, will be the least of our concerns.

You can address those other concerns. I'm addressing
something as basic as the public owning an operating
system.

> > I can also remember Gates saying that 640k was
> > enough for everyone.

> And he was wrong. Lots of people say stupid things when they should
> know better. (And in both these cases, most other people in the
> industry knew they were stupid things to say.) None of this means that
> if /you/ predict something even stupider, it is likely to come true.

I'm not predicting anything. I'm saying I can't predict
what computers will look like in the future, and I
have imperfect knowledge about the past. But I do
know that I've been in exact situations where I didn't
have the tools I want. Actually I'm still in that situation.

> > Things that make sense at one point in time are
> > not always accurate in the future.
> >
> > It took centuries before someone found something
> > inadequate in Newtonian law.

> Next you'll be telling us that you did poorly at school, and Einstein
> did poorly at school, and therefore you too are likely to be a genius.

I don't see what relevance that has to my point that
I don't know what the future holds.

> > They could be used for development. Maybe someone
> > would get some benefit from that. I don't know.

> If you don't know, then trust people who might know a little better.

No, I don't trust anyone as being omniscient.

> No, development is not done on 8-bit processors now, and has not been

You have no way of knowing that, and I can prove
you wrong by powering on my C64 and typing in:

10 print "hello, world"
run

And doing the equivalent under an emulator amounts
to the same thing.

> done for a long time. Even for hobby and home usage the use of 8-bit
> systems as development platforms was gone by the early nineties. 16-bit
> DOS and Windows survived far longer than could be justified, but by the
> turn of the century development work and programming was done almost
> exclusively in 32-bit (or larger) environments. I can't rule out very
> niche use-cases, or the odd enthusiast who preferred their old BBC Micro
> to any x86 PC, but these would definitely have been outliers.

And what options do these "outliers" have for an
operating system?

> 8-bit cpus are, as I said, still in common use in embedded systems.
> Their market share is dropping fast in new products - a 32-bit
> microcontroller can be bought for about a third of a dollar. But many
> embedded systems are slow to change, and 8-bit (and even 4-bit)
> microcontrollers are produced in vast numbers. However, no one does
> development /on/ those devices - they do the development on PC's and
> transfer the binaries for testing, debugging, and running.

That's fine. For you. For most. In this exact year. On this
exact planet.

The theoretical problem remains.

> > Maybe the x64 doesn't have a graphics card (blew out)
> > but the 8-bit CPU (like the C64) can output to a TV, so
> > you can continue writing your C code, continue compiling
> > at exactly the same speed, and the only thing strange is
> > that you're using a smaller screen. Better than no screen.

> You are going to enormous efforts to prepare for something that is
> utterly unrealistic. It makes more sense to practice writing with your
> feet in case you lose both your hands in an accident.

Actually I have given consideration on what I can do
in PDOS to allow me to continue to program if I lose
my eyesight, and even my hearing, ie become deafblind.

> > I don't know how that translates to CPUs that aren't part
> > of an actual computer system. Maybe output ANSI codes
> > via a serial port. I really don't know the exact circumstances.
> >
> The whole thing is vastly more involved, and less realisable, than you
> seem to think. The electrical signals involved are totally different.
> You have been watching too much TV, where electronics systems are
> repaired by teenagers flashing a welding torch at them then sticking
> bits together with duct tape and chewing gum. Reality is not like that.

I am not claiming that teenagers can do anything of
the sort. I'm not making any claims other than "I
don't know". You're the one making claims of being
all-knowing.

> > I didn't set out to invent S/380 either. It just happened
> > while I was pushing the limits of S/370. Ditto AM32.

> To my knowledge, there never was an S/380.

There has been for more than a decade. Many people
run S/3X0 software on emulators rather than expensive
hardware (and IBM hates people doing that). S/380 is
now one of those targets.

> > I am interested in modifying Hercules/380 so that I
> > can effectively have a S/380 and 80386 coprocessor
> > and run software targeting either processor at native
> > speed depending on what actual hardware I happen
> > to be on.
> >
> This would be on S/380 hardware that has never existed, with an 80386
> processor that hasn't been produced for decades, combined in a way that
> is not possible

Why do you think these two pieces of hardware can't
be combined?

> and which no one would want even if it /were/ possible?

No-one? You speak for 7 billion people including me?

> All so that you could run code natively on either processor - code you
> want to write in a portable language that can target any machine,
> combined with development tools that will run on any machine, so that
> the results will be the same regardless of what processor it runs on?

Yes. I want to turn up to a keyboard and screen and
have no clue whatsoever what my hardware is, and
for it to be difficult to even know what code page is
even in use.

> I am sure you can have some fun gluing the Hercules S/370 emulator onto
> Bochs or QEMU for x86 emulation. But I can't imagine how it could be
> anything other than a fun challenge.

Combine it with an ARM emulator as well, and I can switch
to a cheaper computer without even being aware that anything
changed. And switch back of course. Perhaps all from a USB
stick.

BFN. Paul.

[Bart]

On 08/04/2021 21:09, muta...@gmail.com wrote:
> On Thursday, April 8, 2021 at 9:31:10 PM UTC+10, David Brown wrote:

> I'll be in charge of creating an OS for a 6502 processor.

> And if my name was Babbage, I would have been
> writing the OS down on paper, waiting for the
> hardware to arrive.

An OS was not necessary for his purpose. They probably still aren't, for
machines with a dedicated use.

Actually for me they have largely been a nuisance. If a machine was only
to run one program a time (very common in the 80s) then whatever the OS
provided can just be put into a library that is part of the application.

So while you seem to think that an OS is the first piece of software
that people will need when starting from nothing, I think it's one of
the last!

What's the first thing the OS will do? Probably run an application. Then
just run the application!

> You have no way of knowing that, and I can prove
> you wrong by powering on my C64 and typing in:
>
> 10 print "hello, world"
> run

Which doesn't need an OS. Just a Basic interpreter.

[muta...@gmail.com]

If that's all you have, then don't rule out the possibility
you will be stuck on a C64 or equivalent.

> > I on the other hand openly admit that I don't know either
> > current, past or future.

> I know that computers that are only available as collectors' pieces are
> in the past.

You don't know that. There is nothing physically
stopping a piece of hardware from being built.
That was exactly done with Babbage's machine.

> I think you might be projecting your ignorance to others.

I think you might be talking out of your ass.

> There are plenty of aspects of the computer world where I know little -
> especially of the mainframe world, and my knowledge of computing before
> the late 1980's is primarily limited to home computing.

Ok, so don't be too confident about your software
being portable, or a particular operating system
being irrelevant.

> > Maybe there will be Quantum computers that are a
> > million times faster than conventional processors,
> > but Quantum memory is limited to 32k because of
> > some quark issue.

> When you have /no/ idea what you are talking about, it really does not
> make sense to make up random numbers.

You're the one who seems to be absolutely certain
those particular random numbers will never eventuate.

You may as well say that 640k will be enough for everyone.

> > Or maybe it will be an x64 processor has a 64k
> > processor cache, and someone realizes that they
> > can squeeze their application into 64k of memory,
> > by using 16-bit pointers in 16-bit protected mode,
> > and the processor allows you to fix the area of
> > memory that is cached, and everyone is scrambling
> > to fit into that limit to have their application run
> > 10 times faster.
> >
> You are in the wrong profession. With that imagination, you should be a
> science fiction writer, or a politician, or something where a wild
> fantasy is more useful.

Or things like S/380 get invented.

> > Or maybe someone will actually build a Babbage
> > machine. Guess what? They did.

> Please try to think /why/ this was done. Do you think it was to

I don't really care. While ever it is physically possible to
build something, I am interested in porting PDOS to it.

> > It may not be exactly that. I just know that if the
> > situation ever arises that I need an OS for a
> > limited memory machine, that my OS is too big.
> > I don't know whether to #ifdef a whole lot of
> > stuff out, or whether there is some other solution.

> The solution is to get a bit of /realism/ in your life.

No, that "solution" doesn't fit well with me.

> Sure, there is plenty of scope for a small OS - I used several far
> smaller than the ones you are imagining. But these are not for
> development work - they are for embedded systems.

I guess I would like to know the minimum requirements
of an OS for development work.

And then maybe branch into ones for non-development work.

> >> Lots of people make a lot of money with Linux-based systems, and other
> >> free and open source software.
> >
> > And lots more make money from closed-source
> > systems.
> >
> > Again, if you are expecting everyone to agree with
> > you, it will never happen. You'll never convince me,
> > for starters.

> Of course I expect people to agree with me - because I am giving simple,
> clear facts. Note that I am not saying that you can /only/ make money
> with closed source software, or should /only/ use Linux, or anything of
> that sort. I am saying that some people make money using Linux-based
> systems. And some people make money using BSD-based systems. Some make
> money when using or writing open source software, some make money when
> using or writing closed source software. There really isn't anything to
> argue against here.

I'm not arguing with the above paragraph, which is irrelevant
to anything I said. You may as well be saying that some people
make money by baking cakes.

> > And apparently I'll never convince you either.
> >
> >> For example, you could sell the new
> >> computer system and processor - sell the hardware, not the software. By
> >
> > Or I could sell both. My choice.

> Sure, there's no problem in that. And no requirement for "public
> domain" software at any stage.

Depends what you mean by "requirement". I have that
requirement. I'm not going to touch anything that isn't
either written by me or has a clear "released to the
public domain" notice on it.

> >> having the software open source, if the hardware is popular you'll have
> >> other people who want to improve the software, making the whole thing
> >> better so that you sell more hardware.
> >
> > If I think that way, that's what I will do. It will depend on
> > what the marketing department says will make my
> > company the most money.
> >
> > Public domain software allows me to go whichever
> > route *I* wish to go.

> Public domain software allows some options, and disallows others. The

The only options it disallows is that jackasses who imagine
there is something wrong with public domain can't use it.

That's fine. I can live with that.

> same goes for other kinds of licences. I would not expect one license
> to cover everyone's needs, any more than I would expect one OS, one
> compiler or one programming language to cover everyone's needs (or even
> every need for one person).

We'll see about that. A public domain C compiler, OS
etc may well satisfy my needs.

SOME commercial companies may have such hangups.
You don't know about THIS one.

> I /know/ that many open source projects will not accept
> "public domain" contributions and insist on clear copyright information.

Yes, some jackasses have hangups. So what's new?

> (Your earlier comment about mixing GPL and PD software was entirely
> ass-backwards, showing your lack of understanding of the issues involved.)

No, my comment was accurate.

> I am fully in favour of sharing software and technology in appropriate
> ways. I am fully in favour of doing it with /clear/ and /explicit/
> copyright and licensing, in a way that people can be comfortable with if
> everything goes sour and ends up in court, and that is understandable
> for all involved from the programmer to the PHB via the company lawyer
> and tax accountant trying to figure out the value of the code.

Public domain is perfectly clear. It is anything that says
"copyright" that you have to be aware of, because both
you, the author, and the judge know that the author
intended to hold something back. WHAT he is holding
back is unclear, and even different courts may come
to different conclusions.

With "public domain" there is no indication whatsoever
that anything is being held back.

> Serious groups who want to give out code as "public domain", and where
> the code is heavily used, make a point of explaining exactly what they
> mean, and explicitly stating what rights they are giving to others, and
> what this all means legally. The best example here would be SQLite:
>
> <https://www.sqlite.org/copyright.html>

It's a pity Shakespeare didn't know about SQLite so that
he could have clearly stated what was going to happen
70 years after he died, to avoid confusion about the
status of "Hamlet".

> I am not against "public domain" as such - I am against an attitude of
> "Do what you want with this code - I don't care" and slapping on a
> license (including "public domain") without thought or understanding,

"public domain" isn't a license, it's the absence of one.

> and without considering if it really does what you think it does. For
> example, for your usage I believe the Creative Commons CC0 would be more
> appropriate.

I told you already I use that as a fallback.

> >> I know why they would not pick an open source
> >> compiler (GPL or BSD) - there were no realistic bases to start from at
> >> that time, which was many years ago. (If they were doing this now, SDCC
> >> would have been the obvious choice - under the GPL.) What makes a lot
> >
> > OR, even if it did, the company may have thought the
> > same way that I do, and doesn't want to end up being
> > taken to court by some GPL jackass saying "this is
> > my copyrighted code (true) and in my interpretation,
> > and certainly my intent, of rule number 563, you can't
> > do what you just did, and you owe me $50 trillion,
> > the same as that BSD jackass got".

> The GPL is quite well understood - the company involved would have been

What's well understood is that the GPL jackasses have
taken people to court. Do you know of any public domain
author taking someone to court?

> able to fulfil their obligations under that license (or if they decided
> they did not want to follow it, they would not use GPL'ed code). The

I'm one of those people who don't want to follow
GPLs rules, which is why I don't use it, and I cater
for other people who don't want to follow them
either.

> same company currently sells other compilers based on GPL'ed compiler
> code - perfectly legally, and with no fear of court cases.

Perhaps they should be afraid. That is clearly copyrighted
software they are using. The copyright holder can sue
whenever he wants. Even if you think you've followed
their stupid rules (and are happy to do that).

> > And the company has to face a judge who says "you
> > can see there is a very clear copyright here, the onus
> > is on you to prove you didn't violate the intent of this
> > long list of rules written in Swahili - you have 30 seconds
> > to convince me - BTW, what is software anyway? - your
> > time starts now". With a pack of lawyers on both sides.
> >
> Again, your imagination is somewhat distant from reality. I'm not
> suggesting that all judges and lawyers get these things right, or that
> ridiculous lawsuits don't always get thrown out before reaching court.
> But things go a lot smoother with a clear legal license than no
> information at all.

This is a lie about "no information". The phrase "released
to the public domain" has all the information you need.

> > If public domain software had been able to lower
> > the input costs, hopefully capitalism would have
> > passed those onto the consumer.

> The market for embedded development tools has certainly changed in the
> last three decades, and the time of expensive but crappy tools is gone.
> There are still some expensive tools around, but these tend to be very
> high quality and come with other lawyer-friendly features such as
> certifications and guarantees. There are "cheap-and-cheerful"
> toolchains that offer simplicity of use and helpful support. And there
> are free toolchains, based on gcc, llvm or sdcc (GPL, BSD and GPL
> respectively).
>
> Freely available, high quality toolchains have without doubt changed the
> market situation here, to the benefit of the consumer.
>
> There are no "public domain" toolchains of any relevance for any targets
> - there is no benefit in it for either the compiler writers or the users.

Wrong. If I'm a compiler writer, I will release it to the
public domain, so that others can improve it, and when
I am approached by a commercial company with a
new processor who wishes to close-source their new
compiler, I'll be able to charge them, and make use of
my expertise.

Actually I was thinking of doing the same with SQLite.
Instead of chasing the latest, greatest version, I could
take a particular release (similar to what I have done
with GCC 3.2.3) and carefully nurture it. I could
close-source my new version of SQLite, and I could
focus on some of the not-well-supported environments
like OS/2. And sell it, of course. SQLite provides market
opportunities. So does PDOS. I've already been
approached by one guy who wants to use PDOS as
the basis of his own closed-source OS. He wants to
develop it himself though.

> > https://en.wikipedia.org/wiki/BSD_licenses
> >
> > All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the <copyright holder>.
> >
> If you read a little further down, you will see that that only applies
> to the original 4-clause BSD license. In most cases, a "BSD-style"
> license does not include an advertising clause.

That was a quote from the 3-clause license. I
deliberately moved down.

> > So one single advert by Apple in the New York Times that
> > says "buy OS X, it's finger-lickin good!" and the entire BSD
> > clan gets to sue for $50 trillion each.
> >
> As I have pointed out before, you do not know what you are talking
> about. You don't even seem to have the ability to read a few paragraphs
> of a Wikipedia page.

That comment seems better applied to yourself.

> > Enough with your lies about BSD and other virus-licensed
> > software, and your lies about public domain.
> >
> > Just spit out your ulterior motive so we can both move on
> > to our respective campaigns. Mine to donate source code
> > to the public rather than be a dog in a manger. Yours, god
> > knows what.
> >
> This will be the last time I respond to a post of yours that accuses me
> of lying and/or of having an "ulterior motive".

Ok, so the lies will stop soon?

> Take your conspiracy
> theories and your rapid fanaticism elsewhere.

More lies to cover up your ulterior motives.

BFN. Paul.

[muta...@gmail.com]

On Friday, April 9, 2021 at 6:33:36 AM UTC+10, Bart wrote:
> On 08/04/2021 21:09, muta...@gmail.com wrote:
> > On Thursday, April 8, 2021 at 9:31:10 PM UTC+10, David Brown wrote:
>
> > I'll be in charge of creating an OS for a 6502 processor.
>
> > And if my name was Babbage, I would have been
> > writing the OS down on paper, waiting for the
> > hardware to arrive.

> An OS was not necessary for his purpose.

It may not have been necessary, but he might have
been able to invent the concept.

Or was there something missing?

> They probably still aren't, for
> machines with a dedicated use.

I was under the impression that one of his machines
was programmable. Once you have that, even before
you build the hardware, I don't know of any barrier to
creating C90.

> Actually for me they have largely been a nuisance. If a machine was only
> to run one program a time (very common in the 80s) then whatever the OS
> provided can just be put into a library that is part of the application.
>
> So while you seem to think that an OS is the first piece of software
> that people will need when starting from nothing, I think it's one of
> the last!
>
> What's the first thing the OS will do? Probably run an application. Then
> just run the application!

I don't really follow this. Assuming you have 3
programs you are interested in running, each
20k in size, and they thus fit on a 180k floppy
(I think that's what the size was on the C64),
how do you intend to choose which one to
load, or rename the executable, or duplicate
the floppy for backup?

If you're writing a basic program, what editor do
you intend to use, and how do you expect to save
your work into a .bas file on the floppy?

> > You have no way of knowing that, and I can prove
> > you wrong by powering on my C64 and typing in:
> >
> > 10 print "hello, world"
> > run

> Which doesn't need an OS. Just a Basic interpreter.

Yes, and then line 20,

OPEN FILE "fred.txt" for WRITING

or whatever BASIC syntax is - how is the BASIC
interpreter going to achieve that?

It's theoretically possible that every application
could have the library linked in that knows how
to deal with floppy disks.

But then what happens when you bolt on a C64
hard drive (they were in fact available from 3rd
party manufacturers)?

Even 16k computers had CP/M available. IBM
went to a lot of effort to stay compatible with
CP/M. Was that all a waste of time?

BFN. Paul.

[Bart]

On 08/04/2021 22:07, muta...@gmail.com wrote:
> On Friday, April 9, 2021 at 6:33:36 AM UTC+10, Bart wrote:

>> What's the first thing the OS will do? Probably run an application. Then
>> just run the application!
>
> I don't really follow this. Assuming you have 3
> programs you are interested in running, each
> 20k in size, and they thus fit on a 180k floppy
> (I think that's what the size was on the C64),
> how do you intend to choose which one to
> load, or rename the executable, or duplicate
> the floppy for backup?

How did it work on a machine which booted up to Basic?

For that matter, if the floppy has a choice of OSes, how does it choose
which OS to load?

Given /some/ basic functionality when a machine is powered up, a program
that can display files for a choice of program is trivial (I've done it).

> If you're writing a basic program, what editor do
> you intend to use, and how do you expect to save
> your work into a .bas file on the floppy?
>
>>> You have no way of knowing that, and I can prove
>>> you wrong by powering on my C64 and typing in:
>>>
>>> 10 print "hello, world"
>>> run
>
>> Which doesn't need an OS. Just a Basic interpreter.
>
> Yes, and then line 20,
>
> OPEN FILE "fred.txt" for WRITING
>
> or whatever BASIC syntax is - how is the BASIC
> interpreter going to achieve that?

Via the library. The Basic interpreter will be written per platform, so
will the library.

> It's theoretically possible that every application
> could have the library linked in that knows how
> to deal with floppy disks.
>
> But then what happens when you bolt on a C64
> hard drive (they were in fact available from 3rd
> party manufacturers)?

So how does it work with the OS? What makes it so different from any
other library?

(I've written programs that directly talked to floppy disk and hard disk
controllers, at a point where the OS didn't exist or wasn't loaded. Yes,
its specific to that hardware, but whatever needs adding to the OS to do
the same task will also be specific.)

> Even 16k computers had CP/M available. IBM
> went to a lot of effort to stay compatible with
> CP/M. Was that all a waste of time?

The OS provided a set of standards, or a kind of API. The API can exist
by itself, and be implemented by a library. It would be needed to run
programs which /expected/ such an OS to be in place and have a
particular interface.

But here I thought we were starting from nothing. Then anything goes.

(I think CP/M didn't even specify a disk format, so every machine used a
slightly different layout; you couldn't exchange data or programs via
floppy!)

[muta...@gmail.com]

On Friday, April 9, 2021 at 7:32:27 AM UTC+10, Bart wrote:

> >> What's the first thing the OS will do? Probably run an application. Then
> >> just run the application!
> >
> > I don't really follow this. Assuming you have 3
> > programs you are interested in running, each
> > 20k in size, and they thus fit on a 180k floppy
> > (I think that's what the size was on the C64),
> > how do you intend to choose which one to
> > load, or rename the executable, or duplicate
> > the floppy for backup?

> How did it work on a machine which booted up to Basic?

It only booted Basic after booting the OS!

I only see a marginal difference between a command
prompt and a Basic prompt anyway.

> For that matter, if the floppy has a choice of OSes, how does it choose
> which OS to load?

Well I'm not sure anyone at all was so sophisticated
to have multiple OSes on a floppy.

> Given /some/ basic functionality when a machine is powered up, a program
> that can display files for a choice of program is trivial (I've done it).

How do you get your program loaded in the first place?
If it's on floppy, someone needs to understand the
floppy format.

> > If you're writing a basic program, what editor do
> > you intend to use, and how do you expect to save
> > your work into a .bas file on the floppy?
> >
> >>> You have no way of knowing that, and I can prove
> >>> you wrong by powering on my C64 and typing in:
> >>>
> >>> 10 print "hello, world"
> >>> run
> >
> >> Which doesn't need an OS. Just a Basic interpreter.
> >
> > Yes, and then line 20,
> >
> > OPEN FILE "fred.txt" for WRITING
> >
> > or whatever BASIC syntax is - how is the BASIC
> > interpreter going to achieve that?

> Via the library. The Basic interpreter will be written per platform, so
> will the library.

I believe computers used to run without operating
systems per se. They would indeed link in all of the
OS functionality.

But surely the correct abstraction is to separate out
the BIOS, the OS and the application? Perhaps with
mode/ring switches between each of those levels,
and even within those levels (e.g. microkernel), and
even more potential switches above the BIOS, and
even more processor switches.

> > It's theoretically possible that every application
> > could have the library linked in that knows how
> > to deal with floppy disks.
> >
> > But then what happens when you bolt on a C64
> > hard drive (they were in fact available from 3rd
> > party manufacturers)?

> So how does it work with the OS? What makes it so different from any
> other library?

It's the exact same code. It's just where it belongs.

> (I've written programs that directly talked to floppy disk and hard disk
> controllers, at a point where the OS didn't exist or wasn't loaded. Yes,
> its specific to that hardware, but whatever needs adding to the OS to do
> the same task will also be specific.)

But that's the whole point of the OS, or more specifically,
the BIOS. It's at the OS level you should be dealing with
file systems, and at the BIOS level you deal with the
hardware.

> > Even 16k computers had CP/M available. IBM
> > went to a lot of effort to stay compatible with
> > CP/M. Was that all a waste of time?

> The OS provided a set of standards, or a kind of API. The API can exist
> by itself, and be implemented by a library. It would be needed to run
> programs which /expected/ such an OS to be in place and have a
> particular interface.

Sure. It's all technically possible. PDOS/386 currently has
the BIOS and OS woven together too. But now I "realize"
that that was wrong.

> But here I thought we were starting from nothing. Then anything goes.

I certainly agree we are starting from nothing so we
can do anything we want.

But I don't think "what we want" is to collapse all of the
BIOS/OS/app into a single executable that could e.g.
be the Kickstart disk of an Amiga 1000.

> (I think CP/M didn't even specify a disk format, so every machine used a
> slightly different layout; you couldn't exchange data or programs via
> floppy!)

The physical floppy drives may have been different and
incompatible (not sure how that is actually possible given
that floppy disk media is generic I think), but the CP/M
file system was the same I think. I don't see a reason to
change that when you change computer.

BFN. Paul.

[Bart]

On 08/04/2021 23:53, muta...@gmail.com wrote:
> On Friday, April 9, 2021 at 7:32:27 AM UTC+10, Bart wrote:
>
>>>> What's the first thing the OS will do? Probably run an application. Then
>>>> just run the application!
>>>
>>> I don't really follow this. Assuming you have 3
>>> programs you are interested in running, each
>>> 20k in size, and they thus fit on a 180k floppy
>>> (I think that's what the size was on the C64),
>>> how do you intend to choose which one to
>>> load, or rename the executable, or duplicate
>>> the floppy for backup?
>
>> How did it work on a machine which booted up to Basic?
>
> It only booted Basic after booting the OS!

What OS? Some simple home computers had a very simple executive only
which could have been a form of Basic.

> I only see a marginal difference between a command
> prompt and a Basic prompt anyway.

Exactly. It's just a program. To make life simpler, you'd arrange for
some basic program to be in ROM, one whose main purpose is to load your
application from disk.

My job at one point was to write those programs that run before you
loaded your OS.

Or, for a machine that didn't work or was being prototyped or developed,
and which couldn't yet support an OS, I had to write the programs that
run various tests to help with the fault-finding or development (and
somehow get them into the machine).

>> Given /some/ basic functionality when a machine is powered up, a program
>> that can display files for a choice of program is trivial (I've done it).
>
> How do you get your program loaded in the first place?
> If it's on floppy, someone needs to understand the
> floppy format.

The guy who writes the program in the ROM will know! And actually he (or
she) doesn't need to understand the file system used; just require that
the code occupies so many sectors on the first track.

> I believe computers used to run without operating
> systems per se. They would indeed link in all of the
> OS functionality.

They used to do all sorts of things to get the job done. The first OS I
used ran on a machine that took up a whole room, and you needed to book
a terminal to be able to use it. It had 160 simultaneous users so some
sort of supervising, time-sharing operating system was necessary.

But the first machine I built had a 8-bit processor and 256 bytes of
memory; the idea of an OS would be ludicrous. It had no disks anyway (or
a keyboard display at that point)

(Yet I wrote a compiler for it, and played with 3D graphics and image
processing, although by then it had some 40KB of memory in all. But
still no OS, or disks.)

> But surely the correct abstraction is to separate out
> the BIOS, the OS and the application? Perhaps with
> mode/ring switches between each of those levels,
> and even within those levels (e.g. microkernel), and
> even more potential switches above the BIOS, and
> even more processor switches.

If you're interested in OSes (I'm not) by all means do all that. But I
thought you were bootstrapping from ground zero with a 64KB 8-bit
machine. Presumably there'd only be one user at a time.

>> (I've written programs that directly talked to floppy disk and hard disk
>> controllers, at a point where the OS didn't exist or wasn't loaded. Yes,
>> its specific to that hardware, but whatever needs adding to the OS to do
>> the same task will also be specific.)
>
> But that's the whole point of the OS, or more specifically,
> the BIOS. It's at the OS level you should be dealing with
> file systems, and at the BIOS level you deal with the
> hardware.

This is where it gets confusing. Those 64K C64 machines that you will
have to resort to will have what they have; they won't have this new
'BIOS' you've been talking about, and which it sounds like you expect
other people to write.

Without that part, what is your PDOS going to talk to? Whatever it is,
why can't /any/ program talk to it?

>> (I think CP/M didn't even specify a disk format, so every machine used a
>> slightly different layout; you couldn't exchange data or programs via
>> floppy!)
>
> The physical floppy drives may have been different and
> incompatible (not sure how that is actually possible given
> that floppy disk media is generic I think), but the CP/M
> file system was the same I think. I don't see a reason to
> change that when you change computer.

Well, the formats /were/ different enough that it caused problems. I
don't know why they were different.

[anti...@math.uni.wroc.pl]

muta...@gmail.com <muta...@gmail.com> wrote:
> On Friday, April 9, 2021 at 6:33:36 AM UTC+10, Bart wrote:
> > On 08/04/2021 21:09, muta...@gmail.com wrote:
> > > On Thursday, April 8, 2021 at 9:31:10 PM UTC+10, David Brown wrote:
> >
> > > I'll be in charge of creating an OS for a 6502 processor.
> >
> > > And if my name was Babbage, I would have been
> > > writing the OS down on paper, waiting for the
> > > hardware to arrive.
>
> > An OS was not necessary for his purpose.
>
> It may not have been necessary, but he might have
> been able to invent the concept.
>
> Or was there something missing?
>
> > They probably still aren't, for
> > machines with a dedicated use.
>
> I was under the impression that one of his machines
> was programmable. Once you have that, even before
> you build the hardware, I don't know of any barrier to
> creating C90.

Look at IBM 1401. It is much more powerful machine than
anything Babbage could possibly build. How would you
go with implementing C90 for 1401? Do you think that
you must have on OS for it? Even in smallest configuration
it was quite useful machine that could do things essentially
impossible without computers.

BTW: My first programs where written for a programmable
calculator (TI-50) which in almost all aspect was much
more limited than 1401. AFAIK TI-50 actually run interpreter,
so what user saw was virtual machine implemented by software.
Unlike this 1401 was implemented by hardware.

BTW2: There is emulator for 1401 (IIRC copyrighted). There
is also some preserved IBM software (IIUC it is considerd
public domain).

> > Actually for me they have largely been a nuisance. If a machine was only
> > to run one program a time (very common in the 80s) then whatever the OS
> > provided can just be put into a library that is part of the application.
> >
> > So while you seem to think that an OS is the first piece of software
> > that people will need when starting from nothing, I think it's one of
> > the last!
> >
> > What's the first thing the OS will do? Probably run an application. Then
> > just run the application!
>
> I don't really follow this. Assuming you have 3
> programs you are interested in running, each
> 20k in size, and they thus fit on a 180k floppy
> (I think that's what the size was on the C64),
> how do you intend to choose which one to
> load, or rename the executable, or duplicate
> the floppy for backup?

I had ZX Spectrum where only mass storage was tape
recorder. Normal file had a header which contained
name. You gave that name to LOAD program. Program
could load date from tape. Of course you could also
store data or save program. Reading stated in whatever
place you positioned the tape and scanned for header
with maching name, then read following data/program
and stored in memory. Similarly, writes went to
current position on tape. It was up to user to ensure
that no needed data was overwritten and that there
was enough free space on the tape. Read/write procedures
were in ROM, but hardware has acessible to user, so
one could use alternative I/O routines. AFAICS there
was nothing that software could do to make this process
significantly more convenient: most problems were
limitations due to hardware. You could try to put
a catalog at start of a tape, but user still would
have to stop tape after reading catalog (otherwise
tape could move too far) and still would have to
wait for desired file (if it was at end of tape).

In practice, people would use separate tapes at least
for each important programs. When there were several
program you would have a piece of paper where you
noted approximate position, so you could rewind tape
close to start of program (or data).

BTW: I have C compiler for ZX Spectrum. IIRC it has
no floating point, but othewise is reasonable implementation
for its time (well before C90).

> If you're writing a basic program, what editor do
> you intend to use, and how do you expect to save
> your work into a .bas file on the floppy?
>
> > > You have no way of knowing that, and I can prove
> > > you wrong by powering on my C64 and typing in:
> > >
> > > 10 print "hello, world"
> > > run
>
> > Which doesn't need an OS. Just a Basic interpreter.
>
> Yes, and then line 20,
>
> OPEN FILE "fred.txt" for WRITING
>
> or whatever BASIC syntax is - how is the BASIC
> interpreter going to achieve that?
>
> It's theoretically possible that every application
> could have the library linked in that knows how
> to deal with floppy disks.

On ZX Spectrum Basic was the OS. It had command to
handle microdrives (tape drive that at software level
looked similar to floppy), actual routines were in
ROM in interface hardware. Third party floppies had
to hook into this: for example provide interface with
Basic compatible ROM. There were 48k RAM, part taken
by screen buffer. Low 16k were ROM, normally builtin
Basic but interface could assert a line to disable builtin
ROM and provide it own ROM instead.

Of course, in modern time it is hard to imagine computer
system without convenient mass storage. But in 8-bit
era floppy drive plus interface could double or triple
price of system. I probably never saw Spectrum in
real use with anything other than tape.

--
Waldek Hebisch

[muta...@gmail.com]

On Friday, April 9, 2021 at 10:09:44 AM UTC+10, Bart wrote:

> >>>> What's the first thing the OS will do? Probably run an application. Then
> >>>> just run the application!
> >>>
> >>> I don't really follow this. Assuming you have 3
> >>> programs you are interested in running, each
> >>> 20k in size, and they thus fit on a 180k floppy
> >>> (I think that's what the size was on the C64),
> >>> how do you intend to choose which one to
> >>> load, or rename the executable, or duplicate
> >>> the floppy for backup?
> >
> >> How did it work on a machine which booted up to Basic?
> >
> > It only booted Basic after booting the OS!

> What OS? Some simple home computers had a very simple executive only
> which could have been a form of Basic.

My reference is a C64, and it did indeed have an OS,
in ROM, with specific addresses to call to get OS
services.

The Basic that it then invoked could be banked out
by applications not requiring Basic, but requiring
OS services.

> > I only see a marginal difference between a command
> > prompt and a Basic prompt anyway.

> Exactly. It's just a program. To make life simpler, you'd arrange for
> some basic program to be in ROM, one whose main purpose is to load your
> application from disk.

A semblance of an OS, or perhaps BIOS.

> My job at one point was to write those programs that run before you
> loaded your OS.

Ok, so a BIOS.

> Or, for a machine that didn't work or was being prototyped or developed,
> and which couldn't yet support an OS, I had to write the programs that
> run various tests to help with the fault-finding or development (and
> somehow get them into the machine).

I can remember BIOSes having some sort of
self-test facility. Sounds like that.

> >> Given /some/ basic functionality when a machine is powered up, a program
> >> that can display files for a choice of program is trivial (I've done it).
> >
> > How do you get your program loaded in the first place?
> > If it's on floppy, someone needs to understand the
> > floppy format.

> The guy who writes the program in the ROM will know! And actually he (or
> she) doesn't need to understand the file system used; just require that
> the code occupies so many sectors on the first track.

Ok, so you have a BIOS that understands the hardware
and does the initial load. That's not unusual.

Although I note that IBM mainframes don't really
have that. The CPU isn't involved in IPLing.

> > I believe computers used to run without operating
> > systems per se. They would indeed link in all of the
> > OS functionality.

> They used to do all sorts of things to get the job done. The first OS I
> used ran on a machine that took up a whole room, and you needed to book
> a terminal to be able to use it. It had 160 simultaneous users so some
> sort of supervising, time-sharing operating system was necessary.
>
> But the first machine I built had a 8-bit processor and 256 bytes of
> memory; the idea of an OS would be ludicrous. It had no disks anyway (or
> a keyboard display at that point)
>
> (Yet I wrote a compiler for it, and played with 3D graphics and image
> processing, although by then it had some 40KB of memory in all. But
> still no OS, or disks.)

Yes, that is one of my conundrums. My OS too big to
fit in that space and I'm not really willing to give up
any of the functionality.

I have penciled in use of a coprocessor with more
memory, so that when your application needs OS
services (or even run the compiler above), it can
make direct contact with it.

> > But surely the correct abstraction is to separate out
> > the BIOS, the OS and the application? Perhaps with
> > mode/ring switches between each of those levels,
> > and even within those levels (e.g. microkernel), and
> > even more potential switches above the BIOS, and
> > even more processor switches.

> If you're interested in OSes (I'm not) by all means do all that. But I
> thought you were bootstrapping from ground zero with a 64KB 8-bit
> machine. Presumably there'd only be one user at a time.

All the above was for a single user.

> >> (I've written programs that directly talked to floppy disk and hard disk
> >> controllers, at a point where the OS didn't exist or wasn't loaded. Yes,
> >> its specific to that hardware, but whatever needs adding to the OS to do
> >> the same task will also be specific.)
> >
> > But that's the whole point of the OS, or more specifically,
> > the BIOS. It's at the OS level you should be dealing with
> > file systems, and at the BIOS level you deal with the
> > hardware.

> This is where it gets confusing. Those 64K C64 machines that you will
> have to resort to will have what they have; they won't have this new
> 'BIOS' you've been talking about, and which it sounds like you expect
> other people to write.

I expect the C64 ROM to be replaced with a suitable
BIOS, or I would put my own layer on top of the
existing BIOS/OS.

> Without that part, what is your PDOS going to talk to? Whatever it is,
> why can't /any/ program talk to it?

Sure, it can. The micro-emacs that I am using on
PDOS/86 and PDOS/386 uses BIOS calls even
today.

That prevents it from porting though. However,
micro-emacs *also* has an ANSI terminal driver,
and *that* is portable, even to the mainframe.

My focus is on getting micro-emacs with the
ANSI option to work everywhere. Even on the
C64, but likely with an x64 co-processor.

BFN. Paul.

[muta...@gmail.com]

On Friday, April 9, 2021 at 11:07:20 AM UTC+10, anti...@math.uni.wroc.pl wrote:

> > > > I'll be in charge of creating an OS for a 6502 processor.
> > >
> > > > And if my name was Babbage, I would have been
> > > > writing the OS down on paper, waiting for the
> > > > hardware to arrive.
> >
> > > An OS was not necessary for his purpose.
> >
> > It may not have been necessary, but he might have
> > been able to invent the concept.
> >
> > Or was there something missing?
> >
> > > They probably still aren't, for
> > > machines with a dedicated use.
> >
> > I was under the impression that one of his machines
> > was programmable. Once you have that, even before
> > you build the hardware, I don't know of any barrier to
> > creating C90.

> Look at IBM 1401. It is much more powerful machine than
> anything Babbage could possibly build.

I didn't expect Babbage to build anything physical.
I wanted him to invent the computer industry after
he (supposedly) invented a programmable machine,
ie a computer.

> How would you
> go with implementing C90 for 1401?

I looked it up. It doesn't support a CHAR_BIT of 8.

Maybe C90 needs to be reworked to allow a
CHAR_BIT of 6.

> Do you think that you must have on OS for it?

I guess it has a human OS. When output files are
punched, a human picks them up and stores them
in a cabinet with a label. Perhaps at that point you
can at least ask for them to be labelled with 8.3
names. And subdirectories can be implemented too.

Maybe the filename could have been punched as
part of the application.

Any suggestions?

> Even in smallest configuration
> it was quite useful machine that could do things essentially
> impossible without computers.

Ok.

> I had ZX Spectrum where only mass storage was tape
> recorder. Normal file had a header which contained
> name.

> In practice, people would use separate tapes at least
> for each important programs.

Subdirectories.

> When there were several
> program you would have a piece of paper where you
> noted approximate position, so you could rewind tape
> close to start of program (or data).

Files within a subdirectory.

It seems to me that if your memory is really limited,
you need either a human or a coprocessor to assist.

On the other hand, CP/M existed and was useful.
So maybe I need another flavor of PDOS, given that
PDOS/386 and PDOS/3X0 don't share any common
code anyway.

Maybe:

1. PDOS/CPM needs to be written.
2. An 80386 coprocessor solution needs to be written.
3. Some rules for human OSes need to be written down,
compatible with FAT-12.

And Babbage may have been able to do some or all
of the above. Even without access to any physical
hardware. Number 3 is easy to emulate anyway.
With only 1400 characters for an IBM 1401.

BFN. Paul.

[muta...@gmail.com]

On Friday, April 9, 2021 at 11:07:20 AM UTC+10, anti...@math.uni.wroc.pl wrote:

> Look at IBM 1401. It is much more powerful machine than
> anything Babbage could possibly build. How would you
> go with implementing C90 for 1401? Do you think that
> you must have on OS for it? Even in smallest configuration
> it was quite useful machine that could do things essentially
> impossible without computers.

BTW, could you give an example of something *useful*
that can be done on an IBM 1401 with 1400 characters
that can't realistically be done without a computer before
1959?

It would be good to have a reference point.

I guess Flowers was decoding the Enigma even earlier
and couldn't do it by hand. Maybe that can be the
reference point.

BFN. Paul.

[David Brown]

On 08/04/2021 23:07, muta...@gmail.com wrote:
> On Friday, April 9, 2021 at 6:33:36 AM UTC+10, Bart wrote:
>> On 08/04/2021 21:09, muta...@gmail.com wrote:
>>> On Thursday, April 8, 2021 at 9:31:10 PM UTC+10, David Brown wrote:
>>
>>> I'll be in charge of creating an OS for a 6502 processor.
>>
>>> And if my name was Babbage, I would have been
>>> writing the OS down on paper, waiting for the
>>> hardware to arrive.
>
>> An OS was not necessary for his purpose.
>
> It may not have been necessary, but he might have
> been able to invent the concept.
>
> Or was there something missing?

Yes. You are missing a definition of "operating system", and why one
might need one.

What do /you/ think an operating system is? At what point does a
program stop being a "bootloader" and become an "operating system" ?
What do you think of systems where the "OS" is a library that is linked
along with application code? (That is the most common situation for
real-time operating systems.)

And of course, as Bart says, no OS of any sort is needed on dedicated
systems - the /huge/ majority of processors that are made run one single
program with no operating system of any kind, embedded within a
microcontroller.

>
>> They probably still aren't, for
>> machines with a dedicated use.
>
> I was under the impression that one of his machines
> was programmable. Once you have that, even before
> you build the hardware, I don't know of any barrier to
> creating C90.

You don't need an OS to be programmable.

You don't need an OS to be able to run code written in C90 (or modern C,
or C++, or Ada, Forth, or many other languages). Many of the systems I
make have no OS, with the program written in C (older ones are in C90,
newer ones in newer C). Some have an RTOS linked in as a library with
the main code. Some have a separate bootloader. Some can choose
between more than one program as they start up (though this is normally
for different versions of the same basic program).

I have also worked on systems that are programmable, but can barely
support even a limited subset of freestanding C - the smallest device
having no ram at all (but 32 registers in the cpu).

Some of the early computers had no way of doing general subroutine calls
- they could jump, but not return. As long as they were Turing
complete, it would be theoretically possible to have a C compiler for
them, limited only by resources - but when the resource limitations mean
you can't do anything useful in C, the whole exercise is pointless.

>
>> Actually for me they have largely been a nuisance. If a machine was only
>> to run one program a time (very common in the 80s) then whatever the OS
>> provided can just be put into a library that is part of the application.
>>
>> So while you seem to think that an OS is the first piece of software
>> that people will need when starting from nothing, I think it's one of
>> the last!
>>
>> What's the first thing the OS will do? Probably run an application. Then
>> just run the application!
>
> I don't really follow this. Assuming you have 3
> programs you are interested in running, each
> 20k in size, and they thus fit on a 180k floppy
> (I think that's what the size was on the C64),
> how do you intend to choose which one to
> load, or rename the executable, or duplicate
> the floppy for backup?

That is a lot of assumptions that are not relevant for dedicated
systems. You don't have 3 programs to run - you have one program. You
might have a different program at a different time, but only one at a
time. You don't have a floppy. (Babbage did not have floppy disks,
embedded systems don't have floppy disks, and even for your beloved C64
only a tiny proportion of users had floppy disks.)

As far as I remember, Babbage's programmable solution was copied from
Jacquard's looms. A new program means a new stack of boards with pegs
or holes in different positions. You don't have an operating system,
you have an operator.

>
> If you're writing a basic program, what editor do
> you intend to use, and how do you expect to save
> your work into a .bas file on the floppy?
>

Dedicated systems are not like 1980's home computers.

>>> You have no way of knowing that, and I can prove
>>> you wrong by powering on my C64 and typing in:
>>>
>>> 10 print "hello, world"
>>> run
>
>> Which doesn't need an OS. Just a Basic interpreter.
>
> Yes, and then line 20,
>
> OPEN FILE "fred.txt" for WRITING
>
> or whatever BASIC syntax is - how is the BASIC
> interpreter going to achieve that?
>
> It's theoretically possible that every application
> could have the library linked in that knows how
> to deal with floppy disks.
>
> But then what happens when you bolt on a C64
> hard drive (they were in fact available from 3rd
> party manufacturers)?

What /are/ you talking about? Are you still imagining you are Babbage?

[David Brown]

On 08/04/2021 22:48, muta...@gmail.com wrote:

>> This will be the last time I respond to a post of yours that accuses me
>> of lying and/or of having an "ulterior motive".
>
> Ok, so the lies will stop soon?
>
>> Take your conspiracy
>> theories and your rapid fanaticism elsewhere.
>
> More lies to cover up your ulterior motives.
>

I should have read this post before replying to any of the others, but I
had a sort of morbid fascination to see what you were thinking about.
However, I am not interested in insults from someone so completely
disconnected from reality.

End of thread.

[anti...@math.uni.wroc.pl]

muta...@gmail.com <muta...@gmail.com> wrote:
> On Friday, April 9, 2021 at 11:07:20 AM UTC+10, anti...@math.uni.wroc.pl wrote:
>
> > Look at IBM 1401. It is much more powerful machine than
> > anything Babbage could possibly build. How would you
> > go with implementing C90 for 1401? Do you think that
> > you must have on OS for it? Even in smallest configuration
> > it was quite useful machine that could do things essentially
> > impossible without computers.
>
> BTW, could you give an example of something *useful*
> that can be done on an IBM 1401 with 1400 characters
> that can't realistically be done without a computer before
> 1959?

"Killer app" of early computers was numerical solving
of differential equations. Simple solver fits easily
into 100 intstructions and needs 20-30 variables.
In rocket or airplane design you need to solve a lot
of equation to find good design. Related application
is creating various mathematical tables. Some tables
can be done by simpler machines, in fact difference
engine was specialized machine for one kind of tables.

To put this into qantitative settings, 1401 could do
thousends of additions per second, so corresponding
calculations would be huge amount of human labor if
done by hand or mechanical calculator. I am not sure
if you count "analytic machines" as computers or not.
Even if you count them as alternative, they were much
slower at arithemtic and too inflexible. Design
of a rocket could realistically burn few thousends
of 1401 hours -- doable in 1-2 year project.
Alternatives probably would be at least 100 times
slower, so that computations alone would stretch
to tens of years, likely making the project infeasible.
Note that in market setting usually the first one to
get product on maket wins, so even smaller difference
in completiton time can decide between success or
failure.

--
Waldek Hebisch

[anti...@math.uni.wroc.pl]

muta...@gmail.com <muta...@gmail.com> wrote:
> On Friday, April 9, 2021 at 11:07:20 AM UTC+10, anti...@math.uni.wroc.pl wrote:
>
> > > > > I'll be in charge of creating an OS for a 6502 processor.
> > > >
> > > > > And if my name was Babbage, I would have been
> > > > > writing the OS down on paper, waiting for the
> > > > > hardware to arrive.
> > >
> > > > An OS was not necessary for his purpose.
> > >
> > > It may not have been necessary, but he might have
> > > been able to invent the concept.
> > >
> > > Or was there something missing?
> > >
> > > > They probably still aren't, for
> > > > machines with a dedicated use.
> > >
> > > I was under the impression that one of his machines
> > > was programmable. Once you have that, even before
> > > you build the hardware, I don't know of any barrier to
> > > creating C90.
>
> > Look at IBM 1401. It is much more powerful machine than
> > anything Babbage could possibly build.
>
> I didn't expect Babbage to build anything physical.
> I wanted him to invent the computer industry after
> he (supposedly) invented a programmable machine,
> ie a computer.

AFAICS already earlist fairy tales include things happening
when you think about them or ask for them with words. So in
this sence "voice operated OS" (and "thought operated OS")
is known from very beginning of humanity. Some tales involved
"information processing" (like prophecies) so in this sense
very advanced computing is known for millenia. The problem
is with turning tales into real thing.

If you do not expect Babbage to build physical things, then
you ignore his biggest archivement: he was reasonably close
to building working machine (as opposed to dreaming about
one).

> > How would you
> > go with implementing C90 for 1401?
>
> I looked it up. It doesn't support a CHAR_BIT of 8.
>
> Maybe C90 needs to be reworked to allow a
> CHAR_BIT of 6.

That is most obvious, but in a sense smallest problem.
For example, you could use two 1401 characters to
represent one C character. Of couse taking 6 as CHAR_BIT
is natural direction. But once you covered issue with
size of character set (say ISO declared that CHAR_BIT
of 6 is OK) you immediately hit other problems.

1401 is decimal machine that performs arithmetic
on strings of characters (digits). How you match
this to C rules. Also, hardware pointers to numbers
actually point to highest address character of a number,
how you match this to C pointer rules (note that numbering
memory characters in reverse will not work, as I/O goes
in ordinary direction, from low to high). And those
lovely word marks: how do you implement cast

p2 = (T2)p1

where p1 is of type T1. Assume that T1 and T2 are pointer
types pointing to structs with incompatible layout (that
is needing different word marks). AFAUI in C you are
not allowed to dereference both pointers, but typical
C code assumes that cast are OK (and I think that with
slightly more complicated code you do thing which is
semanticaly equivalent and cosher with strict standard
reading). Related to this is question how you use
'malloc', namely 'malloc' should allocate memory fit
for all purposeses (probably without word marks), but
to use memory you need correct word marks.

BTW: I am not sure if this is an accident, but none
of the problem C has with 1401 applies to Pascal:
Pascal is equally happy regardless if machine is
decimal or binary. Pascal 'new' knows type so can
set correct word marks. Strict typing means no
problem with implementing casts (because there
are no casts).

> > Do you think that you must have on OS for it?
>
> I guess it has a human OS. When output files are
> punched, a human picks them up and stores them
> in a cabinet with a label. Perhaps at that point you
> can at least ask for them to be labelled with 8.3
> names. And subdirectories can be implemented too.

Hmm, you are "programming" human here, while you were
supposed to write computer program...

--
Waldek Hebisch

[muta...@gmail.com]

On Friday, April 9, 2021 at 7:25:03 PM UTC+10, David Brown wrote:
> On 08/04/2021 23:07, muta...@gmail.com wrote:
> > On Friday, April 9, 2021 at 6:33:36 AM UTC+10, Bart wrote:
> >> On 08/04/2021 21:09, muta...@gmail.com wrote:
> >>> On Thursday, April 8, 2021 at 9:31:10 PM UTC+10, David Brown wrote:
> >>
> >>> I'll be in charge of creating an OS for a 6502 processor.
> >>
> >>> And if my name was Babbage, I would have been
> >>> writing the OS down on paper, waiting for the
> >>> hardware to arrive.
> >
> >> An OS was not necessary for his purpose.
> >
> > It may not have been necessary, but he might have
> > been able to invent the concept.
> >
> > Or was there something missing?

> Yes. You are missing a definition of "operating system", and why one
> might need one.
>
> What do /you/ think an operating system is? At what point does a
> program stop being a "bootloader" and become an "operating system" ?

An OS allows an application access to resources,
starting with memory and files, so that the
application doesn't need to be concerned with a
specific file system.

I don't think a bootloader needs a definition, and
may not actually exist as program code. The
Amiga 1000 read the first 256k from a floppy
disk. I guess even that involved program code.
But IBM mainframes do a similar thing without
the CPU being involved.

Did you want a definition of a BIOS rather than a
bootloader? That allows you access to raw
memory layout and physical disks, without an
attempt to interpret the contents.

> What do you think of systems where the "OS" is a library that is linked
> along with application code? (That is the most common situation for
> real-time operating systems.)

That is technically equivalent, in fact, identical
code, but has the disadvantage of requiring a
relink of every application with every change,
and no ability to implement security or switch
to a coprocessor.

> And of course, as Bart says, no OS of any sort is needed on dedicated
> systems - the /huge/ majority of processors that are made run one single
> program with no operating system of any kind, embedded within a
> microcontroller.

Sure.

> >> They probably still aren't, for
> >> machines with a dedicated use.
> >
> > I was under the impression that one of his machines
> > was programmable. Once you have that, even before
> > you build the hardware, I don't know of any barrier to
> > creating C90.

> You don't need an OS to be programmable.

The above comment was creating a language, not an OS.
Regardless, an OS could have been imagined anyway.
In fact the whole concept of splitting app/OS/BIOS with
security and processor changes between each level
could have been imagined.

> As far as I remember, Babbage's programmable solution was copied from
> Jacquard's looms. A new program means a new stack of boards with pegs
> or holes in different positions. You don't have an operating system,
> you have an operator.

These are different concepts. There are still people
alive who hand-punched cards to write their program,
before passing it on to a card reader.

> > If you're writing a basic program, what editor do
> > you intend to use, and how do you expect to save
> > your work into a .bas file on the floppy?
> >
> Dedicated systems are not like 1980's home computers.

I thought the above comment was for a 1980s
home computer.

> > It's theoretically possible that every application
> > could have the library linked in that knows how
> > to deal with floppy disks.
> >
> > But then what happens when you bolt on a C64
> > hard drive (they were in fact available from 3rd
> > party manufacturers)?

> What /are/ you talking about? Are you still imagining you are Babbage?

I don't know what you are talking about.

1. Yes, you can link floppy code into your executable.

2. Hard drives existed for the C64.

BFN. Paul.

[muta...@gmail.com]

Of course the other alternative you had was to stick to actual
technical points, drop the claims about being omniscient about
all future computers, and quit with the disinformation campaign
about public domain in a sick, twisted attempt to prevent the
public owning any code, and instead insisting that it stays in
the hands of elites such as yourself.

Regardless, I'm still interested in countering your lies whenever
they pop up and I happen to notice.

BFN. Paul.

[muta...@gmail.com]

On Saturday, April 10, 2021 at 5:36:34 AM UTC+10, anti...@math.uni.wroc.pl wrote:

> > I didn't expect Babbage to build anything physical.
> > I wanted him to invent the computer industry after
> > he (supposedly) invented a programmable machine,
> > ie a computer.

> AFAICS already earlist fairy tales include things happening
> when you think about them or ask for them with words. So in
> this sence "voice operated OS" (and "thought operated OS")
> is known from very beginning of humanity. Some tales involved
> "information processing" (like prophecies) so in this sense
> very advanced computing is known for millenia. The problem
> is with turning tales into real thing.

Interesting take, thanks!

But in that case, what was preventing people (for
millenia) inventing a non-human language? We
already had maths, which is some sort of language.
Why not a procedural language too? Recipes
existed, so they were procedural in a way.

> If you do not expect Babbage to build physical things, then
> you ignore his biggest archivement: he was reasonably close
> to building working machine (as opposed to dreaming about
> one).

Ok, good point.

However, he believed (correctly) that he had a sound,
specific design.

Surely that could have been a trigger for inventing
Pascal?

It would be interesting to know if the language he
invented to accompany his hardware would have
caused everyone to be stuck in a rut centuries
later.

Maybe I need to switch to Pascal instead of C then.
Or some other language.

I am very uncomfortable writing code that can't be
run on an IBM 1401, now that I know about it.

If I'm ever presented with one (or a similar
problematic computer that hasn't been built
yet), I don't want to have to start from scratch.

Is there any language that covers all computers,
starting with Babbage's never-built programmable
machine, and the best we can imagine quantum
computers will look like?

What are the tradeoffs to be made? Can Pascal
be changed to be whatever makes C great? E.g.
is there anything preventing Pascal I/O being
split off into a library called stdio.pas instead of
being part of the language?

> > > Do you think that you must have on OS for it?
> >
> > I guess it has a human OS. When output files are
> > punched, a human picks them up and stores them
> > in a cabinet with a label. Perhaps at that point you
> > can at least ask for them to be labelled with 8.3
> > names. And subdirectories can be implemented too.

> Hmm, you are "programming" human here, while you were
> supposed to write computer program...

Well unless you bolt on an 80386 or whatever coprocessor
to the IBM 1401, I don't see any choice but to use a human
for this task. Is there a functional difference between an
alien coprocessor and an alien human anyway? Even if
the coprocessor is slow (especially the case with a human
"coprocessor"), most of the time is spent running the
actual application (1401 machine code) rather than running
the operating system.

I think that's actually a good analogy in fact. An OS
doesn't need to be fast, or even the same processor,
or even made of silicon. It can be a human.

And cross-compilation is similar. Maybe the 1401
could write to an I/O port that is linked via serial
cable to an 80386 and that's where file services,
and compilations, are done.

Replacing an 80386 with a human depending on
what is on hand.

Is there any alternative anyway?

> "Killer app" of early computers was numerical solving
> of differential equations. Simple solver fits easily
> into 100 intstructions and needs 20-30 variables.
> In rocket or airplane design you need to solve a lot
> of equation to find good design. Related application

Ok, thanks!

BFN. Paul.

[Scott Lurndal]

anti...@math.uni.wroc.pl writes:

>muta...@gmail.com <muta...@gmail.com> wrote:

>
>> > How would you
>> > go with implementing C90 for 1401?
>>
>> I looked it up. It doesn't support a CHAR_BIT of 8.
>>
>> Maybe C90 needs to be reworked to allow a
>> CHAR_BIT of 6.
>
>That is most obvious, but in a sense smallest problem.
>For example, you could use two 1401 characters to
>represent one C character. Of couse taking 6 as CHAR_BIT
>is natural direction. But once you covered issue with
>size of character set (say ISO declared that CHAR_BIT
>of 6 is OK) you immediately hit other problems.

I spent some weeks back in 1984 investigating supporting
a C compiler on the Burroughs Medium systems line. A BCD
machine, addressible to the nibble, operand sizes of from
one to 100 units (digits or bytes). Memory to memory
instructions with no general purpose registers.

No bit shift instructions.

Separate sign digit, allowing both positive and negative
zero.

Very CISCy instructions to search linked lists, tables and
strings.

Decimal floating point.

EBCDIC (0xF) or ASCII (0x3) encoding of the zone digit was supported.

We quickly determined that C was not a good fit for that
architecture (which was designed to run COBOL real fast)
and abandoned the project.

[muta...@gmail.com]

On Saturday, April 10, 2021 at 6:55:59 AM UTC+10, muta...@gmail.com wrote:
> On Saturday, April 10, 2021 at 5:36:34 AM UTC+10, anti...@math.uni.wroc.pl wrote:
>
> Maybe I need to switch to Pascal instead of C then.
> Or some other language.
>
> I am very uncomfortable writing code that can't be
> run on an IBM 1401, now that I know about it.

Actually, maybe I could take a different approach,
and only support processors that were designed
(or in hindsight happened to be) able to support
the C language.

I can't see anything wrong with C on S/370 or
even S/360, for example.

Was there any technological limitation at the
time that made the IBM 1401 unsuitable for C?
Or was it simply that the designers hadn't yet
been exposed to the concepts (binary integers
for maths or whatever) that are present in C?

Another approach is to have 2 flavors of
everything - one in C for modern concepts
and one in Pascal (or whatever) to cover
everything back to Babbage.

BFN. Paul.

[muta...@gmail.com]

BTW, when Apple and Google conspired to take Parler
off the air, I can remember a conversation where someone
was saying they wanted to buy a phone from a different
manufacturer, what were their options?

The reply was "two cans and a piece of string".

At some level, that's where we really stand in communication
technology. The public owns virtually nothing.

I still use a dumb phone, and I'm still focused on weaning
myself off Microsoft, who doesn't appear to have been
part of the above conspiracy anyway, for my PC.

Communications I haven't gotten to yet. I've made some
stabs at it, and indeed, I even have PDCOMM and a
public domain zmodem, but I still haven't figured out
what I want to do and how I want to do it. Just a couple
of months ago I thought the answer might have been
in NJE/RSCS.

BFN. Paul.

[muta...@gmail.com]

On Saturday, April 10, 2021 at 10:12:05 AM UTC+10, muta...@gmail.com wrote:

> BTW, when Apple and Google conspired to take Parler
> off the air, I can remember a conversation where someone
> was saying they wanted to buy a phone from a different
> manufacturer, what were their options?
>
> The reply was "two cans and a piece of string".

And there was a separate conversation where someone
asked "Where does this end? Two internets?".

Basically not even the internet is secured.

And that's before we even consider governments banning
nearly everything. I can remember an exasperated Kuwaiti
saying "There's only so much Wikipedia you can read".

BFN. Paul.

[anti...@math.uni.wroc.pl]

muta...@gmail.com <muta...@gmail.com> wrote:
> On Saturday, April 10, 2021 at 6:55:59 AM UTC+10, muta...@gmail.com wrote:
> > On Saturday, April 10, 2021 at 5:36:34 AM UTC+10, anti...@math.uni.wroc.pl wrote:
> >
> > Maybe I need to switch to Pascal instead of C then.
> > Or some other language.
> >
> > I am very uncomfortable writing code that can't be
> > run on an IBM 1401, now that I know about it.
>
> Actually, maybe I could take a different approach,
> and only support processors that were designed
> (or in hindsight happened to be) able to support
> the C language.

That probably is wise.

> I can't see anything wrong with C on S/370 or
> even S/360, for example.
>
> Was there any technological limitation at the
> time that made the IBM 1401 unsuitable for C?
> Or was it simply that the designers hadn't yet
> been exposed to the concepts (binary integers
> for maths or whatever) that are present in C?

IIUC really early computers were binary. In
case of 1401 IBM looked at market needs. 1401
was supposed to fit well into existing card
systems, so had to take character input from
cards. I would say that 1401 for its time
was comfortable "high level" machine:
- you could directly inspect/dump content
of memory and it made sense because all
data consisted of characters
- no need for extra instructions to convert data,
which means smaller and faster programs
- I/O was via single machine instruction,
no need set several configuration registers
as on modern machines
Wikipedia says that this was most popular machine
in its time. And it increased IBM market share.
So it fit quite well with customer expectations.
Binary machines were rather unpopular in busines.

Limitation to 6-bit characters was only partialy
to save cost: at that time 6-bit characters were
deemed adequate. And IBM spent 1 extra bit on
word marks. And for arithmetic by using character
based arithmetic they wasted 2 bits per character.
AFAICS partially they considered character data
more important, partially this was price to pay
for convenience.

At purely technical level, once most data was on
tapes or discs it probably made sense to switch
to purely biary data, that is on input convert data
from cards or other character sources to binary
do all processing in binary, finally convert decimal
of output. But in due time there were already
legacy character files on tapes and character
data was considered easier to handle (this still
has some merit: comunication protocols frequently
are done as text to ease debugging).

--
Waldek Hebisch

[anti...@math.uni.wroc.pl]

muta...@gmail.com <muta...@gmail.com> wrote

> That prevents it from porting though. However,
> micro-emacs *also* has an ANSI terminal driver,
> and *that* is portable, even to the mainframe.
>
> My focus is on getting micro-emacs with the
> ANSI option to work everywhere. Even on the
> C64, but likely with an x64 co-processor.

Hmm, once you have powerful co-processor why not run everything
on it and get rid of C64?

--
Waldek Hebisch

[muta...@gmail.com]

It's the principle. Why ever have a coprocessor?
Why was the C128 shipped with a Z80 coprocessor?

Maybe the coprocessor above isn't so powerful after
all, but does give access to more than 64k of memory.
Maybe that memory is really slow. But that doesn't
matter, because the OS (and editor) doesn't need to be
fast.

Maybe an application has been custom-made to fit
the 6502 timing and it is too difficult to emulate that
on an arbitrary non-6502 processor. The non-6502
processor may not be an 80386 or x64, it may be a
68000.

Maybe you want to test your application on real
hardware and it's easier to have a real 6502 driving
a real analog TV and just have a single screen in
front of you. I used to have two monitors at work,
but I only ever used one. I always run all my
applications full-screen.

I don't know every circumstance where it would be
convenient to have a coprocessor. I am working on
(effectively) getting a S/3X0 coprocessor for my
80386. You can argue I should abandon the S/3X0
and you may be right for my personal situation.
I'm writing portable C code so I don't personally
need a S/3X0 for that. But if I get a job on an IBM
mainframe tomorrow, the situation will be reversed.
I'll want everything done on the S/3X0 and no
particular need for an 80386 coprocessor.

BFN. Paul.

[luser droog]

On Monday, April 5, 2021 at 3:58:52 PM UTC-5, Scott Lurndal wrote:
> "muta...@gmail.com" <muta...@gmail.com> writes:
> >On Tuesday, April 6, 2021 at 2:26:40 AM UTC+10, Scott Lurndal wrote:
> >
> >> >I'm assuming that reverse polish notation has some
> >> >benefits such as it is simpler to write a compiler.
> >
> >> The general technique is called "Recursive Descent"
> >> parsing, and was quite common until yacc et alia
> >> were developed.
> >
> >Thanks for the info.
> >
> >> RD parsers difficult to maintain and difficult to extend
> >> albeit straightforward to write.
> >
> >Can you elaborate on this "difficult to maintain"?
> >Is this if there is a bug found or something?
> >
> >I like this "straightforward to write" option. Now that
> >I know it's actually possible.
> I suggest you pick up a copy of the Dragon book. The authors
> were recently awarded the Turing Prize by the ACM.

I think the Dragon book is an excellent reference, but not necessarily
the best introduction for a beginner. I'd recommend Jack Crenshaw's
"Let's build a compiler".

https://compilers.iecc.com/crenshaw/tutorfinal.pdf

This version clocks in at 391 pages but it's in a really big font with
lots of inline code. It's really not as long as that number makes it seem.
The Dragon book covers each subtopic separately with tons of
formalisms and theorems. Great if you're taking a course or investigating
the theory, but not so great for just plowing through and consuming
the ideas (and applying them to build along as you go).