Hi Bart (mainly).

For the non-mainly (mainly), here is the source:

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

Given that cc64 inherently has the ability to do
64-bit (with the appropriate (long long) keyword),
and 32-bit (via int) and 16-bit (via short), how
feasible is it to change cc64 in the future so
that long = 64 bit, and (maybe, in future future),
change int to 64 bit too (and maybe short to
32-bit)?

Is it like a one-line change or are there massive
implications throughout the (generated) code?

I realize that this would make the code incompatible
with Microsoft's msvcrt.dll, but that's fine, I will
provide my own DLL or statically link as appropriate
and/or thunk/glue/whatever as appropriate.

(more likely I will use the PDOS-generic interface)

Thanks. Paul.

On 22/09/2023 14:32, Paul Edwards wrote:
> Hi Bart (mainly).
>
> For the non-mainly (mainly), here is the source:
>
> https://sourceforge.net/p/pdos/gitcode/ci/master/tree/cc64/cc64.c
>
> Given that cc64 inherently has the ability to do
> 64-bit (with the appropriate (long long) keyword),
> and 32-bit (via int) and 16-bit (via short), how
> feasible is it to change cc64 in the future so
> that long = 64 bit, and (maybe, in future future),
> change int to 64 bit too (and maybe short to
> 32-bit)?
>
> Is it like a one-line change or are there massive
> implications throughout the (generated) code?
>
> I realize that this would make the code incompatible
> with Microsoft's msvcrt.dll, but that's fine, I will
> provide my own DLL or statically link as appropriate
> and/or thunk/glue/whatever as appropriate.
>
> (more likely I will use the PDOS-generic interface)

Funnily enough, I've been spending the last few weeks adapting an IL
designed for a 64-bit int, to make it work with C which uses a mix of 32
and 64 bits, with defaults of 32 bits.

Changing 'long' is easy; it is (in bcc/cc64) an alias for 'int' anyway.

Changing 'int' to 64 bits is an experiment I've tried before. One that
failed, since apart from the libraries that expect 'int' as 32 bits,
most programs I would want to test it with also assume a 32-bit int.

So testing it thoroughly would be difficult.

There are other questions: what do you make 'short'? How do you denote a
16-bit or 32-bit type? They can't both be short!

What would be the meaning of 'long long int'? I don't really want to
introduce a 128-bit type.

> Is it like a one-line change or are there massive
> implications throughout the (generated) code?

It's not a one-line change, since for one thing, it's switching from a
two-level integer type used for evaluation, to only one level.

You will need a suitable library to match, one where printf("%d",a) will
use a 64-bit type for "%d".

If you want to use any of 10,000 APIs for existing libraries, they will
mostly use a 32-bit int and 16-bit short, with 'long' being either 32 or
64 bits. That's going to be difficult to fix.

I think it would have made a far better C for 64-bit machines, but there
are these practical matters.

(My own systems language is all-64-bit, but there I have to create new
mindings for any external libraries anyway, and those will use 'int32'
wherever 'int' is used in the library.)

But if you want to do the experiment, I can have a go, /after/ I have a
decent version of my new 'MCC' product, perhaps a couple of weeks.
(Currently it can compile and run cc.c, a new version of cc64.c, but not
sql.c.)

On Friday, September 22, 2023 at 10:03:57 PM UTC+8, Bart wrote:

> Funnily enough, I've been spending the last few weeks adapting an IL
> designed for a 64-bit int, to make it work with C which uses a mix of 32
> and 64 bits, with defaults of 32 bits.
>
> Changing 'long' is easy; it is (in bcc/cc64) an alias for 'int' anyway.

Well - not that easy - I did a search for "long" in cc64.c
and didn't see the relevant code that would need to be
changed.

> Changing 'int' to 64 bits is an experiment I've tried before. One that
> failed, since apart from the libraries that expect 'int' as 32 bits,
> most programs I would want to test it with also assume a 32-bit int.
>
> So testing it thoroughly would be difficult.

I don't need it tested - I can do that myself with my own
"test suite", ie the executables that get distributed with
UCX64.

Assuming 32-bit int is against C90. If I have any code that
violates C90 I want it fixed regardless.

> There are other questions: what do you make 'short'? How do you denote a
> 16-bit or 32-bit type? They can't both be short!

There wouldn't be a 16-bit type. C90 doesn't guarantee
such a thing exists.

Note that with SubC, short/int/long are all the same.
I have tested some of my code with SubC with all-32-bit
and a little bit with all-64-bit.

There is a limit to how much I can test with SubC because
the language isn't up to C90 yet.

I see that cc64.c has this:

typedef uint16_t u16;

I expect I would be changing uint16_t (not guaranteed
to exist, even in C99) to uint_fast16_t

> What would be the meaning of 'long long int'? I don't really want to
> introduce a 128-bit type.

"long long int" and "long long" should remain 64-bit.

> > Is it like a one-line change or are there massive
> > implications throughout the (generated) code?

> It's not a one-line change, since for one thing, it's switching from a
> two-level integer type used for evaluation, to only one level.

Depending on how "aliases" are done in cc64, switching
"long" to be an alias of "long long" instead of "int" could
potentially be exactly one line of code.

> You will need a suitable library to match, one where printf("%d",a) will
> use a 64-bit type for "%d".

Yes, I have the C library (PDPCLIB) and that is my task to do.

> If you want to use any of 10,000 APIs for existing libraries, they will
> mostly use a 32-bit int and 16-bit short, with 'long' being either 32 or
> 64 bits. That's going to be difficult to fix.

The only existing libraries I care about are the ones that
I ship on UCX64.

I am basically restarting the computer industry from
scratch with a public domain base.

My wife was unable to access her bank account for
about 6 months because a 6-digit SMS was either not
being received at all, or it was being received late.

She was getting SMS from other sources so contacted
the bank. The bank kept on saying "try again later" and
"no-one else has a problem".

A Commodore 64 with a 300 bps modem could have
transmitted that code in 0.2 seconds in 1983.

In 2023 it took 6 months and a lot of drama because
the systems are too complex for anyone (or enough
people) to understand that we are already in the movie
"Idiocracy".

That's just one of many sad stories of problems going
unfixed. And the limitation isn't that CPUs aren't fast
enough, or the hard disk is too small or we haven't
installed enough frameworks.

It reminds me of "Yes, (Prime) Minister" of a hospital
that had been running for some time with no patients,
and the civil service insisted there was no problem with that.

I don't (yet) have a Commodore 64 OS, but I do have
one for an XT of the same era, and if the bank had
said "sorry - our systems are too complex - we can't
fix that for a minority of customers who may be
affected, but we have a backup plan of direct
transmission, let me dial your number with our XT",
we would have been able to continue our life.

But really, even if only one customer was affected,
we need to find the underlying issue that would
prevent 6 digits from being transmitted from A
to B. So simpler, understandable, debuggable
systems.

Even the code on UCX64 is quite a lot to understand
already - I haven't attempted to do so for most of the
utilities (pdas assembler etc). cc64 is generated code
so I'm not attempting to understand it. I expect it to
be replaced with SubC in due course (years/decades).

ie just to create and support a DOS-like system is
quite difficult.

Of course there will be a million people who pop up
and say how "easy" it is. These are the same people
who are in charge of my wife's bank. Everything is
"easy" if you don't have to do it yourself.

> I think it would have made a far better C for 64-bit machines, but there
> are these practical matters.

Someone popped up yesterday and said they liked PDOS
because they wanted an MSDOS-like system but that
operated on terabytes of data or whatever. ie DOS64.

I have already produced a DOS32 (depending on your
definition of "DOS"), and the limit to producing a DOS64
is largely down to what cc64 defines "long" as.

> (My own systems language is all-64-bit, but there I have to create new
> mindings for any external libraries anyway, and those will use 'int32'
> wherever 'int' is used in the library.)
>
> But if you want to do the experiment, I can have a go, /after/ I have a
> decent version of my new 'MCC' product, perhaps a couple of weeks.
> (Currently it can compile and run cc.c, a new version of cc64.c, but not
> sql.c.)

Sure, no rush. Thanks.

BFN. Paul.

On 22/09/2023 22:17, Paul Edwards wrote:
> On Friday, September 22, 2023 at 10:03:57 PM UTC+8, Bart wrote:
>
>> Funnily enough, I've been spending the last few weeks adapting an IL
>> designed for a 64-bit int, to make it work with C which uses a mix of 32
>> and 64 bits, with defaults of 32 bits.
>>
>> Changing 'long' is easy; it is (in bcc/cc64) an alias for 'int' anyway.
>
> Well - not that easy - I did a search for "long" in cc64.c
> and didn't see the relevant code that would need to be
> changed.

With generated code, many essential named constants are replaced with
literals. The relevant bit in cc64.c is this:

} else if (!!((u64)(d.islong))) {
if (!!(cc_decls_wintarget)) {
t = (!!((u64)(d.isunsigned))?(i64)9:(i64)4);
} else {
t = (!!((u64)(d.isunsigned))?(i64)10:(i64)5);
};

in function "cc_parse_readdeclspec()", line 17879 in my cc64.c. That
corresponds to this code in the original language (I think early
versions could work with headers from either OS before it was fixed on
Windows):

elsif d.islong then
if wintarget then
t:=(d.isunsigned|tuint|tsint)
else
t:=(d.isunsigned|tullong|tsllong)
fi

So for a 64-bit 'long' replace that C with:

} else if (!!((u64)(d.islong))) {
t = (!!((u64)(d.isunsigned))?(i64)10:(i64)5);

Note that 'long' is syntactically an attribute rather than a type, and
appears in constructs like 'int long unsigned'. There is no token 'long'
that is defined as either ti32 or ti64; C is complex that way.

> Note that with SubC, short/int/long are all the same.
> I have tested some of my code with SubC with all-32-bit
> and a little bit with all-64-bit.

According to the SubC Readme:

"The following keywords are not recognized: const, double, float, goto,
long, short, signed, unsigned."

so it doesn't have "short" or "long", unless you have added those as
simple aliases for "int", but then you can do "short int" and so on.

But I'm surprised it can have a 64-bit 'int' since code generation would
need quite a lot of changes. And SubC itself would likely need a 64-bit
int to be able to compile integer constants like '12345678987654321'.

(Or is code generation still for a 32-bit target with 64-bit ints emulated?)

If I produced a C compiler with 64-bit 'int', it would still be a
reasonably full spec. I wouldn't want to dumb it down by saying the only
types are the equivalents of u8 and i64.

Paul Edwards <mutazilah@gmail.com> writes:
> On Friday, September 22, 2023 at 10:03:57 PM UTC+8, Bart wrote:
>
>> Funnily enough, I've been spending the last few weeks adapting an IL
>> designed for a 64-bit int, to make it work with C which uses a mix of 32
>> and 64 bits, with defaults of 32 bits.
>>
>> Changing 'long' is easy; it is (in bcc/cc64) an alias for 'int' anyway.
>
> Well - not that easy - I did a search for "long" in cc64.c
> and didn't see the relevant code that would need to be
> changed.

If you want C standard conformance, int and long are distinct types,
even if they have the same representation.

>> Changing 'int' to 64 bits is an experiment I've tried before. One that
>> failed, since apart from the libraries that expect 'int' as 32 bits,
>> most programs I would want to test it with also assume a 32-bit int.
>>
>> So testing it thoroughly would be difficult.
>
> I don't need it tested - I can do that myself with my own
> "test suite", ie the executables that get distributed with
> UCX64.
>
> Assuming 32-bit int is against C90. If I have any code that
> violates C90 I want it fixed regardless.

C90, like all later versions of C, requires int to be at least 16 bits.

(Some of) the rules are:
- char, signed char, unsigned char are at least 8 bits; all are distinct types
- int is at least 16 bits
- long is at least 32 bits
- long long is at least 64 bits (added in C99)
- Each type in the above list is at least as wide as the previous ones.

>> There are other questions: what do you make 'short'? How do you denote a
>> 16-bit or 32-bit type? They can't both be short!
>
> There wouldn't be a 16-bit type. C90 doesn't guarantee
> such a thing exists.

Correct, but it can be convenient to have types covering 8, 16, and 32
bits, and 64 for C99 or later. That's (probably) part of why int has
remained at 32 bits even on 64-bit systems. C99 introduced extended
integer types, which could be used to fill in any gaps, but as far as I
know no compilers provide them.

[...]

> I see that cc64.c has this:
>
> typedef uint16_t u16;
>
> I expect I would be changing uint16_t (not guaranteed
> to exist, even in C99) to uint_fast16_t

For C99 and later, uint_fast16_t (and uint_least16_t) are required to
exist. uint16_t exists if and only if there's a type that satisfies its
requirements.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Bart <bc@freeuk.com> writes:
[...]
> Note that 'long' is syntactically an attribute rather than a type, and
> appears in constructs like 'int long unsigned'. There is no token
> 'long' that is defined as either ti32 or ti64; C is complex that way.

Assuming we're talking about C, void, char, short, int, long, float,
double, signed, and unsigned are all *type specifiers*. Certain
combinations of these type specifiers form type names, including each of
them by itself. `long` is a keyword, a type specifier, and a type name.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 22/09/2023 23:55, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> Note that 'long' is syntactically an attribute rather than a type, and
>> appears in constructs like 'int long unsigned'. There is no token
>> 'long' that is defined as either ti32 or ti64; C is complex that way.
>
> Assuming we're talking about C, void, char, short, int, long, float,
> double, signed, and unsigned are all *type specifiers*. Certain
> combinations of these type specifiers form type names, including each of
> them by itself. `long` is a keyword, a type specifier, and a type name.
>
> [...]
>

I'm just pointing out that it is a little more elaborate than in
languages with simple, single-token types. So making 'long' a different
type can't done by changing a symbol table.

In my C compiler, 'int' and 'long' are defined in the ST like this [not
C code]:

("int", ktypespecsym, ts_int),
("long", ktypespecsym, ts_long),

In my non-C compiler, "int" is defined in the ST like this (there is no
"long"):

("int", stdtypesym, ti64),

'ti64' is an actual type code, which could be trivially changed to
'ti32'; 'ts_int' isn't. The process of turning "int" in C into an actual
type is longer.

On Saturday, September 23, 2023 at 6:16:38 AM UTC+8, Bart wrote:

> So for a 64-bit 'long' replace that C with:
>
> } else if (!!((u64)(d.islong))) {
> t = (!!((u64)(d.isunsigned))?(i64)10:(i64)5);

Fantastic! Literally a one-line change.

I'm dying to give that a go. I will try it out soon hopefully.

> > Note that with SubC, short/int/long are all the same.

(Ok - I didn't expect my sentence to get scrutinized so
heavily. In MY USE of SubC, short/int/long are all the
same, because I first run a (better - possibly perfect)
preprocessor with -Dshort=int -Dlong=int before handing
the output to SubC.

> so it doesn't have "short" or "long", unless you have added those as
> simple aliases for "int", but then you can do "short int" and so on.

I rarely ever use "short". And whenever I use either short
or long, I just type "short" or "long". If any code is found
that has an extraneous "int" after that, I am happy to trim
that down to my natural coding style to overcome the
limitation in SubC.

I'm not happy to diverge from my natural coding style,
so I put #ifdef around CC64 restrictions, except in a
couple of places. E.g. I think I had a prototype of:

int foo(int);

and CC64 didn't like that, so I made it:

int foo(int x);

which I would normally have done anyway, and the first
was an oversight that I am happy to change.

> But I'm surprised it can have a 64-bit 'int' since code generation would
> need quite a lot of changes. And SubC itself would likely need a 64-bit
> int to be able to compile integer constants like '12345678987654321'.
>
> (Or is code generation still for a 32-bit target with 64-bit ints emulated?)

You can compile on any platform (16, 32, 64, 36), and the generated
code will use rax etc. And use the cdecl calling convention. And
AT&T syntax.

I don't understand the issue. And the SubC code itself doesn't
have such large constants, but yes, you would presumably
need a SubC that has been built on a 64-bit machine, for it
to handle those large constants.

> If I produced a C compiler with 64-bit 'int', it would still be a
> reasonably full spec. I wouldn't want to dumb it down by saying the only
> types are the equivalents of u8 and i64.

That's fine and great.

But am willing to settle for less, and if you - or someone
who modifies SubC - is only able to produce the lesser,
I'll take whatever first appears. And change later. My
code is (meant to be) all C90, so I can change compiler
on whim.

BFN. Paul.

On Saturday, September 23, 2023 at 6:50:57 AM UTC+8, Keith Thompson wrote:

> > Well - not that easy - I did a search for "long" in cc64.c
> > and didn't see the relevant code that would need to be
> > changed.

> If you want C standard conformance, int and long are distinct types,
> even if they have the same representation.

Such a thing would be nice, but more than I need.

I need a C compiler that will accept my C90-conforming
code, not one that enforces C90 compliance, even if the
C90 standard insists that the compiler must enforce that.

You previously quoted from the C90 standard saying that
a diagnostic needs to be issued in a certain case - I'm not
saying its wrong to do that, but I don't NEED it. If it's there,
that's fine - I'm not going to ask for it to be removed. But
nor do I care if I am using a compiler that doesn't have it.

There is probably a nice way to word my position/philosophy,
but I don't know it. I can only tell you specific end results.

Just like the C90 standard itself. It may look like I'm a C90
diehard, but I'm not. I'm just not budging from it without a
reason that I understand.

I recently have a reason. I want to see the hex codes for
ESC and all the ASCII control characters in a header file.

E.g.

chardefs.h

CHAR_ESC_CHAR 0x1b
CHAR_ESC_STR "\x1b"

CHAR_CTRLA_CHAR 0x01
CHAR_CTRLA_STR "\x01"

The reason I need this is because I can't write micro-emacs
portably (ie ANSI X3.64 - plus an EBCDIC variant)
without it (when porting to EBCDIC).

Otherwise all my applications (toolchain) are portable
(or can be made so).

Any suggestions on header file name and defines?

BFN. Paul.

On Saturday, September 23, 2023 at 3:21:14 PM UTC+8, Paul Edwards wrote:

> > } else if (!!((u64)(d.islong))) {
> > t = (!!((u64)(d.isunsigned))?(i64)10:(i64)5);
> Fantastic! Literally a one-line change.
>
> I'm dying to give that a go. I will try it out soon hopefully.

I found the code, it worked from the brief testing. I then
looked at the UEFI environment and found that everything
was 64-bit already (ie file read/write plus seek).

I will hopefully produce a UEFI executable tomorrow or
whatever, but in the meantime I have a quandry.

One thing led to another and I thought I should have
a bootx128.efi that was nominally 32-bit int, 64-bit
long and 128-bit long long. With the caveat that you
must write C90 code. Which means nobody can
actually complain that "long long" doesn't produce
128-bit code because cc64 doesn't do that yet (or
potentially ever).

And then this would be designed to run Win128 programs,
where long is 64-bit, as is fseek in the msvcrt.dll.

It's really just a sneaky way of making long 64-bit.

But then I realized maybe I needed a bootx64t.efi,
where t = true (64-bit).

But then there would potentially be a more-truer,
where int is also 64-bit. And then within that, both
a variant with 16-bit short and a variant with
32-bit short.

And there could be more variants than that.

Is there a sensible naming standard?

Note that regardless of what the bootxxxx.efi is called,
to work with existing x64 systems it would simply be
renamed to bootx64.efi. UEFI itself is defined in terms
of a totally 64-bit interface with specific registers for
a specific calling convention and none of that will
actually change.

What I do internally to feed UEFI an int/long/long long
(whichever is 64-bit) is unknown/transparent to UEFI.

It's not transparent for the Winxxxx applications though.
They need to match the msvcrt.dll so need a specific
compiler to be used.

BFN. Paul.

Also, I was planning on combining PDOS/86 and
PDOS/386 and PDOS/x64 into a single distribution,
and the io.sys loader would detect the CPU and load
the appropriate PDOS8086.SYS or PDOS386.SYS
or PDOSX64.SYS (assuming legacy boot) and then
the path would use c:\dos16, c:\dos32 or c:\dos64
as appropriate.

And a bootx64.efi would be on the same disk for a
UEFI system, and also point to the win64 executables
in c:\dos64.

Note that the DOS16/32/64 directories would have a
lot of executables the same name, but be independently
compiled for the relevant CPU.

And the DOS32/64 directories could be renamed to WIN32/64.

And the DOS16 executables could one day be built with a
compiler that supports the Win32/64 API (as far as
the CreateDirectoryA etc functions are concerned) - assuming
real Win16 doesn't already have that.

I have no particular desire to embed an entire C library in all
my 16-bit executables so that they can run on MSDOS/Freedos/etc.

So would it make sense to rename my DOSxx directories
to WINxx?

Note that the original intention was to replace Microsoft in
the sentence "Until Microsoft makes DOS 32-bit, DOS
extenders are just a kludge" which I think I read in C_ECHO
(Fidonet).

I didn't (and still don't really) know what the very definition
of 32-bit DOS is in that sentence.

Now that I'm gearing up for a 64-bit DOS (or Windows or
whatever the hell it is), it would probably be a good time
to know what it technically is.

Also I have a PDOS-generic alternative to msvcrt.dll.
It is similar to EFI in that the OS passes the app all
the function in the C library, so they are available for
callback.

I don't need a special DLL-supporting 16-bit linker to
implement that in PDOS/86.

If I continue with that model, then I could have BOTH
a DOS16 and WIN16 (and 32/64/128 variants).

This is all compounded by the fact that I don't have a
specific goal in mind other than writing everything
in C90 (e.g. Microemacs 3.6 has been updated),
plus ANSI X3.64 for fullscreen apps.

Any suggestions on rationalization?

BFN. Paul.