On Wednesday, May 19, 2021 at 6:53:56 AM UTC+10, Bart wrote:

> >> 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.
> >
> > That's a *really* bad idea. Anyone using those types (especially short)
> > is using them because they have an expectation regarding how wide they
> > are. Violating that expectation is a great way to break code.

Anyone who assumes that shorts are 16 bits, no
more, has written broken code. An unstated
assumption I have is that I have no interest
whatsoever in broken code.

I'd like to know how everything (compilers, operating
systems, standards) should be set for people willing
to obey the rules.

Anyone else can do whatever they want.

> It's a bad idea also because if you have a requirement for an array of
> elements that are too big for 8 bits but will fit within 16, then it
> means using twice the memory if 32 bits have to be used.

Yes, at the time you start having 128 bit longs, so what?

What sort of code are we talking about that needs
128 bit longs but is memory-constrained so needs
shorts to be restricted to 16 bits?

And you can add to that the fact that I've almost
never personally coded "short". I always code "int"
and let it expand, to give my code more flexibility
and performance. I've never coded for a
memory-constrained environment where short is
smaller than int. Have you? I'm from 1990. Most
people seem to be from 2021. Which environment
anywhere from 1990-2021 are people feeling the
need to use "short" instead of "int" because of
memory constraints?

> Plus it makes it impossible to interface to anything else that has
> arrays, structs and pointers that involved 16-bit types.

Another unstated assumption I have is that you have
the source code and are willing to recompile all your
software with a new processor, or a new configuration
within the same processor.

If you're talking outside of that, I'm happy to concede
whatever you want.

But within those constraints, I'd like to know what
complaints you have.

BFN. Paul.

On Wednesday, May 19, 2021 at 4:12:12 AM UTC+10, Kaz Kylheku wrote:

> >> What are the first principles you are working from?
> >> (that Ritchie was apparently not aware of - and I
> >> certainly aren't)
> >
> > Unexpected numbers of bytes in words has caused fifty years of anguish
> > for programmers caught unawares. Much, much better to have specified
> > the size of the variables in a way similar to the 'int32_t' and related
> > types that have been grafted on after the fact now.

> I simply cannot agree with:
>
> #include <unistd.h>
>
> What if that thinking had been applied thirty years ago?
> Then we would be stuck with:
>
> int main(int16 argc, char **argv)
>
> C would be famous for not handling more than 32767 program arguments on
> any platform.

This is a really great point.

> The type int has nicely scaled with increasing platform capabilities.
> On a platform with 16 or 18 bit int, you wouldn't have that many
> arguments to a program. On a 32 bit platform you conceivably could; and
> by golly, your "int argc" has scaled up to handle that, without a
> code change having been required.

Yep, brilliant. That is exactly what I am after - a language,
starting in 1990 or even 1890, that is going to scale with
increasing platform capabilities.

Even if we accept the seemingly-absurd notion that one
day hardware engineers will plug in more than 4 GiB of
addressable memory.

I'm willing to accept the notion that 36-bit integers are
an aberration, like the IBM 1401, that shouldn't be used
as an excuse to hold back a language from being able
to generate efficient machine code. This is because
people at the time didn't have the benefit of hindsight.
I do.

We're going to end up with 8/16/32/64/128/256. Fine.

However, integers may be aligned (z/Arch), characters
may be EBCDIC, and may be big-endian (z/Arch). And
you can't will these platforms out of existence (an
assumption I am making).

And although I know where we're going to end up,
hardware-wise, I want a language that provides the
stepping stones, preferably starting with 8-bit
registers, but at least 16-bit registers, all the way
up to 64-bit registers, and even give some
half-hearted consideration for 128-bit and 256-bit,
to at least get the conceptual framework right,
even if God personally appears saying "nope, the
hardware engineers will perform miracles, but
I'm going to zap them before they get too big for
their boots".

I think Ritchie got it right.

Specific types (int32_t) to manipulate hardware
(even assuming that is the correct solution)
belong in a separate standard. C for application
use shouldn't have been polluted, and fortunately
C90 wasn't.

So I'm not budging until ISO return to their senses,
come back to 1990, and we negotiate a C90+.

BFN. Paul.

On Wednesday, May 19, 2021 at 2:01:49 AM UTC+10, David Brown wrote:

> Representation is two's complement for signed integers, IEEE for
> floating point, no padding bits. There hasn't been anything else made
> for the last 40 years or so, except a few Burroughs mainframes.

Are you talking about IBM mainframes? They have
padding bits.

> If you need the absolute most portable code, then you have to do things
> long-hand with reading chars, building up your bigger types as you go.
> Certainly it can be done - but it is nice not to have to do it.

Maybe the discussion needs to be split to clarify what
we are talking about.

You can't assume little-endian, even in 2021. IBM
mainframes exist, and are big-endian. And they're
usually EBCDIC, but even assuming they are ASCII
(as is the case with z/Linux), you can't blindly write
out an int32_t.

If this is the problem you are solving, then why not
ask ISO to create some functions that work on
z/Linux too?

> > Giving the language
> > size-specific integers is not the solution to this problem, but it's a
> > cheap one and has caught on at the expense of doing it "properly".
> >
> Define "properly". Maximal portability is a requirement for some code -
> usually, it is not. If you are already using POSIX network functions or
> Windows file functions to get the data, then you can safely use
> <stdint.h> fixed-size types and you can make assumptions about various
> other implementation-specific features. There is no point in making
> code needlessly non-portable, but equally there is no point in making it
> needlessly portable.

This is a good point. Once you start using POSIX network
functions, you may as well be using C++ or Java. There's
nothing much to argue about.

To have a sensible discussion I think we need to be talking
about portable code. Writing out int32_t is not going to give
you portable code, so what problem is being solved?

Direct hardware manipulation is not portable either, so no
need to mention it in that context.

We can discuss which platforms C should be catering for
with regards to portability. Once we rule out the IBM 1401
and that Burroughs machine Scott mentioned, we shouldn't
be shy about ruling out 36-bit registers too.

We could conceivably rule out EBCDIC and big endian while
we're at it, but I'm personally reluctant to do that for as long
as monkeys keep going to work, in 2021, and populating
spinning rust with EBCDIC characters they just generated
by bashing away at a keyboard.

So for me, I want to see *at least* the following platforms
covered:

8086, 80386, x64, 68000, 68020, S/370-XA (has MVCLE),
z/Arch.

BFN. Paul.

On 18/05/2021 22:22, muta...@gmail.com wrote:
> On Wednesday, May 19, 2021 at 6:53:56 AM UTC+10, Bart wrote:

> Anyone who assumes that shorts are 16 bits, no
> more, has written broken code.

So what should they do instead?

>> It's a bad idea also because if you have a requirement for an array of
>> elements that are too big for 8 bits but will fit within 16, then it
>> means using twice the memory if 32 bits have to be used.
>
> Yes, at the time you start having 128 bit longs, so what?

What? Having occasional need for 128-bit values doesn't mean you have
memory, processor time or bandwidth to waste.

If you need to store a billion numbers that will never be above 1000,
say, what array size element do you want to use?

16-bit (short) elements will need 2GB. 32-bit elements will need 4GB,
with half of that wasted.

> What sort of code are we talking about that needs
> 128 bit longs but is memory-constrained so needs
> shorts to be restricted to 16 bits?
>
> And you can add to that the fact that I've almost
> never personally coded "short". I always code "int"
> and let it expand, to give my code more flexibility
> and performance. I've never coded for a
> memory-constrained environment where short is
> smaller than int. Have you? I'm from 1990. Most
> people seem to be from 2021.

Most people here are not young and will be familiar with lower spec
hardware. Having 64-bits available doesn't mean going mad and using it
for absolutely everything.

But for individual variables, parameters and return values there is
little advantage to not using it, since registers, stack slots, and
pointers are all 64 bits anyway. If you have a LOT of data however, you
should keep widths to a minimum.

How many years have you been coding? This is basic stuff...

>> Plus it makes it impossible to interface to anything else that has
>> arrays, structs and pointers that involved 16-bit types.
>
> Another unstated assumption I have is that you have
> the source code and are willing to recompile all your
> software with a new processor, or a new configuration
> within the same processor.

This is a fantasy. So you're going to rewrite all the world's software,
all its libraries, reinvent all the binary file formats include video,
image and audio, redesign all the chips in peripherals so that they
never use 16-bit registers...

....just because you personally have never used a datatype between 'char'
and 'int'? I assume you still have 'char', or is that done away with too?

I've also lost track here of exactly what it is you're trying to
reinvent. I mean, why bother with C, just invent another language for
your purposes. Or is C good enough except for the 3/4 of it that you
don't like?

On 5/18/2021 3:43 AM, Malcolm McLean wrote:
> 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,

To go to "print" wrt fractals, produce a 1920*8x1080*8 image is quite
normal.

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

Bart <bc@freeuk.com> writes:
> On 18/05/2021 22:22, muta...@gmail.com wrote:
>> On Wednesday, May 19, 2021 at 6:53:56 AM UTC+10, Bart wrote:
>> Anyone who assumes that shorts are 16 bits, no
>> more, has written broken code.
>
> So what should they do instead?

They should *not* assume that shorts are 16 bits, no more.

A more detailed answer than that would require a more detailed question.
What should they do *in what circumstances*? What are the actual
requirements?

[...]

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

"muta...@gmail.com" <mutazilah@gmail.com> writes:
> On Wednesday, May 19, 2021 at 2:01:49 AM UTC+10, David Brown wrote:
>> Representation is two's complement for signed integers, IEEE for
>> floating point, no padding bits. There hasn't been anything else made
>> for the last 40 years or so, except a few Burroughs mainframes.
>
> Are you talking about IBM mainframes? They have
> padding bits.

Can you provide more details? Which IBM mainframes? Which types? What
are their sizes and upper and lower bounds?

[...]

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

On 5/13/2021 2:01 PM, 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?
>
> 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.
>

Check this out, a 63 atomic pointer:

https://groups.google.com/g/comp.lang.asm.x86/c/FScbTaQEYLc/m/X0gAskwQW44J

On 5/18/2021 5:20 PM, Chris M. Thomasson wrote:
> On 5/13/2021 2:01 PM, 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?
>>
>> 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.
>>
>
> Check this out, a 63 atomic pointer:
>
> https://groups.google.com/g/comp.lang.asm.x86/c/FScbTaQEYLc/m/X0gAskwQW44J

When I first got to converse with Joe Seigh, he is so smart, that it
made me think of the following song:

https://youtu.be/y3hf0T4qpYg

Joe created atomic_ptr! WOW! A 100% true strong thread safety atomic
pointer. Joe even created the first atomic proxy collector:

http://atomic-ptr-plus.sourceforge.net

I am there way back in comp.programming.threads.

On 5/18/2021 5:25 PM, Chris M. Thomasson wrote:
> On 5/18/2021 5:20 PM, Chris M. Thomasson wrote:
>> On 5/13/2021 2:01 PM, 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?
>>>
>>> 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.
>>>
>>
>> Check this out, a 63 atomic pointer:
>>
>> https://groups.google.com/g/comp.lang.asm.x86/c/FScbTaQEYLc/m/X0gAskwQW44J
>>
>
> When I first got to converse with Joe Seigh, he is so smart, that it
> made me think of the following song:
>
> https://youtu.be/y3hf0T4qpYg
>
> Joe created atomic_ptr! WOW! A 100% true strong thread safety atomic
> pointer. Joe even created the first atomic proxy collector:
>
> http://atomic-ptr-plus.sourceforge.net
>
> I am there way back in comp.programming.threads.

A link to atomic_ptr way back in 2002:
https://groups.google.com/g/comp.programming.threads/c/Sev_8xKh3RU/m/wEkEqnOhs_oJ

On Wednesday, May 19, 2021 at 10:07:26 AM UTC+10, Keith Thompson wrote:

> >> Representation is two's complement for signed integers, IEEE for
> >> floating point, no padding bits. There hasn't been anything else made
> >> for the last 40 years or so, except a few Burroughs mainframes.
> >
> > Are you talking about IBM mainframes? They have
> > padding bits.

> Can you provide more details? Which IBM mainframes? Which types? What
> are their sizes and upper and lower bounds?

Apologies. I might have misspoken.

I thought we were talking about structure padding.

IBM compilers align "int" on a 4-byte boundary etc.
I think they no longer give an exception if they are
misaligned, but I believe they used to.

If you guys are talking about something else, it's
beyond my knowledge.

BFN. Paul.

On Wednesday, May 19, 2021 at 8:42:33 AM UTC+10, Bart wrote:

> > Anyone who assumes that shorts are 16 bits, no
> > more, has written broken code.

> So what should they do instead?

I'll defer to Keith to answer that strange question.

> >> It's a bad idea also because if you have a requirement for an array of
> >> elements that are too big for 8 bits but will fit within 16, then it
> >> means using twice the memory if 32 bits have to be used.
> >
> > Yes, at the time you start having 128 bit longs, so what?

> What? Having occasional need for 128-bit values doesn't mean you have
> memory, processor time or bandwidth to waste.

Ok, you want to complicate the language with a "long long"
so that you can occasionally have 128-bit values, while
still retaining 16-bit values.

There is no end to this if you go that route. Shouldn't the
language be extended with an int<128> etc data type with
custom routines? Or why does this even need to be part
of the language?

> If you need to store a billion numbers that will never be above 1000,
> say, what array size element do you want to use?

I normally go for efficiency, so I use an int. But I don't
store billions of numbers personally. If I had to do
that, I would indeed use "short".

> 16-bit (short) elements will need 2GB. 32-bit elements will need 4GB,
> with half of that wasted.

Yes. But I expected a system with a 128-bit native
data type to have a memory capacity of something
in the region of 100000000000 GB of RAM, so
nobody would care about 2 GB.

> > What sort of code are we talking about that needs
> > 128 bit longs but is memory-constrained so needs
> > shorts to be restricted to 16 bits?
> >
> > And you can add to that the fact that I've almost
> > never personally coded "short". I always code "int"
> > and let it expand, to give my code more flexibility
> > and performance. I've never coded for a
> > memory-constrained environment where short is
> > smaller than int. Have you? I'm from 1990. Most
> > people seem to be from 2021.

> Most people here are not young and will be familiar with lower spec
> hardware. Having 64-bits available doesn't mean going mad and using it
> for absolutely everything.

Ok, that's good.

> But for individual variables, parameters and return values there is
> little advantage to not using it, since registers, stack slots, and
> pointers are all 64 bits anyway.

Well that's a case for using a compiler that makes
"int" 64 bits. The source code will still be efficient
on an 8086.

> If you have a LOT of data however, you
> should keep widths to a minimum.
>
> How many years have you been coding? This is basic stuff...

I've been coding since 1986, non-stop, ie at work and
and at home, almost every waking minute.

There have been some periods where something else
had to be done.

Actually, most of the time it's not coding, it's thinking
about code.

> >> Plus it makes it impossible to interface to anything else that has
> >> arrays, structs and pointers that involved 16-bit types.
> >
> > Another unstated assumption I have is that you have
> > the source code and are willing to recompile all your
> > software with a new processor, or a new configuration
> > within the same processor.

> This is a fantasy. So you're going to rewrite all the world's software,
> all its libraries, reinvent all the binary file formats include video,
> image and audio, redesign all the chips in peripherals so that they
> never use 16-bit registers...

There's no such thing as a 16-bit register in C90.
If code hasn't been written assuming that everything
from char to long is 256 bits, I do not care one iota
if it doesn't work. Another unstated assumption, now
stated.

> ...just because you personally have never used a datatype between 'char'
> and 'int'?

No, because I read the relevant bit of C90. There are
minimums, no maximums.

> I assume you still have 'char', or is that done away with too?

I use char. I assume you can't actually do away with
that. I use it heavily. But if someone explains why all
the places I coded char should be replaced with
wchar_t, or alternatively, another type that could be
either char or wchar_t, I'm listening.

> I've also lost track here of exactly what it is you're trying to
> reinvent. I mean, why bother with C, just invent another language for
> your purposes. Or is C good enough except for the 3/4 of it that you
> don't like?

I am not a language expert. I do not have the ability to
challenge C90. I'm asking, not telling. I will continue to
use C90 until someone explains what's wrong with it.
Something specific Ritchie got wrong. Until then, he
may as well be God.

If I had picked up Pascal, and got as far with Pascal as
I got with C, I'd instead be asking "what's wrong with
Pascal?". Again, I'm not a language expert. I won't be
leaving C90 until I'm a language expert, which may
never happen.

BFN. Paul.

On 19/05/2021 00:07, muta...@gmail.com wrote:
> On Wednesday, May 19, 2021 at 2:01:49 AM UTC+10, David Brown wrote:
>
>> Representation is two's complement for signed integers, IEEE for
>> floating point, no padding bits. There hasn't been anything else made
>> for the last 40 years or so, except a few Burroughs mainframes.
>
> Are you talking about IBM mainframes? They have
> padding bits.

I have not used any mainframes, but AFAIK the Power chips used on IBM
systems for the last few decades are 64-bit (previously 32-bit)
big-endian with no padding, two's complement integers, 8-bit char, etc.
Standard stuff.

I know of no systems with padding bits that are currently in use. In
fact, I know of none that existed historically, but I'm sure others can
remember some.

>
>> If you need the absolute most portable code, then you have to do things
>> long-hand with reading chars, building up your bigger types as you go.
>> Certainly it can be done - but it is nice not to have to do it.
>
> Maybe the discussion needs to be split to clarify what
> we are talking about.
>

Fair enough.

> You can't assume little-endian, even in 2021.

I don't assume that. I have worked with several big-endian processors
(including PowerPC microcontrollers, which are a descendant of the Power
processors in IBM mainframes). I also note that many network protocols
use big-endian ordering. So sometimes endian swapping can't be avoided.
Standard C fixed-size integer types won't do the full job here, but can
still be helpful sometimes. A more complete solution that covers
endianness requires extensions in C (like gcc's "scaler_storage_order"
attribute, or endianness qualifiers available in some compilers, or
perhaps extended integer types with other endianness.

> IBM
> mainframes exist, and are big-endian. And they're
> usually EBCDIC, but even assuming they are ASCII
> (as is the case with z/Linux), you can't blindly write
> out an int32_t.
>
> If this is the problem you are solving, then why not
> ask ISO to create some functions that work on
> z/Linux too?
>

You really don't know what "ISO" is, does, or has done, do you? You
mention the organisation regularly in your posts, invariably in an
inappropriate or unrealistic manner.

>>> Giving the language
>>> size-specific integers is not the solution to this problem, but it's a
>>> cheap one and has caught on at the expense of doing it "properly".
>>>
>> Define "properly". Maximal portability is a requirement for some code -
>> usually, it is not. If you are already using POSIX network functions or
>> Windows file functions to get the data, then you can safely use
>> <stdint.h> fixed-size types and you can make assumptions about various
>> other implementation-specific features. There is no point in making
>> code needlessly non-portable, but equally there is no point in making it
>> needlessly portable.
>
> This is a good point. Once you start using POSIX network
> functions, you may as well be using C++ or Java. There's
> nothing much to argue about.

Or you can use C with POSIX, as many people do. You don't have to jump
language.

>
> To have a sensible discussion I think we need to be talking
> about portable code. Writing out int32_t is not going to give
> you portable code, so what problem is being solved?
>
> Direct hardware manipulation is not portable either, so no
> need to mention it in that context.
>

Low-level hardware access has reduced portability, but that does not
mean all related code is non-portable. Sized integer types help make it
portable by working the same way on any system. That means your PCI
card driver can work on 32-bit ARM, 64-bit x86, 64-bit big-endian PPC,
or anything else.

And even for non-portable code, having a consistent naming makes live
easier. I might not share driver code between an 8-bit AVR and a 32-bit
Cortex-M microcontroller, but I'm glad I can write "uint16_t" on both
systems with exactly the same meaning, rather than learning new type
names for each target.

> We can discuss which platforms C should be catering for
> with regards to portability. Once we rule out the IBM 1401
> and that Burroughs machine Scott mentioned, we shouldn't
> be shy about ruling out 36-bit registers too.
>

Sure. Ruling these out for the future does not impact existing software
(including existing C compilers). There is a limit to how long it makes
sense to carry historical baggage into the future. The next C2x
standard will require two's complement signed integers - that means
there will be no C2x compiler for the Burroughs machines. Since these
machines exist purely for historical reasons, running historical
software, that is no loss to them - and a gain in convenience for all
other C programmers.

> We could conceivably rule out EBCDIC and big endian while

The proportion of programmers and users who would be sad to see the end
of EBCDIC is currently absolutely tiny, and getting smaller all the
time. I think in most cases it will only ever by used internally on an
IBM system - all data moving into or out of the system will be in ASCII
or UTF-8.

Big-endian is dead for the future. Existing big-endian processor ISA's
will be around for a good while yet, but new designs are always
little-endian.

> we're at it, but I'm personally reluctant to do that for as long
> as monkeys keep going to work, in 2021, and populating
> spinning rust with EBCDIC characters they just generated
> by bashing away at a keyboard.
>
> So for me, I want to see *at least* the following platforms
> covered:
>
> 8086, 80386, x64, 68000, 68020, S/370-XA (has MVCLE),
> z/Arch.
>
> BFN. Paul.
>

On 19/05/2021 08:23, muta...@gmail.com wrote:
> On Wednesday, May 19, 2021 at 10:07:26 AM UTC+10, Keith Thompson wrote:
>
>>>> Representation is two's complement for signed integers, IEEE for
>>>> floating point, no padding bits. There hasn't been anything else made
>>>> for the last 40 years or so, except a few Burroughs mainframes.
>>>
>>> Are you talking about IBM mainframes? They have
>>> padding bits.
>
>> Can you provide more details? Which IBM mainframes? Which types? What
>> are their sizes and upper and lower bounds?
>
> Apologies. I might have misspoken.
>
> I thought we were talking about structure padding.

I was talking about "padding bits", in integer representations.

Any compiler for any target with a minimal alignment of at least 2 will
have padding bytes in structures.

>
> IBM compilers align "int" on a 4-byte boundary etc.
> I think they no longer give an exception if they are
> misaligned, but I believe they used to.

Most processors can handle misaligned accesses, albeit at a performance
cost, but some do not, and will throw a processor exception. The OS may
handle that exception to provide transparent (but even slower) access to
the misaligned data.

Sometimes a processor will handle misaligned accesses in some
instructions (like normal load/store) but not others (such as SIMD
accesses).

>
> If you guys are talking about something else, it's
> beyond my knowledge.
>
> BFN. Paul.
>

On 19/05/2021 07:45, muta...@gmail.com wrote:
> On Wednesday, May 19, 2021 at 8:42:33 AM UTC+10, Bart wrote:

> I normally go for efficiency, so I use an int. But I don't
> store billions of numbers personally.

I wonder what people use all those GB of memory for then?

> If I had to do
> that, I would indeed use "short".

So it is needed. I thought you were eliminating short completely and
stopping every one else and every other language from using it too.

>> 16-bit (short) elements will need 2GB. 32-bit elements will need 4GB,
>> with half of that wasted.
>
> Yes. But I expected a system with a 128-bit native
> data type to have a memory capacity of something
> in the region of 100000000000 GB of RAM, so
> nobody would care about 2 GB.

An int128 type is nothing special. On x64 and ARM64, it is simply a type
that is double the natural word size of the processor, and requires two
registers to represent instead of one.

That has been the case on every processor I've used; 8-bit ones needed
two 8-bit registers just to store a regular 'int'.

>> But for individual variables, parameters and return values there is
>> little advantage to not using it, since registers, stack slots, and
>> pointers are all 64 bits anyway.
>
> Well that's a case for using a compiler that makes
> "int" 64 bits. The source code will still be efficient
> on an 8086.

Mine (not for C) make int 64 bits. As well as a 128-bit type, it allows
arrays of 4, 2 and 1-bit elements, for even more efficient arrays when
needed.

> There's no such thing as a 16-bit register in C90.

But you may have a memory-mapped device which is only 16-bits wide.

> If code hasn't been written assuming that everything
> from char to long is 256 bits, I do not care one iota
> if it doesn't work. Another unstated assumption, now
> stated.

That makes things very difficult. And incredibly inefficient.

(Funny how you considered my 128-bit type, which works today,
far-fetched above, but you're happy to use a language where char, short,
int, long are all 256 bits each!)

>> ...just because you personally have never used a datatype between 'char'
>> and 'int'?
>
> No, because I read the relevant bit of C90. There are
> minimums, no maximums.

Have you thought about why that is? C had to work on a too diverse set
of architectures to pin things down.

And if there are no maximums, then why stop at 256 bits? Why not 257, or
16777215 bits? [LLVM apparently supports data types up to either 2**23-1
or 2**24-1 bits]

>> I assume you still have 'char', or is that done away with too?
>
> I use char. I assume you can't actually do away with
> that. I use it heavily. But if someone explains why all
> the places I coded char should be replaced with
> wchar_t, or alternatively, another type that could be
> either char or wchar_t, I'm listening.
>
>> I've also lost track here of exactly what it is you're trying to
>> reinvent. I mean, why bother with C, just invent another language for
>> your purposes. Or is C good enough except for the 3/4 of it that you
>> don't like?
>
> I am not a language expert. I do not have the ability to
> challenge C90. I'm asking, not telling. I will continue to
> use C90 until someone explains what's wrong with it.

Well, it's too vague for a start. Forget about fantasy 256-bit machines,
and concentrate on today's 64-bit ones, unless you want your project
(some sort of OS?) to on a

> Something specific Ritchie got wrong. Until then, he
> may as well be God.

Please. Plenty of people devised lower level, machine-oriented systems
languages in that era. Most of them have died out because they weren't
used as an integral part of Unix which inexplicably got popular.

Look at how incredibly messy C's set of integer types are in 2021, a zoo
of dozens of disparate types with ungainly denotations, some compatible,
some not, and compare with the EIGHT types used for the same purposes by
alternative languages, based around i8/16/32/64 u8/16/32/64.

On 19/05/2021 01:05, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 18/05/2021 22:22, muta...@gmail.com wrote:
>>> On Wednesday, May 19, 2021 at 6:53:56 AM UTC+10, Bart wrote:
>>> Anyone who assumes that shorts are 16 bits, no
>>> more, has written broken code.
>>
>> So what should they do instead?
>
> They should *not* assume that shorts are 16 bits, no more.
>
> A more detailed answer than that would require a more detailed question.
> What should they do *in what circumstances*? What are the actual
> requirements?

I'm sure a huge amount of code that uses 'short', uses it in the belief
that it is half the width of 'int'. Further, that it assumes that 'int'
is 32 bits.

If the requirement was a type half the size of 'int', but you don't want
to presume that int is 32 bits, what should people write?

I think that if someone knows their own platform very well, they are
welcome to make such assumptions, perhaps backed up by asserts if
necessary. Platform specs change very rarely. The last big one was 32 to
64 bits, where in the C world apparently little changed (void*/intptr_t
became wider perhaps); when's the next one?

On Wednesday, 19 May 2021 at 11:12:33 UTC+1, Bart wrote:
>
> Look at how incredibly messy C's set of integer types are in 2021, a zoo
> of dozens of disparate types with ungainly denotations, some compatible,
> some not, and compare with the EIGHT types used for the same purposes by
> alternative languages, based around i8/16/32/64 u8/16/32/64.
>
Yes, the underlying reality is that you can have an 8 bit, 16 bit, 32 bit, 64 bit
and maybe 128 bit integers. They can be signed or unsigned, but that only
really matters for 8 bits (if you need values from 16000 - 32000 it's usually
better to go for a 32 bit integer than trying to squeeze into an unsigned 16
bit integer).
But C has developed historically. If we were starting a language from
scratch, we'd do things differently.

On 19/05/2021 11:48, Malcolm McLean wrote:
> On Wednesday, 19 May 2021 at 11:12:33 UTC+1, Bart wrote:
>>
>> Look at how incredibly messy C's set of integer types are in 2021, a zoo
>> of dozens of disparate types with ungainly denotations, some compatible,
>> some not, and compare with the EIGHT types used for the same purposes by
>> alternative languages, based around i8/16/32/64 u8/16/32/64.
>>
> Yes, the underlying reality is that you can have an 8 bit, 16 bit, 32 bit, 64 bit
> and maybe 128 bit integers. They can be signed or unsigned, but that only
> really matters for 8 bits (if you need values from 16000 - 32000 it's usually
> better to go for a 32 bit integer than trying to squeeze into an unsigned 16
> bit integer).

ITYM values from 32768 to 65535. But you wouldn't have to squeeze; they
would fit exactly into u16.

If you are defining struct layouts used in APIs for binary file formats,
and they use u16 for example, then you have to do the same.

And given a 16-bit field which is only ever going to store a positive
value, why not use u16?

> But C has developed historically. If we were starting a language from
> scratch, we'd do things differently.

With C I'm concerned only with desktop-class machines (in which I
include RPi), mainly running x86 and arm processors. But I understand
the rest are mostly not that different.

Then on those machines, those 8 types dominate. By themselves they are
not onerous; only two may be primary types, the rest will be storage
types used with arrays, structs and pointers.

The problem with C is the dog's dinner it makes of even those 8 types,
with dozens of different denotations, plus dozens more ways of writing
those, plus the fact that few are pinned them.

Here's how you might write a u64 type based on long long or long
(technically, this can be 64 bits or wider):

unsigned long long
long unsigned long
long long unsigned
int unsigned long long
unsigned int long long
unsigned long int long
unsigned long long int
int long unsigned long
long int unsigned long
long unsigned int long
long unsigned long int
int long long unsigned
long int long unsigned
long long int unsigned
long long unsigned int
unsigned long # on Linux 64
long unsigned
int unsigned long
unsigned int long
unsigned long int
int unsigned long
unsigned int long
unsigned long int
int long unsigned
long int unsigned
long unsigned int

(I haven't included other possibilities where 'char' is 64 bits and so on.)

If you choose to make it const, then I think there are 124 ways of
writing the combinations with /one/ 'const' (and an unlimited number
with more than one, all legal).

Add 'static', and there are 124 of those. Add static AND const, then
I've no idea.

C99 tried to fix this with just one denotation:

uint64_t

(Here there are only 2 ways of adding either const or static, and 6 ways
of adding both.)

However:

* Since C doesn't define 'long long' other than it's at least 64 bits,
or long other than it's 32 bits or more, these may not be compatible
with uint64_t.

* Any type with 'long long' may or may not be compatible with 'long'

* uint64_t itself may be defined on top of either 'long', or 'long
long', or maybe neither

* Software using uint64_t may need to interact with code based on 'long
long', or maybe 'long', but they may or may not be compatible.

* The rest of the language still uses printf formats based on 'long' and
'long long'.

* The rest of the language still used literal suffixes -L and -LL based
on long and long long litersl

* C99 types will need dozens of obscure macros to do printf formats and
literals

If that isn't a mess, then I don't know what is.

David Brown <david.brown@hesbynett.no> writes:

>Most processors can handle misaligned accesses, albeit at a performance
>cost, but some do not, and will throw a processor exception. The OS may
>handle that exception to provide transparent (but even slower) access to
>the misaligned data.
>
>Sometimes a processor will handle misaligned accesses in some
>instructions (like normal load/store) but not others (such as SIMD
>accesses).

Or it may allow misaligned accesses to "normal" memory but not
to "uncached" or "device" memory. See MAIR registers on ARM
and MTRR on x86/amd.

David Brown <david.brown@hesbynett.no> writes:
>On 19/05/2021 00:07, muta...@gmail.com wrote:
>> On Wednesday, May 19, 2021 at 2:01:49 AM UTC+10, David Brown wrote:
>>
>>> Representation is two's complement for signed integers, IEEE for
>>> floating point, no padding bits. There hasn't been anything else made
>>> for the last 40 years or so, except a few Burroughs mainframes.
>>
>> Are you talking about IBM mainframes? They have
>> padding bits.
>
>I have not used any mainframes, but AFAIK the Power chips used on IBM
>systems for the last few decades are 64-bit (previously 32-bit)
>big-endian with no padding, two's complement integers, 8-bit char, etc.
> Standard stuff.

MIPS chips have historically been big-endian as well.

ARM64 can be little, big or can support both. ARMv7 SETEND
instruction allows code to change the endianness at will.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

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

My son does deep learning at Microsoft. He tells me one of their recent
projects gets 1GB of data per hour.

My daughter does retina research at U Utah. I asked what sort of image
sizes she works with (EM photos of retinas). The conversation went

Me: I'm trying to remember -- how big (in bytes) did you say the images
you're dealing with are? Came across someone saying a 2GB image is
rare.

Her: Lol
Our volumes (stacks of images) are in the terabytes
Off the scope I want to say a standard image (montage of tiles) is
around 50, but that is super off the cuff. I'd have to actually
look to know a real number.

But 50gb images aren't unusual these days.

On Wednesday, 19 May 2021 at 15:19:01 UTC+1, Joe Pfeiffer wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > 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.
> My son does deep learning at Microsoft. He tells me one of their recent
> projects gets 1GB of data per hour.
>
> My daughter does retina research at U Utah. I asked what sort of image
> sizes she works with (EM photos of retinas). The conversation went
>
> Me: I'm trying to remember -- how big (in bytes) did you say the images
> you're dealing with are? Came across someone saying a 2GB image is
> rare.
>
> Her: Lol
> Our volumes (stacks of images) are in the terabytes
> Off the scope I want to say a standard image (montage of tiles) is
> around 50, but that is super off the cuff. I'd have to actually
> look to know a real number.
>
> But 50gb images aren't unusual these days.
>
Humans can resolve about 1 arc minute. Field of view is about 120 degrees.
So that's about 7200 pixels. However not all images are for human viewing.

On 18/05/2021 13:46, Malcolm McLean wrote:
> On Tuesday, 18 May 2021 at 12:06:47 UTC+1, Bart wrote:

>> Weren't you advocating for 64-bit ints everywhere a few years ago? (And
>> didn't we have the same discussion even more recently!)
>>
> Yes. I was advocating for a simplified language and architecture in which
> floating point values and integers are both 64 bits. However most people
> have decided to use 32 bits as the default for an integer, and there are
> reasons for that.

Probably because C does so. And it has it own reasons for /that/.

64-bit processors in consumer stuff have been around for 15 years I think.

Since registers, stack slots, pointers, most ops are at least 64 bits
anyway, why not use that as the default?

The cost of using it for individual variables, as parameter and return
types, is zero. You are still free to use narrower types in arrays and
structs if the range is not needed.

The benefits however are significant. Because all operations in C are
done at 'int' size, and since int is now 64 bits, you can worry about
overflow and its UB a lot less.

You can use plain int in place of those size_t types, or file offset types.

You write 1<<36 without needing to use 1ull<<36 instead.

You can print out a 64-bit int expression just by using "%d"; you don't
need %ld or %lld or PRId64 depending on what alternative type you've had
to use instead.

You can use plain int instead of intptr_t. You can cast pointers to and
from plain into with no loss of info.

You can forget about using unsigned int, for the purposes of extra
range, most of the time. The range of i64 includes that of u32.

This list goes on. For me, it's a no-brainer.

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> 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.
>
>My son does deep learning at Microsoft. He tells me one of their recent
>projects gets 1GB of data per hour.

Chips currently exist which have 100Gb/sec (10GB/sec) ports feeding an array
of general purpose processors, custom co-processors and digital
signal processors, doing heavy processing on the data at line rate.

Machine learning and machine vision systems also have huge data requirements
when used for real-time tasks (e.g. automotive self driving).

As for cache occupancy, it's likely that on a 64-bit CPU, pointers and
SIMD vectors use more cache than unnecessarily large 64-bit integers.

On 19/05/2021 15:58, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 19/05/2021 00:07, muta...@gmail.com wrote:
>>> On Wednesday, May 19, 2021 at 2:01:49 AM UTC+10, David Brown wrote:
>>>
>>>> Representation is two's complement for signed integers, IEEE for
>>>> floating point, no padding bits. There hasn't been anything else made
>>>> for the last 40 years or so, except a few Burroughs mainframes.
>>>
>>> Are you talking about IBM mainframes? They have
>>> padding bits.
>>
>> I have not used any mainframes, but AFAIK the Power chips used on IBM
>> systems for the last few decades are 64-bit (previously 32-bit)
>> big-endian with no padding, two's complement integers, 8-bit char, etc.
>> Standard stuff.
>
> MIPS chips have historically been big-endian as well.

Yes - but most MIPS chips these days are used in little-endian mode.
(Not that MIPS has a bright future ahead of it in any case.)

>
> ARM64 can be little, big or can support both. ARMv7 SETEND
> instruction allows code to change the endianness at will.
>

ARM was originally big-endian, then started supporting both. Many
modern ARM implementations are little-endian only (the endian control
bit is still part of the ISA, but it is fixed at little-endian).