When hard disks started exceeding 2 GiB,
but processors were still 32-bit, did anyone
create a compiler for the 80386 that did
64-bit longs while everything else (pointers,
size_t) was still 32-bits?

Or was there a technical barrier to that?

Come to think of it, that's probably exactly
what I want for my OS. If my OS can read
large disks (which use a "long" in C90), that's
good enough. Almost all applications would
use a 32-bit long and be fast. It doesn't matter
if the OS is a bit slow because all longs are
64-bit, even when they don't need to be.

A system is expected to be bottlenecked on
running applications, on the CPU, not inefficient
disk operations by the OS because 64-bit
non-native integers are being used.

What would be involved in getting the i386
target of GCC 3.2.3 to support such a model?

Thanks. Paul.

On 2021-05-13, muta...@gmail.com <mutazilah@gmail.com> wrote:
> When hard disks started exceeding 2 GiB,
> but processors were still 32-bit, did anyone
> create a compiler for the 80386 that did
> 64-bit longs while everything else (pointers,
> size_t) was still 32-bits?
>
> Or was there a technical barrier to that?

C99 introduced "long long". Compilers had extensions for 64 bit types
before this, including GCC.

> What would be involved in getting the i386
> target of GCC 3.2.3 to support such a model?

Why wouldn't you at least use the GCC 3 end-of-life
version, which I recall was 3.4.6?

GCC 3 has long long, including as an extension in C90 mode.

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

On Friday, May 14, 2021 at 7:20:42 AM UTC+10, Kaz Kylheku wrote:

> On 2021-05-13, muta...@gmail.com <muta...@gmail.com> wrote:
> > When hard disks started exceeding 2 GiB,
> > but processors were still 32-bit, did anyone
> > create a compiler for the 80386 that did
> > 64-bit longs while everything else (pointers,
> > size_t) was still 32-bits?
> >
> > Or was there a technical barrier to that?

> C99 introduced "long long". Compilers had extensions for 64 bit types
> before this, including GCC.

Good point! I should be able to hook into that logic.

> > What would be involved in getting the i386
> > target of GCC 3.2.3 to support such a model?

> Why wouldn't you at least use the GCC 3 end-of-life
> version, which I recall was 3.4.6?

I compiled 3.4.6 for MVS, but ran into three problems:

1. It had runtime bugs which didn't exist in 3.2.3, and
there's no-one around to fix them.

2. The generated files are now built by a process that
requires manipulation of filenames that can't be
created on MVS.

3. The largest file or object code exceeds 1 cylinder
of a 3390 disk, which prevents me from using a crude
space allocation algorithm in PDOS/3X0. I tried
doubling it to 2 cylinders, but that caused a 3390-1 to
be exceeded, and any bigger 3390s break the 2 GiB
limit of PDOS/x86.

Number 3 will be fixed by PDOS/3X0 improvements
at an appropriate date, but it has been many years
so far.

> GCC 3 has long long, including as an extension in C90 mode.

Ok, thanks.

BFN. Paul.

muta...@gmail.com <mutazilah@gmail.com> wrote:
> When hard disks started exceeding 2 GiB,
> but processors were still 32-bit, did anyone
> create a compiler for the 80386 that did
> 64-bit longs while everything else (pointers,
> size_t) was still 32-bits?
<snip>
> What would be involved in getting the i386
> target of GCC 3.2.3 to support such a model?

Try and you will know. GCC 3.2.3 on i386 supports
64-bit integer types and size of buit-in types is
defined early during initialization. Change
initialization and you will know what else needs
to be changed. I suspect that main work in C
library, in particular in code ensuring that
compier and library agree.

--
Waldek Hebisch

"muta...@gmail.com" <mutazilah@gmail.com> writes:
>When hard disks started exceeding 2 GiB,
>but processors were still 32-bit, did anyone
>create a compiler for the 80386 that did
>64-bit longs while everything else (pointers,
>size_t) was still 32-bits?

Disks were accessed by sector number, not by
offset.

When _files_ larger than 2GB became common, the Large File
Summit devised extensions to Unix/Posix API's to support
a 64-bit off_t (I was part of the LFS group).

https://en.wikipedia.org/wiki/Large-file_support

https://www.opengroup.org/platform/lfs.html

Kaz Kylheku <563-365-8930@kylheku.com> wrote:
> On 2021-05-13, muta...@gmail.com <mutazilah@gmail.com> wrote:
>> When hard disks started exceeding 2 GiB,
>> but processors were still 32-bit, did anyone
>> create a compiler for the 80386 that did
>> 64-bit longs while everything else (pointers,
>> size_t) was still 32-bits?
>>
>> Or was there a technical barrier to that?
>
> C99 introduced "long long". Compilers had extensions for 64 bit types
> before this, including GCC.
>
>> What would be involved in getting the i386
>> target of GCC 3.2.3 to support such a model?
>
> Why wouldn't you at least use the GCC 3 end-of-life
> version, which I recall was 3.4.6?
>
> GCC 3 has long long, including as an extension in C90 mode.
>

AFAICT, GCC has supported a long long type since at least 1.35, April 1989.
It may have been among the earliest compilers to do so. See
http://port70.net/~nsz/c/c89/longlong.html

GCC seems to have accepted the token sequence "long long" since 0.9 (1987),
but doesn't seem to have treated it specially. Release 1.30 (1988) supported
a proper long long type, but only on architectures with native support.[1]
Software emulation (see gnulib2.c) came with release 1.35.[2]

[1] I can't find the source code for 1.30. But support is clearly in 1.31
(also released 1988), where according to ChangeLog it was added before the
1.30 release.

[2] Not ChangeLog entry but it first appears between 1.34 and 1.35. See
http://www.netgull.com/gcc/old-releases/gcc-1/patches/gcc.diff-1.34-1.35.bz2

On Saturday, May 15, 2021 at 4:11:26 AM UTC+10, Scott Lurndal wrote:

> "muta...@gmail.com" <muta...@gmail.com> writes:
> >When hard disks started exceeding 2 GiB,
> >but processors were still 32-bit, did anyone
> >create a compiler for the 80386 that did
> >64-bit longs while everything else (pointers,
> >size_t) was still 32-bits?

> Disks were accessed by sector number, not by
> offset.

I think a better abstraction for disks is access by
byte offset.

That way there is no problem when 4096-byte sectors
are used, no problem when a 3350 disk is used with
19069-byte tracks with what amounts to variable-length
"sectors" (blocks), no problem with SSD disks. And I
think UEFI uses a byte offset too.

> When _files_ larger than 2GB became common, the Large File
> Summit devised extensions to Unix/Posix API's to support
> a 64-bit off_t (I was part of the LFS group).

Any reason why long wasn't extended to 64-bits, even
on an 80386? Isn't this exactly why we have short/int/long?

And that way the plethora of existing code works.
Instead of a new type and new functions, which
necessarily resolve to a "long" in C90 anyway.

Perhaps in hindsight off_t should have been used
for fseek right from the start. What is the underlying
principle? Never use a base type? Always abstract
it. And then provide a facility to print it, because
printf won't know what to do with an abstract type?

BFN. Paul.

"muta...@gmail.com" <mutazilah@gmail.com> writes:
>On Saturday, May 15, 2021 at 4:11:26 AM UTC+10, Scott Lurndal wrote:
>
>> "muta...@gmail.com" <muta...@gmail.com> writes:
>> >When hard disks started exceeding 2 GiB,
>> >but processors were still 32-bit, did anyone
>> >create a compiler for the 80386 that did
>> >64-bit longs while everything else (pointers,
>> >size_t) was still 32-bits?
>
>> Disks were accessed by sector number, not by
>> offset.
>
>I think a better abstraction for disks is access by
>byte offset.

At the application level, it already is. Operating
systems dumped the fixed-record/blocking garbage back
in the early days of unix.

Applications can always impose their own record
structure on a simple stream of bytes.

Applications don't need to and should _never_ have
to deal directly with the underlying storage
media, which makes the sector size or other access
granule irrelevent.

>> When _files_ larger than 2GB became common, the Large File
>> Summit devised extensions to Unix/Posix API's to support
>> a 64-bit off_t (I was part of the LFS group).
>
>Any reason why long wasn't extended to 64-bits, even
>on an 80386? Isn't this exactly why we have short/int/long?

POSIX defines interfaces, not hardware, and not compilers,
which it deferred (at the time) to C89/C90. LFS was based
on the POSIX interface set.

Note that at the time, the x86 architecture wasn't widely
used with POSIX interfaces, unix being primarily a set of
mostly compatible proprietary offerings from various hardware
manufactors, many of which already had 64-bit longs (MIPS,
PowerPC, Sparc, Alpha).

On Tuesday, May 18, 2021 at 2:21:18 AM UTC+10, muta...@gmail.com wrote:

> Perhaps in hindsight off_t should have been used
> for fseek right from the start. What is the underlying
> principle? Never use a base type? Always abstract
> it. And then provide a facility to print it, because
> printf won't know what to do with an abstract type?

I had a thought about these abstract types. Let's
say it's just something simple like "cents" for
money as an integer.

C90 gives you the flexibility to have a 64-bit long
if you need it, but with 32-bit registers that will be
expensive, so you want the flexibility to limit your
financial application to 32 bits if you live in a
country where 32-bits worth of cents is enough.

Regardless.

typedef long cents;

#define cents_qualifier "l"
(could instead be "" or "h" and I won't mention "ll")

cents x = 50;

printf("you have %" cents_qualifier "u cents in your bank account, x);

That way you don't need to harass ISO to add a plethora
of types to printf.

In addition, I don't think Microsoft C should qualify as
C90 or at least C90+ compliant in their model where
size_t (64 bits) exceeds long (32 bits).

I think size_t should only be definable in one of the
C90 data types actually available in C90, so that
"long" is always big enough to store every integer
type.

BFN. Paul.

On 5/17/2021 11:01 AM, Scott Lurndal wrote:
> "muta...@gmail.com" <mutazilah@gmail.com> writes:
>> On Saturday, May 15, 2021 at 4:11:26 AM UTC+10, Scott Lurndal wrote:
>>
>>> "muta...@gmail.com" <muta...@gmail.com> writes:
>>>> When hard disks started exceeding 2 GiB,
>>>> but processors were still 32-bit, did anyone
>>>> create a compiler for the 80386 that did
>>>> 64-bit longs while everything else (pointers,
>>>> size_t) was still 32-bits?
>>
>>> Disks were accessed by sector number, not by
>>> offset.
>>
>> I think a better abstraction for disks is access by
>> byte offset.
>
> At the application level, it already is. Operating
> systems dumped the fixed-record/blocking garbage back
> in the early days of unix.
>
> Applications can always impose their own record
> structure on a simple stream of bytes.
>
> Applications don't need to and should _never_ have
> to deal directly with the underlying storage
> media, which makes the sector size or other access
> granule irrelevent.
>
>
>>> When _files_ larger than 2GB became common, the Large File
>>> Summit devised extensions to Unix/Posix API's to support
>>> a 64-bit off_t (I was part of the LFS group).
>>
>> Any reason why long wasn't extended to 64-bits, even
>> on an 80386? Isn't this exactly why we have short/int/long?
>
> POSIX defines interfaces, not hardware, and not compilers,
> which it deferred (at the time) to C89/C90. LFS was based
> on the POSIX interface set.

It does not define compilers, but it can be a pain when a compiler
claims to support POSIX, but has bugs:

https://groups.google.com/g/comp.programming.threads/c/Y_Y2DZOWErM/m/JI3i5zlA2H0J

>
> Note that at the time, the x86 architecture wasn't widely
> used with POSIX interfaces, unix being primarily a set of
> mostly compatible proprietary offerings from various hardware
> manufactors, many of which already had 64-bit longs (MIPS,
> PowerPC, Sparc, Alpha).
>

On 5/17/2021 1:51 PM, Chris M. Thomasson wrote:
> On 5/17/2021 11:01 AM, Scott Lurndal wrote:
>> "muta...@gmail.com" <mutazilah@gmail.com> writes:
>>> On Saturday, May 15, 2021 at 4:11:26 AM UTC+10, Scott Lurndal wrote:
>>>
>>>> "muta...@gmail.com" <muta...@gmail.com> writes:
>>>>> When hard disks started exceeding 2 GiB,
>>>>> but processors were still 32-bit, did anyone
>>>>> create a compiler for the 80386 that did
>>>>> 64-bit longs while everything else (pointers,
>>>>> size_t) was still 32-bits?
>>>
>>>> Disks were accessed by sector number, not by
>>>> offset.
>>>
>>> I think a better abstraction for disks is access by
>>> byte offset.
>>
>> At the application level, it already is.   Operating
>> systems dumped the fixed-record/blocking garbage back
>> in the early days of unix.
>>
>> Applications can always impose their own record
>> structure on a simple stream of bytes.
>>
>> Applications don't need to and should _never_ have
>> to deal directly with the underlying storage
>> media, which makes the sector size or other access
>> granule irrelevent.
>>
>>
>>>> When _files_ larger than 2GB became common, the Large File
>>>> Summit devised extensions to Unix/Posix API's to support
>>>> a 64-bit off_t (I was part of the LFS group).
>>>
>>> Any reason why long wasn't extended to 64-bits, even
>>> on an 80386? Isn't this exactly why we have short/int/long?
>>
>> POSIX defines interfaces, not hardware, and not compilers,
>> which it deferred (at the time) to C89/C90.  LFS was based
>> on the POSIX interface set.
>
> It does not define compilers, but it can be a pain when a compiler
> claims to support POSIX, but has bugs:
>
> https://groups.google.com/g/comp.programming.threads/c/Y_Y2DZOWErM/m/JI3i5zlA2H0J
[...]

Love this response from Dave Butenhof:

https://groups.google.com/g/comp.programming.threads/c/Y_Y2DZOWErM/m/DVeoCCZBn3IJ

I miss talking to him. Iirc, the last time we had a conversation, he was
actually thinking about creating a new book called Cooking with POSIX
Threads... ;^)

On 17/05/2021 17:21, muta...@gmail.com wrote:
> Any reason why long wasn't extended to 64-bits, even
> on an 80386? Isn't this exactly why we have short/int/long?

IIRC the '286 you started with doesn't have 64-bit arithmetic, so each
operation would involve multiple instructions to handle carry and so forth.

I don't recall what the '386s do, and my manual is by my desk at work.
Which I've only seen for 5 minutes in the last year...

Andy

On Tuesday, May 18, 2021 at 7:04:47 AM UTC+10, Vir Campestris wrote:

> > Any reason why long wasn't extended to 64-bits, even
> > on an 80386? Isn't this exactly why we have short/int/long?

> IIRC the '286 you started with doesn't have 64-bit arithmetic, so each
> operation would involve multiple instructions to handle carry and so forth.
>
> I don't recall what the '386s do, and my manual is by my desk at work.
> Which I've only seen for 5 minutes in the last year...

If the 16-bit 80286 restricts itself to accessing 2 GiB files,
so be it.

I'm interested in the 32-bit 80836, so several instructions
required to do 64-bit operations.

It seems to me that Ritchie covered everything with
short/int/long. If you're on a 32-bit machine and you
want to do 64-bit arithmetic, then make "long" 64-bit.
It will be slow, but that's what it's for. If you want to
be fast, and can live with 32 bits, use "int".

There's no need for a "long long" and there's no need
for a fpos_t type and new functions.

BFN. Paul.

On 17/05/2021 23:00, muta...@gmail.com wrote:
> On Tuesday, May 18, 2021 at 7:04:47 AM UTC+10, Vir Campestris wrote:
>
>>> Any reason why long wasn't extended to 64-bits, even
>>> on an 80386? Isn't this exactly why we have short/int/long?
>
>> IIRC the '286 you started with doesn't have 64-bit arithmetic, so each
>> operation would involve multiple instructions to handle carry and so forth.
>>
>> I don't recall what the '386s do, and my manual is by my desk at work.
>> Which I've only seen for 5 minutes in the last year...
>
> If the 16-bit 80286 restricts itself to accessing 2 GiB files,
> so be it.
>
> I'm interested in the 32-bit 80836, so several instructions
> required to do 64-bit operations.
>
> It seems to me that Ritchie covered everything with
> short/int/long. If you're on a 32-bit machine and you
> want to do 64-bit arithmetic, then make "long" 64-bit.
> It will be slow, but that's what it's for. If you want to
> be fast, and can live with 32 bits, use "int".
>
> There's no need for a "long long" and there's no need
> for a fpos_t type and new functions.

If starting from scratch then it makes sense to settle on:

char 8 bits
short 16
int 32
long 64

'long long' could be reserved for 128 bits but that's a going to be
difficult on a 32-bit processor.

You certainly don't need that other zoo of types that includes clock_t,
off_t, size_t and so on.

But are you in effect starting again? Usually you don't get to redefine
the C language, and even if you tried, most existing code you will come
across will make its own assumptions.

Programs from the era you're interested in will likely have 16-bit ints.
And most platforms these days, except 64-bit Linux, will likely have
32-bit longs, and a lot of software will assume that.

On Tuesday, May 18, 2021 at 8:26:24 AM UTC+10, Bart wrote:

> > I'm interested in the 32-bit 80836, so several instructions
> > required to do 64-bit operations.
> >
> > It seems to me that Ritchie covered everything with
> > short/int/long. If you're on a 32-bit machine and you
> > want to do 64-bit arithmetic, then make "long" 64-bit.
> > It will be slow, but that's what it's for. If you want to
> > be fast, and can live with 32 bits, use "int".
> >
> > There's no need for a "long long" and there's no need
> > for a fpos_t type and new functions.

> If starting from scratch then it makes sense to settle on:
>
> char 8 bits
> short 16
> int 32
> long 64

I'm guessing that's what Ritchie had in mind. He had
everything covered already for a very long time. Well
past 2021.

> 'long long' could be reserved for 128 bits but that's a going to be
> difficult on a 32-bit processor.

Well, if we ever reach that stage, rather than add yet
more fundamental types, it's probably time to retire
16-bit "short" and shift everything up. Processors
probably don't even have the ability to do 16-bit
arithmetic anyway. The S/370 doesn't have such
instructions.

The language has enough types already.

> You certainly don't need that other zoo of types that includes clock_t,
> off_t, size_t and so on.

I think you need size_t. Why do you think we don't
need that?

And if you don't need to print clock_t, which you don't,
what's wrong with having an abstract type for it? What
principle do you think is at play?

> But are you in effect starting again?

I don't really know what I'm trying to do. I'm still trying
to understand the principles.

There is a language, C90. What's wrong with it? I've
been coding to it for 3 decades, and haven't really
noticed any problem. But I'm not a language expert.

C90 is a superset of what Ritchie came up with. Did
Ritchie not have enough foresight, and that's why we
needed ISO to come up with C99? I'm not convinced.

> Usually you don't get to redefine
> the C language, and even if you tried, most existing code you will come
> across will make its own assumptions.

I'm not the one redefining it. I got C90 and then struggled
to get K&R 1 fans to accept it. I don't know how to live
without memmove(). I pointed out that Ritchie himself
had accepted C90, and I was told that he had gone
insane or something.

Someone else decided to pressure ISO to change the
language and add a whole grab-bag into C99.

> Programs from the era you're interested in will likely have 16-bit ints.
> And most platforms these days, except 64-bit Linux, will likely have
> 32-bit longs, and a lot of software will assume that.

Well - I can tell you that I'm not interested in software
that makes non-C90 assumptions.

I'm only interested in running properly-written programs.

Specifically I want to make sure that I personally am writing
"properly-written programs".

I have not even reached that fundamental point where I am
confident that my own programs are C90-compliant.

Nor have I even reached the point where I'm satisfied that
Ritchie got everything right, well, after a little bit of
fine-tuning by reality and ANSI/ISO. I don't yet have the
skills required to critique Ritchie's work. So after 30 years,
I haven't moved on from 1990. I effectively have a time
machine though, so I know what's going to happen in the
next 30 years with regard to hardware. I don't really give
a toss about the software. I'll rewrite every aspect of that
if I find something I don't like. But I'm not going to rewrite
it for the sake of rewriting it. I started with a 32-bit version
of MSDOS, and now I still have that, but also a 32-bit
version of Windows. But I'm unlikely to actually use the
Windows API. I will use the MSDOS API. That doesn't have
crap like SECURITY_ATTRIBUTES. It has stuff like "int".
At least once the Pos* layer is applied. But that's up for
negotiation too.

BFN. Paul.

On 18/05/2021 00:16, muta...@gmail.com wrote:
> On Tuesday, May 18, 2021 at 8:26:24 AM UTC+10, Bart wrote:
>
>>> I'm interested in the 32-bit 80836, so several instructions
>>> required to do 64-bit operations.
>>>
>>> It seems to me that Ritchie covered everything with
>>> short/int/long. If you're on a 32-bit machine and you
>>> want to do 64-bit arithmetic, then make "long" 64-bit.
>>> It will be slow, but that's what it's for. If you want to
>>> be fast, and can live with 32 bits, use "int".
>>>
>>> There's no need for a "long long" and there's no need
>>> for a fpos_t type and new functions.
>
>> If starting from scratch then it makes sense to settle on:
>>
>> char 8 bits
>> short 16
>> int 32
>> long 64
>
> I'm guessing that's what Ritchie had in mind. He had
> everything covered already for a very long time. Well
> past 2021.
>
>> 'long long' could be reserved for 128 bits but that's a going to be
>> difficult on a 32-bit processor.
>
> Well, if we ever reach that stage, rather than add yet
> more fundamental types, it's probably time to retire
> 16-bit "short" and shift everything up. Processors
> probably don't even have the ability to do 16-bit
> arithmetic anyway. The S/370 doesn't have such
> instructions.
>
> The language has enough types already.
>
>> You certainly don't need that other zoo of types that includes clock_t,
>> off_t, size_t and so on.
>
> I think you need size_t. Why do you think we don't
> need that?

If some type needs to be variable because it will be different between
32-bit and 64-bit systems, then don't have a dozen different ones for
different purposes.

At most you will need 4 generic types: an int type whose width depends
on the target machine word size; and one that depends on pointer size;
plus signed/unsigned versions of each.

(Since I only code for 64-bit machines, I'd forgotten there was a need
for such things. A 64-bit signed int will suffice as a 'size_t' for
pretty any purpose.)

The trouble with such things is this: people will make assumptions, that
size_t is always the same size of as int, or is always double the size,
and then things will go badly wrong when they aren't.

> And if you don't need to print clock_t, which you don't,
> what's wrong with having an abstract type for it? What
> principle do you think is at play?

Obviously you've never tried to use clock() via an FFI from another
language! I've seen clock_t buried under SIX layers of typedefs and
macros. You may however have needed to print the value from clock(), so
what format code to use?

FFS it's just a number. Why have a different type for each function that
returns a number?

On Tuesday, May 18, 2021 at 11:13:32 AM UTC+10, Bart wrote:

> >> You certainly don't need that other zoo of types that includes clock_t,
> >> off_t, size_t and so on.
> >
> > I think you need size_t. Why do you think we don't
> > need that?

> If some type needs to be variable because it will be different between
> 32-bit and 64-bit systems, then don't have a dozen different ones for
> different purposes.
>
> At most you will need 4 generic types: an int type whose width depends
> on the target machine word size; and one that depends on pointer size;
> plus signed/unsigned versions of each.

It's unclear to me what a target machine's "word size"
even is. And whether you even want to use that if you
know what it is.

An x64 can do 32-bit and 64-bit operations efficiently,
and if you stick with 32-bit your data is more likely to
be cached.

> (Since I only code for 64-bit machines, I'd forgotten there was a need
> for such things. A 64-bit signed int will suffice as a 'size_t' for
> pretty any purpose.)

For coding on the 8086, I need to choose between an
efficient 16-bit size_t, or if I want to access more than
64k buffers, ie huge memory model, giving access to
1 MiB of memory potentially, I need 32-bit size_t.

I'm happy to rebuild all my software with an appropriate
memory model.

I can't code either "int" or "long" for this purpose.

I don't think I can anyway, even if I'm able to rebuild
the compiler. Neither type seems to be appropriate.

> The trouble with such things is this: people will make assumptions, that
> size_t is always the same size of as int, or is always double the size,
> and then things will go badly wrong when they aren't.

I don't care what happens when people disobey the rules.

I just want to have sensible rules. Derived from first
principles. First principles should *exist*, right?

> > And if you don't need to print clock_t, which you don't,
> > what's wrong with having an abstract type for it? What
> > principle do you think is at play?

> Obviously you've never tried to use clock() via an FFI from another
> language! I've seen clock_t buried under SIX layers of typedefs and
> macros. You may however have needed to print the value from clock(), so
> what format code to use?

Good point. I think that is like size_t - no way was given to
print it. But I think following C90 rules we can be sure that
all these types can at most be a "long", so just typecast to
long and %ld?

> FFS it's just a number. Why have a different type for each function that
> returns a number?

To allow efficient implementation? Otherwise everything can
just be a long. No matter how horrendous that may be on an
8086 that has decided to make longs 64-bit to access large
files, whatever the cost may be.

Note that I am interested in supporting 16-bit, 32-bit and 64-bit
systems, so I'm after recommendations for that.

Possibly 8-bit in the future too.

I'm willing for the 8-bit and 16-bit to be *slow*, in deference
to 32-bit and 64-bit, but not fail to work *at all*.

BFN. Paul.

Bart <bc@freeuk.com> writes:

> ... You may however have needed to print the value from clock(), so
> what format code to use?

A good choice in portable code is to convert to double use your choice
of %g, %f etc. You may already have a double because you might be doing
this:

double start = clock();
...
printf("That took %.1fs\n", (clock() - start)/CLOCKS_PER_SEC);

or the slightly safer, but fussier,

double start = clock()/(double)CLOCKS_PER_SEC;
...
printf("That took %.1fs\n", clock()/(double)CLOCKS_PER_SEC - start);

--
Ben.

On 18/05/2021 00:26, Bart wrote:
> On 17/05/2021 23:00, muta...@gmail.com wrote:
>> On Tuesday, May 18, 2021 at 7:04:47 AM UTC+10, Vir Campestris wrote:
>>
>>>> Any reason why long wasn't extended to 64-bits, even
>>>> on an 80386? Isn't this exactly why we have short/int/long?
>>
>>> IIRC the '286 you started with doesn't have 64-bit arithmetic, so each
>>> operation would involve multiple instructions to handle carry and so
>>> forth.
>>>
>>> I don't recall what the '386s do, and my manual is by my desk at work.
>>> Which I've only seen for 5 minutes in the last year...
>>
>> If the 16-bit 80286 restricts itself to accessing 2 GiB files,
>> so be it.
>>
>> I'm interested in the 32-bit 80836, so several instructions
>> required to do 64-bit operations.
>>
>> It seems to me that Ritchie covered everything with
>> short/int/long. If you're on a 32-bit machine and you
>> want to do 64-bit arithmetic, then make "long" 64-bit.
>> It will be slow, but that's what it's for. If you want to
>> be fast, and can live with 32 bits, use "int".
>>
>> There's no need for a "long long" and there's no need
>> for a fpos_t type and new functions.
>
> If starting from scratch then it makes sense to settle on:
>
>  char    8 bits
>  short  16
>  int    32
>  long   64
>
> 'long long' could be reserved for 128 bits but that's a going to be
> difficult on a 32-bit processor.

It would not be difficult - it's just 4 32-bit parts. It's bigger and
slower than 2 32-bit parts for 64-bit types, but the same principle.
(Division is always really ugly for such multi-part arithmetic.) Any
8-bit C compiler can handle 32-bit types fine - some support 64-bit types.

>
> You certainly don't need that other zoo of types that includes clock_t,
> off_t, size_t and so on.

It's not clear if you mean "starting a language from scratch" or
"starting a C implementation from scratch". For a new language, there
are many possibilities but calling things "short" or "long" is unlikely
to be a good choice. And for a C implementation, you most certainly
/do/ need size_t and many other types (which are defined as macros and
will always be other existing integer types).

>
> But are you in effect starting again? Usually you don't get to redefine
> the C language, and even if you tried, most existing code you will come
> across will make its own assumptions.
>
> Programs from the era you're interested in will likely have 16-bit ints.
> And most platforms these days, except 64-bit Linux, will likely have
> 32-bit longs, and a lot of software will assume that.

On 18/05/2021 09:14, muta...@gmail.com wrote:
> On Tuesday, May 18, 2021 at 4:54:40 PM UTC+10, David Brown wrote:
>
>> For a new language, there
>> are many possibilities but calling things "short" or "long" is unlikely
>> to be a good choice.
>
> Why do you say that?
>
> What are the first principles you are working from?
> (that Ritchie was apparently not aware of - and I
> certainly aren't)
>
> Thanks. Paul.
>

C was conceived around 50 years ago, designed to work with the machines
of the time (both in terms of the hosts for compilers, and the target
machines), designed for the programs of the time, and designed with a
view to being better than the languages around at that time.

We have a far greater range of languages now, with a wide selection of
balances between features, simplicity, run-time efficiency, developer
efficiency, ease-of-use, safety, etc. Some are more minimal, with
perhaps just a single integer type at 64-bit, others have a selection of
different sizes for different purposes.

IME and IMHO, I would say there are three basic kinds of integers,
depending on their usage.

There are low-level uses - required for interaction with hardware,
connection to data outside the program (file formats, network protocols,
foreign-function interfaces, etc.), or for when you want accurate
control such as for getting maximal efficiency from large data
structures. In these cases, you want size-specific types. Whether you
call them int32_t, i32, Int<32>, etc., is a matter of taste. But they
should be size-specific and explicit.

There are "just a number" uses - a counter, an index, etc. The type for
this needs to be big enough that it is not going to overflow - the
programmer can treat it as though it were an unlimited size mathematical
integer. These days, that really means 64-bit - or an unlimited integer
type that grows as needed. The type name here should reflect that -
"number" would be good. In C, this is "int".

Then there are uses where you are using something that is really a bit
more abstract, but storing it as an integer type. Then you want a name
that reflects its usage, not its size, and you may want restrictions on
what you can do with the type. C has types like uintptr_t, clock_t and
size_t for this - code using these types should generally avoid being
dependent on the actual size of the types.

At no point do I see any purpose in a type whose name says "this is a
bit shorter than general-purpose numbers" or "this is a bit longer than
general-purpose numbers", /especially/ when these descriptions might not
actually be accurate.

In my own C (and C++) code, I use size-specific types (int32_t,
uint16_t, etc.), some purpose-specific types (such as uintptr_t,
size_t), and "int" for general numbers. I use "char" strictly for
letters, string data and other character data, and of course "bool" for
true/false flags. To me, "long" and "short" are as outdated as
non-prototype function declarations.

On Tuesday, May 18, 2021 at 5:49:00 PM UTC+10, David Brown wrote:

Thanks for your interesting thoughts!

> There are low-level uses - required for interaction with hardware,
> connection to data outside the program (file formats, network protocols,
> foreign-function interfaces, etc.), or for when you want accurate
> control such as for getting maximal efficiency from large data
> structures. In these cases, you want size-specific types. Whether you
> call them int32_t, i32, Int<32>, etc., is a matter of taste. But they
> should be size-specific and explicit.

When it comes to external file formats, you also need
to take into account endianness. As such, isn't it more
appropriate to be operating at a byte level? My FAT
processing code is all done in bytes and ready to go
to the Amiga etc.

You could argue that on the Amiga the FAT format
should morph into an Amiga-FAT though, with its
endianness.

> There are "just a number" uses - a counter, an index, etc. The type for
> this needs to be big enough that it is not going to overflow - the
> programmer can treat it as though it were an unlimited size mathematical
> integer. These days, that really means 64-bit - or an unlimited integer
> type that grows as needed. The type name here should reflect that -
> "number" would be good. In C, this is "int".

But int is almost always 32-bits "these days". How do you
reconcile that?

> At no point do I see any purpose in a type whose name says "this is a
> bit shorter than general-purpose numbers" or "this is a bit longer than
> general-purpose numbers", /especially/ when these descriptions might not
> actually be accurate.

That certainly makes sense. I have almost never
coded "short".

Although I would say that "long" would mean "give
me whatever you're capable of, even if it is slow".

I don't think you should cheat by assuming only
64-bit processors. So on a 16-bit processor, don't
you want to distinguish between fast 16-bit
integers and slow 32-bit file offsets?

What else are you going to call a file offset? You
think off_t is the appropriate thing to use and
fseek() should have used that from day 1?

> In my own C (and C++) code, I use size-specific types (int32_t,
> uint16_t, etc.), some purpose-specific types (such as uintptr_t,
> size_t), and "int" for general numbers. I use "char" strictly for
> letters, string data and other character data, and of course "bool" for
> true/false flags. To me, "long" and "short" are as outdated as
> non-prototype function declarations.

I'm wondering whether int32_t is the thing that has
any meaning.

Is there really something magical about 32 bits?
The number of people in the world? Currency values?

For a file format you need FOUR_BYTE_LITTLE_ENDIAN.
And a macro to populate that from a suitable data type,
probably a "long".

Maybe it was Ritchie who was right, not ISO C99.
But perhaps drop "short" as a direct application type?

BFN. Paul.

On 18/05/2021 10:14, muta...@gmail.com wrote:
> On Tuesday, May 18, 2021 at 5:49:00 PM UTC+10, David Brown wrote:
>
> Thanks for your interesting thoughts!
>
>> There are low-level uses - required for interaction with hardware,
>> connection to data outside the program (file formats, network protocols,
>> foreign-function interfaces, etc.), or for when you want accurate
>> control such as for getting maximal efficiency from large data
>> structures. In these cases, you want size-specific types. Whether you
>> call them int32_t, i32, Int<32>, etc., is a matter of taste. But they
>> should be size-specific and explicit.
>
> When it comes to external file formats, you also need
> to take into account endianness. As such, isn't it more
> appropriate to be operating at a byte level? My FAT
> processing code is all done in bytes and ready to go
> to the Amiga etc.

Yes, endianness is important - as is alignment. Operating at byte level
avoids that effect (you still need a "byte" type of some sort. C99's
"uint8_t" is ideal here - C90's "char" is not.) Operating at byte level
can be inefficient, however.

In a new language - or as an extension to C - you could have a way to
express endianness as well as size for fixed size types.

Fixed sizes are still vital for many other kinds of interactions.

Often a programmer also wants types that match C99's "int_least16_t" and
"int_fast16_t" families. These are useful when you know you need at
least 16 bits of range, and want as small a size as possible (for
efficient memory and cache use with large data structures) or as fast as
possible (some cpus are inefficient at handling smaller data types). In
practice, however, programmers would usually pick "int16_t" here as the
disadvantages in efficiency and portability are typically very minor
compared to the convenience of knowing the exact size.

>
> You could argue that on the Amiga the FAT format
> should morph into an Amiga-FAT though, with its
> endianness.
>
>> There are "just a number" uses - a counter, an index, etc. The type for
>> this needs to be big enough that it is not going to overflow - the
>> programmer can treat it as though it were an unlimited size mathematical
>> integer. These days, that really means 64-bit - or an unlimited integer
>> type that grows as needed. The type name here should reflect that -
>> "number" would be good. In C, this is "int".
>
> But int is almost always 32-bits "these days". How do you
> reconcile that?

Backwards compatibility.

In some more modern languages, 64-bit is the default size for the
equivalent of a "number".

Of course you could still have 32-bit for more limited hardware (e.g.,
embedded systems rather than PC's).

>
>> At no point do I see any purpose in a type whose name says "this is a
>> bit shorter than general-purpose numbers" or "this is a bit longer than
>> general-purpose numbers", /especially/ when these descriptions might not
>> actually be accurate.
>
> That certainly makes sense. I have almost never
> coded "short".
>
> Although I would say that "long" would mean "give
> me whatever you're capable of, even if it is slow".
>

That is not what the name says (at least to me), nor how the type is
defined in C. In C, "intmax_t" is "the biggest integer type you have".

> I don't think you should cheat by assuming only
> 64-bit processors. So on a 16-bit processor, don't
> you want to distinguish between fast 16-bit
> integers and slow 32-bit file offsets?

I'm fine with "number" being 32-bit on smaller systems - it can be
somewhat target dependent. But 16-bit is too small for a general number
- when using 16-bit, programmers need to be aware of the limitations and
the likely risk of overflows. When you want 16 bits, name it explicitly.

>
> What else are you going to call a file offset? You
> think off_t is the appropriate thing to use and
> fseek() should have used that from day 1?
>

"file_offset_t" would be a good first choice. I don't see a need for
minimal characters in a type name here.

>> In my own C (and C++) code, I use size-specific types (int32_t,
>> uint16_t, etc.), some purpose-specific types (such as uintptr_t,
>> size_t), and "int" for general numbers. I use "char" strictly for
>> letters, string data and other character data, and of course "bool" for
>> true/false flags. To me, "long" and "short" are as outdated as
>> non-prototype function declarations.
>
> I'm wondering whether int32_t is the thing that has
> any meaning.
>
> Is there really something magical about 32 bits?
> The number of people in the world? Currency values?
>

It is simply a size that is heavily used. In the early days of digital
computing, different sizes were used, but the industry solidified on
8-bit bytes and power-of-two steps up from there. There /are/ systems
today that have char size bigger than 8, and integer types that are not
power-of-two chars, but they are rare and niche (some DSP's and other
specialised processors). A general-purpose language can usually forget
about them.

> For a file format you need FOUR_BYTE_LITTLE_ENDIAN.
> And a macro to populate that from a suitable data type,
> probably a "long".

This is your fantasy, not mine - I can give my opinion as to why I think
"long" has no place in a programming language, but you make the decisions.

>
> Maybe it was Ritchie who was right, not ISO C99.
> But perhaps drop "short" as a direct application type?
>
> BFN. Paul.
>

On 18/05/2021 09:14, muta...@gmail.com wrote:

> But int is almost always 32-bits "these days". How do you
> reconcile that?

Because most existing C programs would likely break if 'int' was
suddenly 64 bits.

>> At no point do I see any purpose in a type whose name says "this is a
>> bit shorter than general-purpose numbers" or "this is a bit longer than
>> general-purpose numbers", /especially/ when these descriptions might not
>> actually be accurate.
>
> That certainly makes sense. I have almost never
> coded "short".
>
> Although I would say that "long" would mean "give
> me whatever you're capable of, even if it is slow".
>
> I don't think you should cheat by assuming only
> 64-bit processors.

Why is it any more cheating than assuming 32-bit processors over 16-bits
or 8-bits?

What is magic about 80386?

> So on a 16-bit processor, don't
> you want to distinguish between fast 16-bit
> integers and slow 32-bit file offsets?
>
> What else are you going to call a file offset? You
> think off_t is the appropriate thing to use and
> fseek() should have used that from day 1?

These are the fstat functions that Microsoft ended up with for
information about a file's size and creation time:

fstat, fstat32, fstat64, fstati64, fstat32i64, fstat64i32

Six functions, but there are two variations of each of fstat and fstat32
depending on some global macro that determined whether the time was a
32- or 64-bit type.

So in the end, there are 8 combinations, but end result is that time
might be 32 or 64 bits, and file size might be 32 or 64 bits. (There's
further complications as I think some used a struct of two ints to
represent 64 bits, others used an actual 64-bit int.)

This is the mess that MS got into because of the transition from
16/32-bit system to full 64 bits, which didn't quite coincidence with
the development of large file systems.

You've decided to go back in time just so we can have all the same
problems again!

For a 'time', just use 64 bits; for a file offset; just use 64 bits. You
might need to decide whether to use i64 or u64, but the range of i64 is
so wide, it doesn't really matter. i64 has equivalent positive range to
a u63 type.

Nobody who's ever going to use your system is going to thank you for
reinventing that same mess.

https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fstat-fstat32-fstat64-fstati64-fstat32i64-fstat64i32?view=msvc-160

DB:
>> In my own C (and C++) code, I use size-specific types (int32_t,
>> uint16_t, etc.), some purpose-specific types (such as uintptr_t,
>> size_t), and "int" for general numbers. I use "char" strictly for
>> letters, string data and other character data, and of course "bool" for
>> true/false flags. To me, "long" and "short" are as outdated as
>> non-prototype function declarations.
>
> I'm wondering whether int32_t is the thing that has
> any meaning.
>
> Is there really something magical about 32 bits?

In the computer world, then yes, since practically every machine is
based on power-of-two word sizes.

On 18/05/2021 02:44, muta...@gmail.com wrote:
> On Tuesday, May 18, 2021 at 11:13:32 AM UTC+10, Bart wrote:

>> FFS it's just a number. Why have a different type for each function that
>> returns a number?
>
> To allow efficient implementation? Otherwise everything can
> just be a long. No matter how horrendous that may be on an
> 8086 that has decided to make longs 64-bit to access large
> files, whatever the cost may be.
>
> Note that I am interested in supporting 16-bit, 32-bit and 64-bit
> systems, so I'm after recommendations for that.
> Possibly 8-bit in the future too.

Then you are creating extra problems. You may need a special type that
is different things across those 4 architectures (pointers will already
be different).

You need to decide whether each of those systems will only ever be used
with matching, contemporary hardware, so that an 8-bit system will only
ever see a 100MB drive for example, and which means a file-size type can
be specific to it.

Or whether you plan on allowing an 8-bit system to access a 2TB drive,
then you will need the same 64-bit file-size type as used on current
machines.

> I'm willing for the 8-bit and 16-bit to be *slow*, in deference
> to 32-bit and 64-bit, but not fail to work *at all*.

Another approach then is for 8- and 16-bit machines to run emulators for
larger machines. That will be extra slow.

(I've think I seen a video of 6502 running a emulator that was running
Linux.)

On Tuesday, 18 May 2021 at 09:14:37 UTC+1, muta...@gmail.com wrote:
>
> > There are "just a number" uses - a counter, an index, etc. The type for
> > this needs to be big enough that it is not going to overflow - the
> > programmer can treat it as though it were an unlimited size mathematical
> > integer. These days, that really means 64-bit - or an unlimited integer
> > type that grows as needed. The type name here should reflect that -
> > "number" would be good. In C, this is "int".
> But int is almost always 32-bits "these days". How do you
> reconcile that?
>
You only rarely have 2 billion data points. A 1024 * 1024 image is quite large,
for example, but it's only a million pixels.
Whist modern CPU operations with 64 bits will be as fast as 32 bit operations, you
can store more 32 bit integers in the cache, and it's cache mises which are
the main determiner of performance.