On 19/05/2021 16:46, Bart wrote:
> 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.
>

As is often the case, a "no-brainer" means you are not using your brain.

I would have no objection to "int" being 64-bit on 64-bit systems. But
IMHO it is very poor programming style to use "int" instead of types
such as size_t and intptr_t simply because the sizes are the same.
Programmers mostly left such typeless "everything is int" style behind
50 years ago when they moved from BCPL to C.

Named types are not just for portability (which you are throwing out the
window here), but also for clarity in the code.

Bart <bc@freeuk.com> writes:
>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 cost is not zero. Cache occupancy is one cost (takes twice
as much cache per variable). And there is actually a power cost
between 64-bit and 32-bit arithmetic (small, but non-zero); most
CPU cores will agressively conditional gate the power to the high
32-bits of a 64-bit ALU when they're not needed.

David Brown <david.brown@hesbynett.no> writes:
>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.)

Not in my experience - they've all been in network processing
appliances (switches, gateways, firewalls) where big-endian rules,
for example, consider the Octeon processors.

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

I've personally used big-endian linux kernels on ARMv8, but as you note,
little-endian is the rule, big-endian is the exception.

ARMv8 allows the endianess to differ at each exception level (ring) (SCTLR_ELx[EE]),
so the firmware, hypervisor, operating system and applications can each run
with different endianness. Not that anyone does that, but it is possible.

As noted, ARMv7 has a user-level instruction to change the endianness
on the fly.

Bart <bc@freeuk.com> writes:
> 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.

Any such code is, of course, not portable. Sometimes that's OK.

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

You could do something like this:

#include <stdint.h>
#include <limits.h>

#if INT_MAX == 0x7fff
typedef int8_t half_int;
#elif INT_MAX == 0x7fffffff
typedef int16_t half_int;
#elif INT_MAX == 0x7fffffffffffffff
typedef int32_t half_int;
#else
#error "Unable to define half_int"
#endif

Of course you'll get an error if int8_t, int16_t, or int32_t isn't
defined.

But I've never run into that particular rather odd requirement.
Have you? C doesn't provide an elegant way to define a type half the
width of int, but I can't think of any good reason why it should.
I can certainly imagine a language that would make this easier,
but C doesn't.

Yes, C's integer type system is messy. That's because it evolved over
time, starting with a language that only had a single integer type that
wasn't even explicitly specified, with backward compatibility as a high
priority at each stage of evolution.

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

I don't know.

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

That's padding *bytes*, necessary to satisfy member alignment
requirements.

Padding *bits* are bits within the representation of an integer type
that do not contribute to its value. The concept was first explicitly
acknowledged in C99. Note that the requirements on the predefined
integer types are defines in terms of lower and upper bounds, not sizes.

Most implementations don't use padding bits. They can be necessary if
integer types are implemented on top of floating-point, or if the
hardware only supports signed integer arithmetic and unsigned types
can't use the sign bit as a value bit.

[...]

--
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 19/05/2021 16:45, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> 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 cost is not zero. Cache occupancy is one cost (takes twice
> as much cache per variable).

Most individual parameters need to take up at least one stack slot
anyway, which is going to be 64 bits whether or not the variable is 32
bits only.

Apart from which, up to the first 6 parameters (on Linux64) or the first
4 (on Windows64, but also needs a 32-byte shadow space) are passed in
registers.

Any return type will be passed in a register.

Most individual 64-bit int variables will be locals located on the stack
frame. While they take a bit more memory, most of the action is usually
going to take place within the same few KB of stack memory, so localised.

And here, also, the most used locals will likely reside in registers not
memory.

(Variables that are doubles or pointers will need 64 bits anyway.)

There might be a tiny cost, on x64, for extra instruction prefixes for
some 64-bit ops, but mainly using the 8 legacy registers; the 8 new ones
all need prefixes.

> And there is actually a power cost
> between 64-bit and 32-bit arithmetic (small, but non-zero); most
> CPU cores will agressively conditional gate the power to the high
> 32-bits of a 64-bit ALU when they're not needed.

How does that work? Presumbly some power is needed to remember the state
of those 32 bits. Is power also shut off to the other 15 registers while
operating on the 16th?

On x64, any 32-bit loads into a 64-bit register will zero the top half.
That write needs to be performed, and those bits retained.

Or are you going to tell me that isn't done until the next read of those
bits?

This is all extreme micro-optimisation which shouldn't be the concern of
someone using a HLL and wants the most suitable and convenient types.

On 19/05/2021 16:31, David Brown wrote:
> On 19/05/2021 16:46, Bart wrote:

>> The benefits [of 64-bit int] 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.
>>
>
> As is often the case, a "no-brainer" means you are not using your brain.
>
> I would have no objection to "int" being 64-bit on 64-bit systems. But
> IMHO it is very poor programming style to use "int" instead of types
> such as size_t and intptr_t simply because the sizes are the same.

Think about why those extra types were needed. It's because address
ranges were often greater than provided by the local int type.

With 64-bit ints, that's much less likely to be the case.

> Programmers mostly left such typeless "everything is int" style behind
> 50 years ago when they moved from BCPL to C.

A size /is/ just a number, like innumerable other quantities in a
program. It's hardly as though C gives much type protection.

> Named types are not just for portability (which you are throwing out the
> window here), but also for clarity in the code.

Many languages are dynamically typed without explicit types at all, nor
lots of little int types for different purposes.

Usually such languages are considered clearer.

Bart <bc@freeuk.com> writes:
>On 19/05/2021 16:45, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> 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 cost is not zero. Cache occupancy is one cost (takes twice
>> as much cache per variable).
>
>Most individual parameters need to take up at least one stack slot
>anyway, which is going to be 64 bits whether or not the variable is 32
>bits only.

Nicely irrelevent digression. As you note, all modern architectures store
the first N arguments (for a very reasonable value of N e.g. 6 on
linux or 8+ on ARM64) in registers. Very few functions have more
than 6 arguments.

The auto data on the stack (in the original sense of the word) is far
more interesting and does affect the cache occupancy. As do fields
in structs and static data items.

>Most individual 64-bit int variables will be locals located on the stack
>frame. While they take a bit more memory, most of the action is usually
>going to take place within the same few KB of stack memory, so localised.

It still occupies cache and increases the eviction rate.

>
>And here, also, the most used locals will likely reside in registers not
>memory.

By far, the most prevelent data in a real program will be allocated
off the heap (e.g. structs), but for every four 64-bit locals you
need a cache line, where you can fit eight 32-bit locals in the same line.

>> And there is actually a power cost
>> between 64-bit and 32-bit arithmetic (small, but non-zero); most
>> CPU cores will agressively conditional gate the power to the high
>> 32-bits of a 64-bit ALU when they're not needed.
>
>How does that work? Presumbly some power is needed to remember the state
>of those 32 bits. Is power also shut off to the other 15 registers while
>operating on the 16th?

Conditional clock gating is very widely used to turn off unneeded gates
in circuitry. The ALU doesn't have "registers", it takes two (or more)
inputs (8, 16, 32 or 64 wires) and produces one (or more, e.g. conditional
flags) outputs.

If you're working on 32-bit
data, there is no need to power up the gates required to perform the
arithmetic operation on the high bits, so you gate off the clock signal
to those gates for 32-bit (or 16-bit, or 8-bit) data.

>
>On x64, any 32-bit loads into a 64-bit register will zero the top half.

Zero in hardware is simply a non-asserted signal (Vgnd). So don't assert the
high-32 bits and you get zero. No loading involved, just an AND gate
with one input tied low.

>That write needs to be performed, and those bits retained.

You conditionally clock gate the logic, not the flops (registers).

>
>Or are you going to tell me that isn't done until the next read of those
>bits?

That's certainly a possible optimization, particulary when half the
path is powered off, many registers (e.g. control and status registers)
with unassigned bits simply tie those bits to Vgnd rather than lay down
flops for them.

>
>This is all extreme micro-optimisation which shouldn't be the concern of
>someone using a HLL and wants the most suitable and convenient types.

It is of concern to anyone who cares about application performance. There's
a reason that all the major processors have performance counters for things
like cache hit rates, cache miss rates, TLB hit rates, TLB miss rates,
memory bandwidth, and hundreds of other microarchitectural details (e.g.
store buffer occupancy, etc).

On 19/05/2021 18:53, Bart wrote:
> On 19/05/2021 16:45, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> 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 cost is not zero.   Cache occupancy is one cost (takes twice
>> as much cache per variable).
>
> Most individual parameters need to take up at least one stack slot
> anyway, which is going to be 64 bits whether or not the variable is 32
> bits only.
>

Most parameters are in registers, not stack slots.

> Apart from which, up to the first 6 parameters (on Linux64) or the first
> 4 (on Windows64, but also needs a 32-byte shadow space) are passed in
> registers.
>
> Any return type will be passed in a register.
>
> Most individual 64-bit int variables will be locals located on the stack
> frame.

Most local variables will be in registers. But when data is on the
stack, compilers are likely to pack them in a frame according to size.
64-bit sizes take up more space. (I don't think it is likely to matter
in most cases. But it might be noticeable in highly recursive algorithms.)

> While they take a bit more memory, most of the action is usually
> going to take place within the same few KB of stack memory, so localised.
>
> And here, also, the most used locals will likely reside in registers not
> memory.
>
> (Variables that are doubles or pointers will need 64 bits anyway.)
>
> There might be a tiny cost, on x64, for extra instruction prefixes for
> some 64-bit ops, but mainly using the 8 legacy registers; the 8 new ones
> all need prefixes.
>
>
>> And there is actually a power cost
>> between 64-bit and 32-bit arithmetic (small, but non-zero); most
>> CPU cores will agressively conditional gate the power to the high
>> 32-bits of a 64-bit ALU when they're not needed.
>
> How does that work? Presumbly some power is needed to remember the state
> of those 32 bits. Is power also shut off to the other 15 registers while
> operating on the 16th?
>

You have clock gating on parts of the ALU. I expect it will be most
relevant for multiplies and divides - logic operations are pretty low
power anyway. Addition (and subtraction) might be worth gating, as
carry look-ahead adders get quite big for 64 bits.

It is the clock to the big combinational blocks that gets shut off,
rather than the power to any register bits.

> On x64, any 32-bit loads into a 64-bit register will zero the top half.
> That write needs to be performed, and those bits retained.
>
> Or are you going to tell me that isn't done until the next read of those
> bits?
>
> This is all extreme micro-optimisation which shouldn't be the concern of
> someone using a HLL and wants the most suitable and convenient types.
>

People concerned with having the lowest possible power from their chips
pay attention to surprisingly small details.

One other point about using 32-bit rather than 64-bit for int is that in
some cases a compiler might use SIMD instructions to optimise code -
that will be easier and more effective with smaller types.

(Though as I said, overall I would not object to 64-bit int on 64-bit
processors.)

On 19/05/2021 18:06, Keith Thompson wrote:
>
> Padding *bits* are bits within the representation of an integer type
> that do not contribute to its value. The concept was first explicitly
> acknowledged in C99. Note that the requirements on the predefined
> integer types are defines in terms of lower and upper bounds, not sizes.
>
> Most implementations don't use padding bits. They can be necessary if
> integer types are implemented on top of floating-point, or if the
> hardware only supports signed integer arithmetic and unsigned types
> can't use the sign bit as a value bit.
>

Do you know of any systems that have or had padding bits in their
integer types?

On 19/05/2021 17:52, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> 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.)
>
> Not in my experience - they've all been in network processing
> appliances (switches, gateways, firewalls) where big-endian rules,
> for example, consider the Octeon processors.
>

Yes, for networking appliances big-endian is convenient. These are
perhaps the last bastion of MIPS, but they are getting pushed out by ARM.

(I think this is a shame - MIPS is a perfectly good ISA, and
alternatives mean more competition. It's as unhealthy with ARM
dominance in embedded systems as it is with x86 dominance in desktops
and servers. I'd have like to see more MIPS cores in the
microcontroller world. Perhaps RISC-V will grow competitively.)

>>
>>>
>>> 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).
>
> I've personally used big-endian linux kernels on ARMv8, but as you note,
> little-endian is the rule, big-endian is the exception.
>
> ARMv8 allows the endianess to differ at each exception level (ring) (SCTLR_ELx[EE]),
> so the firmware, hypervisor, operating system and applications can each run
> with different endianness. Not that anyone does that, but it is possible.
>
> As noted, ARMv7 has a user-level instruction to change the endianness
> on the fly.
>

Yes. But on many implementations (I use mainly microcontrollers, where
core size is important - I gather you have more experience with bigger
devices) the instruction doesn't work because the big-endian support is
not there. PowerPC microcontrollers similarly lack support for
little-endian modes even though the control register bits still exist.

On 19/05/2021 18:30, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:

>> And here, also, the most used locals will likely reside in registers not
>> memory.
>
> By far, the most prevelent data in a real program will be allocated
> off the heap (e.g. structs), but for every four 64-bit locals you
> need a cache line, where you can fit eight 32-bit locals in the same line.

But I'm talking about individual variables, that is named variables
comprising a single int value, of which there will be a small number in
any function.

Values inside arrays and structs, as I've mentioned a few times, are
storage types where you can choose the most suitable and most efficient
width.

Someone needing to store a billion values of 0 to 10000, and carelessly
uses a dynamic array of int which is 64 bits, will be wasting 6GB. But
some using an int of 32 bits will still be wasting 2GB.

In either case the element type needs to carefully chosen.

Bart <bc@freeuk.com> writes:
> 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/.

No, C does not do so. Many C implementations do. C only requires int
to be at least 16 bits.

When common systems transitioned from 16 to 32 bits, the size of int
was, on most implementations, increased from 16 to 32 bits. The same
didn't happen with the 32-to-64 transition.

One reason for that may have been that there was more software that
non-portably assumed a certain size, simply because there was more
software in general.

Another, and I suspect the main one, is that making int 64 bits means
that you can't cover all reasonable sizes with predefined integer types.
An implementation might have 8-bit char, 16-bit short, 32-bit int, and
64-bit long. Making int 64 bits means that you have to give up either
16 or 32 bits. (And it was always assumed that some integer types,
perhaps short and int or int and long, might have the same size; that
was the case for all 4 systems described in K&R1.)

Extended integer types, introduced in C99, *could* have addressed that,
but few if any implementations support them. (Adding something like
"long short" might also have addressed it, but that's a bit ugly.)

[...]

--
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 */

David Brown <david.brown@hesbynett.no> writes:
> On 19/05/2021 18:06, Keith Thompson wrote:
>> Padding *bits* are bits within the representation of an integer type
>> that do not contribute to its value. The concept was first explicitly
>> acknowledged in C99. Note that the requirements on the predefined
>> integer types are defines in terms of lower and upper bounds, not sizes.
>>
>> Most implementations don't use padding bits. They can be necessary if
>> integer types are implemented on top of floating-point, or if the
>> hardware only supports signed integer arithmetic and unsigned types
>> can't use the sign bit as a value bit.
>
> Do you know of any systems that have or had padding bits in their
> integer types?

I do not. I've heard of some old systems that implemented integers as
floating-point with a zero exponent, or unsigned integers as signed
integers with the sign bit fixed to 0, but there may not be any
modernish C implementations for such hardware.

I wouldn't be surprised if some DSP implementations had padding bits,
though.

--
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 */

Bart <bc@freeuk.com> writes:
>On 19/05/2021 18:30, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> And here, also, the most used locals will likely reside in registers not
>>> memory.
>>
>> By far, the most prevelent data in a real program will be allocated
>> off the heap (e.g. structs), but for every four 64-bit locals you
>> need a cache line, where you can fit eight 32-bit locals in the same line.
>
>But I'm talking about individual variables, that is named variables
>comprising a single int value, of which there will be a small number in
>any function.

Most functions in my experience aren't limited to stack local
data, and thus neither is their cache footprint dependent upon
local declarations.

David Brown <david.brown@hesbynett.no> writes:
>On 19/05/2021 17:52, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:

>> Not in my experience - they've all been in network processing
>> appliances (switches, gateways, firewalls) where big-endian rules,
>> for example, consider the Octeon processors.
>>
>
>Yes, for networking appliances big-endian is convenient. These are
>perhaps the last bastion of MIPS, but they are getting pushed out by ARM.
>
>(I think this is a shame - MIPS is a perfectly good ISA, and
>alternatives mean more competition. It's as unhealthy with ARM
>dominance in embedded systems as it is with x86 dominance in desktops
>and servers. I'd have like to see more MIPS cores in the
>microcontroller world. Perhaps RISC-V will grow competitively.)

Indeed. Octeon switched to ARMv8 a few years ago. ARM has a nice
Technical Advisory Board made up of their customers and other interested
entities (the OS vendors, primarily) who help shape the
ARMv8 architecture.

However, with the pending acquisition of ARM by Nvidia, you can expect to
see RISC-V gain in traction and eventually market share.

Until the next new idea comes along.

>>
>> As noted, ARMv7 has a user-level instruction to change the endianness
>> on the fly.
>>
>
>Yes. But on many implementations (I use mainly microcontrollers, where
>core size is important - I gather you have more experience with bigger
>devices) the instruction doesn't work because the big-endian support is
>not there. PowerPC microcontrollers similarly lack support for
>little-endian modes even though the control register bits still exist.

Well, to be fair, I only know about SETEND because I had to implement
it in a ARM simulator. I expect most people, even at the ARM-M scale,
will be working with ARMv8 mostly going forward and from what I see,
most of the network appliance folks are switching to little-endian
when they switch to ARM.

On 19/05/2021 19:23, Bart wrote:
> On 19/05/2021 16:31, David Brown wrote:
>> On 19/05/2021 16:46, Bart wrote:
>
>
>>> The benefits [of 64-bit int] 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.
>>>
>>
>> As is often the case, a "no-brainer" means you are not using your brain.
>>
>> I would have no objection to "int" being 64-bit on 64-bit systems.  But
>> IMHO it is very poor programming style to use "int" instead of types
>> such as size_t and intptr_t simply because the sizes are the same.
>
> Think about why those extra types were needed. It's because address
> ranges were often greater than provided by the local int type.
>

On most C implementations, they are the same size.

Different types were used in C primarily so that code was not restricted
to implementations where that was the case.

But that is the historic reason. Modern language design and modern
coding practices tend towards using different types for different
purposes, even if the underlying concrete types and object code are the
same. These are good types to use because they are dealing with
different things - in a modern language that does not have the backwards
compatibility baggage of C, you would not only have different types but
have them incompatible types.

The idea of dropping these types and making everything an "int" is very
much a backwards view.

> With 64-bit ints, that's much less likely to be the case.
>
>
>> Programmers mostly left such typeless "everything is int" style behind
>> 50 years ago when they moved from BCPL to C.
>
> A size /is/ just a number, like innumerable other quantities in a
> program. It's hardly as though C gives much type protection.
>
>> Named types are not just for portability (which you are throwing out the
>> window here), but also for clarity in the code.
>
> Many languages are dynamically typed without explicit types at all, nor
> lots of little int types for different purposes.
>
> Usually such languages are considered clearer.

A single type for general numbers is fine. That does not mean treating
/everything/ as a number. In particular, treating an address as a
number without even the courtesy (to the reader) of having a specific
named type is bad coding (IMHO). Most modern languages make that sort
of thing quite difficult to do.

On 19/05/2021 20:40, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> 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/.
>
> No, C does not do so. Many C implementations do. C only requires int
> to be at least 16 bits.
>
> When common systems transitioned from 16 to 32 bits, the size of int
> was, on most implementations, increased from 16 to 32 bits. The same
> didn't happen with the 32-to-64 transition.
>
> One reason for that may have been that there was more software that
> non-portably assumed a certain size, simply because there was more
> software in general.
>
> Another, and I suspect the main one, is that making int 64 bits means
> that you can't cover all reasonable sizes with predefined integer types.
> An implementation might have 8-bit char, 16-bit short, 32-bit int, and
> 64-bit long. Making int 64 bits means that you have to give up either
> 16 or 32 bits. (And it was always assumed that some integer types,
> perhaps short and int or int and long, might have the same size; that
> was the case for all 4 systems described in K&R1.)
>
> Extended integer types, introduced in C99, *could* have addressed that,
> but few if any implementations support them. (Adding something like
> "long short" might also have addressed it, but that's a bit ugly.)
>
> [...]
>

There is always the "Standardizing Extended Integers" proposal for C:

<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0989r0.pdf>

:-)

On 19/05/2021 20:45, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 19/05/2021 18:06, Keith Thompson wrote:
>>> Padding *bits* are bits within the representation of an integer type
>>> that do not contribute to its value. The concept was first explicitly
>>> acknowledged in C99. Note that the requirements on the predefined
>>> integer types are defines in terms of lower and upper bounds, not sizes.
>>>
>>> Most implementations don't use padding bits. They can be necessary if
>>> integer types are implemented on top of floating-point, or if the
>>> hardware only supports signed integer arithmetic and unsigned types
>>> can't use the sign bit as a value bit.
>>
>> Do you know of any systems that have or had padding bits in their
>> integer types?
>
> I do not. I've heard of some old systems that implemented integers as
> floating-point with a zero exponent, or unsigned integers as signed
> integers with the sign bit fixed to 0, but there may not be any
> modernish C implementations for such hardware.
>

The ZX Spectrum did something like that for its BASIC interpreter. (It
was not in hardware - the cpu was an 8-bit Z80A, for those that remember
them.) I did have a C compiler for it, but I can't remember the details
- I was a teenager at the time.

> I wouldn't be surprised if some DSP implementations had padding bits,
> though.
>

I haven't heard of any. I know of a few DSP's with odd integer types,
such as 18-bit char. And some have registers of unusual sizes, such as
mainly 32-bit registers but a 40-bit "accumulator" for
multiply-accumulate instructions.

I suppose one possibility is the MSP430x microcontroller, which is an
extended version of the 16-bit MSP430. It has 20-bit registers for
addressing a larger memory than the 64 KB address space. When loading
and storing these, they take the space of a 32-bit type - so maybe these
count as having padding bits.

On 19/05/2021 20:04, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 19/05/2021 18:30, Scott Lurndal wrote:
>>> Bart <bc@freeuk.com> writes:
>>
>>>> And here, also, the most used locals will likely reside in registers not
>>>> memory.
>>>
>>> By far, the most prevelent data in a real program will be allocated
>>> off the heap (e.g. structs), but for every four 64-bit locals you
>>> need a cache line, where you can fit eight 32-bit locals in the same line.
>>
>> But I'm talking about individual variables, that is named variables
>> comprising a single int value, of which there will be a small number in
>> any function.
>
> Most functions in my experience aren't limited to stack local
> data, and thus neither is their cache footprint dependent upon
> local declarations.
>

This is my point. Whether those are int32 or int64 is not relevant on
64-bit machines.

Bart <bc@freeuk.com> writes:
>On 19/05/2021 20:04, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 19/05/2021 18:30, Scott Lurndal wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>
>>>>> And here, also, the most used locals will likely reside in registers not
>>>>> memory.
>>>>
>>>> By far, the most prevelent data in a real program will be allocated
>>>> off the heap (e.g. structs), but for every four 64-bit locals you
>>>> need a cache line, where you can fit eight 32-bit locals in the same line.
>>>
>>> But I'm talking about individual variables, that is named variables
>>> comprising a single int value, of which there will be a small number in
>>> any function.
>>
>> Most functions in my experience aren't limited to stack local
>> data, and thus neither is their cache footprint dependent upon
>> local declarations.
>>
>
>This is my point. Whether those are int32 or int64 is not relevant on
>64-bit machines.'

How do you come to that conclusion? Their cache footprint is not dependent
upon the locals _alone_ because there is other data accessed from the function that
affects the cache footprint _more_. However, the locals still affect
the cache footprint, potentially significantly.

On 19/05/2021 20:27, David Brown wrote:
> On 19/05/2021 19:23, Bart wrote:

>> Think about why those extra types were needed. It's because address
>> ranges were often greater than provided by the local int type.
>>
>
> On most C implementations, they are the same size.

On current 64-bit systems, they are different sizes. int is 32 bits;
size_t and intptr_t are 64 bits.

> Different types were used in C primarily so that code was not restricted
> to implementations where that was the case.
>
> But that is the historic reason. Modern language design and modern
> coding practices tend towards using different types for different
> purposes, even if the underlying concrete types and object code are the
> same. These are good types to use because they are dealing with
> different things - in a modern language that does not have the backwards
> compatibility baggage of C, you would not only have different types but
> have them incompatible types.
>
> The idea of dropping these types and making everything an "int" is very
> much a backwards view.

Having a single /default/ integer type that is big enough to represent
most things, and do it efficiently (using one word not two), would be a
welcome simplificatiion I would have thought.

And it would remove that discontinuity between 32 bits and 64 bits.

>> Many languages are dynamically typed without explicit types at all, nor
>> lots of little int types for different purposes.
>>
>> Usually such languages are considered clearer.
>
> A single type for general numbers is fine. That does not mean treating
> /everything/ as a number. In particular, treating an address as a
> number without even the courtesy (to the reader) of having a specific
> named type is bad coding (IMHO).

Who's doing that? An address should be stored in a pointer. If you
explicitly convert it to an int, then it /is/ a int.

David Brown <david.brown@hesbynett.no> writes:
[...]
> I haven't heard of any. I know of a few DSP's with odd integer types,
> such as 18-bit char. And some have registers of unusual sizes, such as
> mainly 32-bit registers but a 40-bit "accumulator" for
> multiply-accumulate instructions.

The R.O.U.S.'s? I don't think they exist. 8-)}

[...]

--
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 19/05/2021 21:12, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 19/05/2021 20:04, Scott Lurndal wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 19/05/2021 18:30, Scott Lurndal wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>>> And here, also, the most used locals will likely reside in registers not
>>>>>> memory.
>>>>>
>>>>> By far, the most prevelent data in a real program will be allocated
>>>>> off the heap (e.g. structs), but for every four 64-bit locals you
>>>>> need a cache line, where you can fit eight 32-bit locals in the same line.
>>>>
>>>> But I'm talking about individual variables, that is named variables
>>>> comprising a single int value, of which there will be a small number in
>>>> any function.
>>>
>>> Most functions in my experience aren't limited to stack local
>>> data, and thus neither is their cache footprint dependent upon
>>> local declarations.
>>>
>>
>> This is my point. Whether those are int32 or int64 is not relevant on
>> 64-bit machines.'
>
> How do you come to that conclusion? Their cache footprint is not dependent
> upon the locals _alone_ because there is other data accessed from the function that
> affects the cache footprint _more_. However, the locals still affect
> the cache footprint, potentially significantly.
>

I'm slightly losing track of whether you are arguing for against using
64-bit integers.

I'm saying there is little impact from using such types as local
variables, when a 32-bit version would have done as well.

This makes it practical to use it as a /default/ integer type, and only
use an explicitly narrower type where needed (with all the benefits, and
more, that I listed).

Do you have an example of a function where it makes a measureable
difference?

On 19/05/2021 22:29, Bart wrote:
> On 19/05/2021 20:27, David Brown wrote:
>> On 19/05/2021 19:23, Bart wrote:
>
>>> Think about why those extra types were needed. It's because address
>>> ranges were often greater than provided by the local int type.
>>>
>>
>> On most C implementations, they are the same size.
>
> On current 64-bit systems, they are different sizes. int is 32 bits;
> size_t and intptr_t are 64 bits.
>

64-bit systems are a tiny minority of C implementations. An important
minority, but still a minority.

>> Different types were used in C primarily so that code was not restricted
>> to implementations where that was the case.
>>
>> But that is the historic reason.  Modern language design and modern
>> coding practices tend towards using different types for different
>> purposes, even if the underlying concrete types and object code are the
>> same.  These are good types to use because they are dealing with
>> different things - in a modern language that does not have the backwards
>> compatibility baggage of C, you would not only have different types but
>> have them incompatible types.
>>
>> The idea of dropping these types and making everything an "int" is very
>> much a backwards view.
>
> Having a single /default/ integer type that is big enough to represent
> most things, and do it efficiently (using one word not two), would be a
> welcome simplificatiion I would have thought.
>

Over-simplifying is not helpful. (I realise there are different
opinions as to what is simple or not - I want more types, not less, and
would prefer more distinctions between them.)

> And it would remove that discontinuity between 32 bits and 64 bits.
>
>
>>> Many languages are dynamically typed without explicit types at all, nor
>>> lots of little int types for different purposes.
>>>
>>> Usually such languages are considered clearer.
>>
>> A single type for general numbers is fine.  That does not mean treating
>> /everything/ as a number.  In particular, treating an address as a
>> number without even the courtesy (to the reader) of having a specific
>> named type is bad coding (IMHO).
>
> Who's doing that? An address should be stored in a pointer. If you
> explicitly convert it to an int, then it /is/ a int.
>

Turning an address into a number does not mean you want to do the same
kinds of operations on it as you do on a general number. Giving a clear
name to the type makes it easier to see what you are doing, and what you
should not be doing. (Of course, it helps when you don't have a coding
style from a previous century where information about a variable's type
is in a completely different part of the function than where you use the
variable.) Even better is if such types are restricted in what you can
do with them.