David Brown <david.brown@hesbynett.no> writes:
>On 20/02/2024 13:00, Anton Ertl wrote:
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>> mitchalsup@aol.com (MitchAlsup1) writes:
>>>> We are in an era where long has higher performance than ints (except for
>>>> cache footprint overheads.)
>>>
>>> C has been in that era since the bad I32LP64 decision of the people
>>> who did the first 64-bit Unix compilers in the early 1990s.
>
>I presume the main reason for this was the size and cost of memory at
>the time? Or do you know any other reason? Maybe some of the early
>64-bit cpus were faster at 32-bit, just as some early 32-bit cpus were
>faster at 16-bit.

I know no implementation of a 64-bit architecture where ALU operations
(except maybe division where present) is slower in 64 bits than in 32
bits. I would have chosen ILP64 at the time, so I can only guess at
their reasons:

Guess 1: There was more software that depended on sizeof(int)==4 than
software that depended on sizeof(int)==sizeof(char *).

Guess 2: When benchmarketing without adapting the source code (as is
usual), I32LP64 produced better numbers then ILP64 for some
benchmarks, because arrays and other data structures with int elements
are smaller and have better cache hit rates.

My guess is that it was a mixture of 1 and 2, with 2 being the
decisive factor. I have certainly seen a lot of writing about how
64-bit (pointers) hurt performance, and it even led to the x32
nonsense (which never went anywhere, not surprising to me). These
days support for 32-bit applications is eliminated from ARM cores,
another indication that the performance advantages of 32-bit pointers
are minor.

>> BTW, some people here have advocated the use of unsigned instead of
>> int. Which of the two results in better code depends on the
>> architecture. On AMD64 where the so-called 32-bit instructions
>> perform a 32->64-bit zero-extension, unsigned is better. On RV64G
>> where the so-called 32-bit instructions perform a 32->64-bit sign
>> extension, signed int is better. But actually the best way is to use
>> a full-width type like intptr_t or uintptr_t, which gives better
>> results than either.
>
>I would suggest C "fast" types like int_fast32_t (or other "fast" sizes,
>picked to fit the range you need).

Sure, and then the program might break when an array has more the 2^31
elements; or it might work on one platform and break on another one.

By contrast, with (u)intptr_t, on modern architectures you use the
type that's as wide as the GPRs. And I don't see a reason why to use
something else for a loop counter.

For a type of which you store many in an array or other data
structure, you probably prefer int32_t rather than int_fast32_t if 32
bits is enough. So I don't see a reason for int_fast32_t etc.

These adapt suitably for different
>targets. If you want to force the issue, then "int64_t" is IMHO clearer
>than "long long int" and does not give a strange impression where you
>are using a type aimed at pointer arithmetic for general integer arithmetic.

Why do you bring up "long long int"? As for int64_t, that tends to be
slow (if supported at all) on 32-bit platforms, and it is more than
what is necessary for indexing arrays and for loop counters that are
used for indexing into arrays.

>If you want fast local variables, use C's [u]int_fastN_t types. That's
>what they are for.

I don't see a point in those types. What's wrong with (u)intptr_t IYO?

> Don't use "-fwrapv" unless you actually need it - in most
>code, if your arithmetic overflows, you have a mistake in your code, so
>letting the compiler assume that will not happen is a good thing.

Thank you for giving a demonstration for Scott Lurndal. I assume that
you claim to be a programmer.

Anyway, if I have made a mistake in my code, why would let the
compiler assume that I did not make a mistake be a good thing?

I OTOH prefer if the compiler behaves consistently, so I use -fwrapv,
and for good performance, I write the code appropriately (e.g., by
using intptr_t instead of int).

>(And
>it lets you check for overflow bugs using run-time sanitizers.)

If the compiler assumes that overflow does not happen, how do these
"sanitizers" work?

Anyway, I certainly have code that relies on modulo arithmetic.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

scott@slp53.sl.home (Scott Lurndal) writes:
>Or maybe changing int from 32-bit to 64-bit would have caused
>as many (or likely more) problems as changing from 16-bit to 32-bit did back in the
>day.

In Unix sizeof(int) == sizeof(int *) on both 16-bit and 32-bit
architectures. Given the history of C, that's not surprising: BCPL
and B have a single type, the machine word, and it eventually became
C's int. You see this in "int" declarations being optional in various
places. So code portable between 16-bit and 32-bit systems could not
assume that int has a specific size (such as 32 bits), but if it
assumed that sizeof(int) == sizeof(int *), that would port fine
between 16-bit and 32-bit Unixes. There may have been C code that
assumed that sizeof(int)==4, but why cater to this kind of code which
did not even port to 16-bit systems?

In any case, I32LP64 caused breakage for my code, and I expect that
there was more code around with the assumption sizeof(int)==sizeof(int
*) than with the assumption sizeof(int)==4. Of course, we worked
around this misfeature of the C compilers on Digital OSF/1, but those
who assumed sizeof(int)==4 would have adapted their code if the
decision had been for ILP64.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

David Brown <david.brown@hesbynett.no> writes:
>On 20/02/2024 16:17, Terje Mathisen wrote:
>> x86 has had an 'O' (Overflow) flags bit since the very beginning, along
>> with JO and JNO for Jump on Overflow and Jump if Not Overflow.
>>
>
>Many processors had something similar. But I think they fell out of
>fashion for 64-bit RISC,

No, it didn't. All the RISCs that had flags registers for their
32-bit architectures still have it for their 64-bit architectures.

>as flag registers are a bottleneck for OOO and
>superscaling

No, it isn't, as demonstrated by the fact that architectures with
flags registers (AMD64, ARM A64) handily outperform architectures
without (but probably not because they have a flags register).
Implementing a flags register in an OoO microarchitecture does require
execution resources, however.

>overflow is a lot less common for 64-bit arithmetic, and
>people were not really using the flag except for implementation of
>64-bit arithmetic.

That's nonsense. People use carry for implementing multi-precision
arithmetic (e.g., for cryptography) and for Bignums, and they use
overflow for implementing Bignums. And the significance of these
features has increased over time.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>>Or maybe changing int from 32-bit to 64-bit would have caused
>>as many (or likely more) problems as changing from 16-bit to 32-bit did back in the
>>day.
>
>In Unix sizeof(int) == sizeof(int *) on both 16-bit and 32-bit
>architectures. Given the history of C, that's not surprising: BCPL
>and B have a single type, the machine word, and it eventually became
>C's int. You see this in "int" declarations being optional in various
>places. So code portable between 16-bit and 32-bit systems could not
>assume that int has a specific size (such as 32 bits), but if it
>assumed that sizeof(int) == sizeof(int *), that would port fine
>between 16-bit and 32-bit Unixes. There may have been C code that
>assumed that sizeof(int)==4, but why cater to this kind of code which
>did not even port to 16-bit systems?

Most of the problems encountered when moving unix (System V)
from 16-bit to 32-bit were more around missing typedefs for certain
data types (e.g. uids, gids, pids, etc), so there was
a lot of code that declared these as shorts, but the 32-bit
kernels defined these as 32-bit (unsigned) values).

That's when uid_t, pid_t, gid_t were added.

Then there were the folks who used 'short [int]' instead of 'int'
since they were the same size on the PDP-11.

The Unix code ported relatively easily to I32LP64 because uintptr_t
had been used extensively rather than assumptions about
sizeof(int) == sizeof(int *).

On 2/20/24 10:25, David Brown wrote:
> On 20/02/2024 13:00, Anton Ertl wrote:
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>> mitchalsup@aol.com (MitchAlsup1) writes:
>>>> We are in an era where long has higher performance than ints (except for
>>>> cache footprint overheads.)
>>>
>>> C has been in that era since the bad I32LP64 decision of the people
>>> who did the first 64-bit Unix compilers in the early 1990s.
>
> I presume the main reason for this was the size and cost of memory at the
> time?  Or do you know any other reason?  Maybe some of the early 64-bit cpus
> were faster at 32-bit, just as some early 32-bit cpus were faster at 16-bit.
>
>>> We have
>>> been paying with additional sign-extension and zero-extension
>>> operations ever since then, and it has even deformed architectures:
>>> ARM A64 has addressing modes that include sign- or zero-extending a
>>> 32-bit index, and RISC-V's selected SLLI, SRLI, SRAI for their
>>> compressed extension, probably because they are so frequent because
>>> they are used in RISC-V's idioms for sign and zero extension.
>>
>> Also, these architectures probably would not have the so-called 32-bit
>> arithmetic instructions (like RV64G's addw) if the mainstream C world
>> had decided to use ILP64.  RV64G could have left these instructions
>> away and replaced them with a sequence of add, slli, srli, i.e., a
>> 64-bit addition followed by a sign-extension idiom.  After all, RISC-V
>> seems to favour sequences of more general instructions over having
>> more specialized instructions (and addressing modes).  But apparently
>> the frequency of 32-bit additions is so high thanks to I32LP64 that
>> they added addw and addiw to RV64G; and they even occupy space in the
>> compressed extension (16-bit encodings of frequent instructions).
>>
>> BTW, some people here have advocated the use of unsigned instead of
>> int.  Which of the two results in better code depends on the
>> architecture.  On AMD64 where the so-called 32-bit instructions
>> perform a 32->64-bit zero-extension, unsigned is better.  On RV64G
>> where the so-called 32-bit instructions perform a 32->64-bit sign
>> extension, signed int is better.  But actually the best way is to use
>> a full-width type like intptr_t or uintptr_t, which gives better
>> results than either.
>
> I would suggest C "fast" types like int_fast32_t (or other "fast" sizes, picked
> to fit the range you need).  These adapt suitably for different targets.  If
> you want to force the issue, then "int64_t" is IMHO clearer than "long long
> int" and does not give a strange impression where you are using a type aimed at
> pointer arithmetic for general integer arithmetic.
>
What I would like is a compiler flag that did "IFF when an int (or unsigned)
ends up in a register, promote it to the 'fast' type". This would be great
when compiling dusty C decks. (Was there ever C code on punched cards?)

On 2/20/2024 10:25 AM, David Brown wrote:
> On 20/02/2024 13:00, Anton Ertl wrote:
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>> mitchalsup@aol.com (MitchAlsup1) writes:
>>>> We are in an era where long has higher performance than ints (except
>>>> for
>>>> cache footprint overheads.)
>>>
>>> C has been in that era since the bad I32LP64 decision of the people
>>> who did the first 64-bit Unix compilers in the early 1990s.
>
> I presume the main reason for this was the size and cost of memory at
> the time?  Or do you know any other reason?  Maybe some of the early
> 64-bit cpus were faster at 32-bit, just as some early 32-bit cpus were
> faster at 16-bit.
>

I never really questioned it, but then again, when I was starting out,
everything was ILP32, and going to I32LP64 made the most sense.

MSVC went from ILP32 to IL32P64, which was wonky. But, then again, some
amount of originally 16-bit code had used 'long' whenever they wanted a
32-bit value; seemingly more often than expecting 'long' to be the same
size as a pointer (the other common assumption).

>>> We have
>>> been paying with additional sign-extension and zero-extension
>>> operations ever since then, and it has even deformed architectures:
>>> ARM A64 has addressing modes that include sign- or zero-extending a
>>> 32-bit index, and RISC-V's selected SLLI, SRLI, SRAI for their
>>> compressed extension, probably because they are so frequent because
>>> they are used in RISC-V's idioms for sign and zero extension.
>>
>> Also, these architectures probably would not have the so-called 32-bit
>> arithmetic instructions (like RV64G's addw) if the mainstream C world
>> had decided to use ILP64.  RV64G could have left these instructions
>> away and replaced them with a sequence of add, slli, srli, i.e., a
>> 64-bit addition followed by a sign-extension idiom.  After all, RISC-V
>> seems to favour sequences of more general instructions over having
>> more specialized instructions (and addressing modes).  But apparently
>> the frequency of 32-bit additions is so high thanks to I32LP64 that
>> they added addw and addiw to RV64G; and they even occupy space in the
>> compressed extension (16-bit encodings of frequent instructions).
>>

In my case, I had dedicated instructions for sign and zero extension of
the various types.

But, yeah, like RISC-V, there are both 32 and 64 bit variants of many
instructions, mostly because some amount of code will break if an
overflow happens, and does not behave as it would on an authentic 32-bit
machine (IOW: wrap on overflow).

Though, some of this reminds me:
Another instruction SuperH had that was not carried over:
ADDV
Which would do an ADD and update SR.T based on Overflow.

But, this scenario was rare, and one could usually detect overflow like:
if(b>=0)
{
c=a+b;
if(c<a) { ...overflow... }
}else
{
c=a+b;
if(c>a) { ...overflow... }
}

Meanwhile, cases where one would need an instruction like ADDV would not
happen in C compiler output.

For detecting 32-bit overflow, in premise one could also do something like:
ADD R4, R5, R3
EXTS.L R3, R2
CMPQEQ R3, R2
BF .overflow

Or, with JCMP extension (*1):
ADD R4, R5, R3
EXTS.L R3, R2
BRNE R3, R2, .overflow

Or, RV:
ADD A6, A0, A1
ADDW A7, A6, 0
BNE A6, A7, .overflow

*1: Seems I actually need this to more consistently match/beat RV
performance (unlike my prior estimates that this case was mostly
unnecessary and that 2-op sequences were sufficient).

But, more work is still needed.
And, it seemed, a recent ISA tweak to improve performance (by making the
immediate for AND signed) had unintentionally broke compiler output in
the Baseline+XGPR mode, as when writing the code, I had overlooked that
this case was N/E in XGPR mode (or, that is was effectively another "XG2
Only" feature).

Then had to do a last minute update to my GitHub project, as I had noted
that I had uploaded stuff with BGBCC producing broken output, which is
not ideal (and then hope that none of the other stuff I was working on
right at the moment breaks anything; as I had otherwise been recently
working a bit in trying to squeeze more performance out of BGBCC's
compiler output).

Well, since "barely faster than RISC-V in some cases" (or, potentially
losing in some other cases) isn't really a strong enough win as I see it...

But, seems the margins are close enough that things like missing out on
12-15% of AND immediate values being negative, cycles spent in relative
comparisons for branches, etc..., are enough to visibly effect results.

....

>> BTW, some people here have advocated the use of unsigned instead of
>> int.  Which of the two results in better code depends on the
>> architecture.  On AMD64 where the so-called 32-bit instructions
>> perform a 32->64-bit zero-extension, unsigned is better.  On RV64G
>> where the so-called 32-bit instructions perform a 32->64-bit sign
>> extension, signed int is better.  But actually the best way is to use
>> a full-width type like intptr_t or uintptr_t, which gives better
>> results than either.
>
> I would suggest C "fast" types like int_fast32_t (or other "fast" sizes,
> picked to fit the range you need).  These adapt suitably for different
> targets.  If you want to force the issue, then "int64_t" is IMHO clearer
> than "long long int" and does not give a strange impression where you
> are using a type aimed at pointer arithmetic for general integer
> arithmetic.
>

A lot of my code was written mostly in an alternate timeline where
"stdint.h" was mostly absent for a long time (cough, MSVC); so a
convention arose of using names like "s64" or "u64" instead for the
64-bit types (well, with similar for most of the other explicit sizes,
and other typedef's for things like trying to match the size of a
pointer, ...).

Where, say, C99 didn't really make its way over to the Windows side of
things until well over a decade after the fact (early on, I was using
Cygwin, which had gotten stuck with old version of GCC for a fairly long
time).

Though, at least for things like the C and runtime libraries, arguably
it would make more sense to move over to C99 conventions.

Then again, even now, it is sometimes difficult to not be at least a
little weirded out by things like putting declarations anywhere other
than at the top of a function.

>
>>  E.g., consider the function
>>
>> void sext(int M, int *ic, int *is)
>> {
>>    int k;
>>    for (k = 1; k <= M; k++) {
>>      ic[k] += is[k];
>>    }
>> }
>>
>> which is based on the only loop (from 456.hmmer) in SPECint 2006 where
>> the difference between -fwrapv and the default produces a measurable
>> performance difference (as reported in section 3.3 of
>> <https://people.eecs.berkeley.edu/~akcheung/papers/apsys12.pdf>).  I
>> created variations of this function, where the types of M and k were
>> changed to b) unsigned, c) intptr_t, d) uintptr_t and compiled the
>> code with "gcc -Wall -fwrapv -O3 -c -fno-unroll-loops".  The loop body
>> looks as follows on RV64GC:
>>
>>     int                   unsigned             (u)intptr_t
>> .L3:                  .L8:                   .L15:
>> slli  a5,a4,0x2       slli  a5,a4,0x20       lw    a5,0(a1)
>> add   a6,a1,a5        srli  a5,a5,0x1e       lw    a4,4(a2)
>> add   a5,a5,a2        add   a6,a1,a5         addi  a1,a1,4
>> lw    a3,0(a6)        add   a5,a5,a2         addi  a2,a2,4
>> lw    a5,0(a5)        lw    a3,0(a6)         addw  a5,a5,a4
>> addiw a4,a4,1         lw    a5,0(a5)         sw    a5,-4(a1)
>> addw  a5,a5,a3        addiw a4,a4,1          bne   a2,a3,54 <.L15>
>> sw    a5,0(a6)        addw  a5,a5,a3
>> bge   a0,a4,6 <.L3>   sw    a5,0(a6)
>>                        bgeu  a0,a4,28 <.L8>
>>
>> There is no difference between the intptr_t loop body and the
>> uintptr_t loop.  And without -fwrapv, the int loop looks just like the
>> (u)intptr_t loop (because the C compiler then assumes that signed
>> integer overflow does not happen).
>>
>> So, if you don't have a specific reason to choode int or unsigned,
>> better use intptr_t or uintptr_t, respectively.  In this way you can
>> circumvent some of the damage that I32LP64 has done.
>>
>
> I would say the takeaways here are :
>
> If you want fast local variables, use C's [u]int_fastN_t types.  That's
> what they are for.
>
> Don't use unsigned types for counters and indexes unless you actually
> need them.  Don't use "-fwrapv" unless you actually need it - in most
> code, if your arithmetic overflows, you have a mistake in your code, so
> letting the compiler assume that will not happen is a good thing.  (And
> it lets you check for overflow bugs using run-time sanitizers.)
>

Anton Ertl wrote:

> David Brown <david.brown@hesbynett.no> writes:
>>On 20/02/2024 16:17, Terje Mathisen wrote:
>>> x86 has had an 'O' (Overflow) flags bit since the very beginning, along
>>> with JO and JNO for Jump on Overflow and Jump if Not Overflow.
>>>
>>
>>Many processors had something similar. But I think they fell out of
>>fashion for 64-bit RISC,

> No, it didn't. All the RISCs that had flags registers for their
> 32-bit architectures still have it for their 64-bit architectures.

>>as flag registers are a bottleneck for OOO and
>>superscaling

> No, it isn't, as demonstrated by the fact that architectures with
> flags registers (AMD64, ARM A64) handily outperform architectures
> without (but probably not because they have a flags register).
> Implementing a flags register in an OoO microarchitecture does require
> execution resources, however.

These implementations have several 200 man design teams and decades
of architectural and µArchitectural understanding that upstart
RISC designs cannot afford (until they <also> reach 100M chips sold
per year--where you reach the required amount of cubic dollars).

The fact that some designs with flags can perform at the top or near
the top is only indicative that flags are "not that much" of an
impediment to performance at the scale of current µprocessors
(3-4 wide)

>>overflow is a lot less common for 64-bit arithmetic, and
>>people were not really using the flag except for implementation of
>>64-bit arithmetic.

> That's nonsense. People use carry for implementing multi-precision
> arithmetic (e.g., for cryptography) and for Bignums, and they use
> overflow for implementing Bignums. And the significance of these
> features has increased over time.

You can implement BigNums efficiently without a RAW serializing
carry bit in some control register (see My 66000 CARRY instruction-
modifier).

> - anton

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>>Architectures of old _expected_ integer overflows and had
>>mechanisms in the languages to test for them.
>
>IIRC S/360 has two modes of operation: One where, on signed addition,
>overflow traps, and one where it sets some flag; and the flag-setting
>is not as consistent as say the NZCV flags on modern architectures;
>instead, there are two bits that can mean anything at all, depending
>on the instruction that sets them. In any case, if you use a program
>that checks for overflows, then you either have to change the mode to
>non-trapping before the addition and change it back afterwards, or all
>signed overflows that are not checked explicitly are ignored.

Not quite. It had regular add and subtract (A, AR, S, SR) and logical
(AL, ALR, SL, SLR). The former set the condition code as
negative,zero,positive, or overflow, and interrupted if the overflow
interrupt was enabled. The latter set the condition code as zero no
carry, nonzero no carry, zero carry, or nonzero carry, and never
overflowed. There weren't instructions to do add or subtract with
carry but it was pretty easy to fake by doing a branch on no carry
around an instruction to add or subtract 1.

Multiplication was always signed and took two single length operands
and produced a double length product. It couldn't overflow but you
could with some pain check to see if the high word of the product had
any significant bits.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Anton Ertl wrote:

> David Brown <david.brown@hesbynett.no> writes:
>>On 20/02/2024 13:00, Anton Ertl wrote:
>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>> mitchalsup@aol.com (MitchAlsup1) writes:
>>>>> We are in an era where long has higher performance than ints (except for
>>>>> cache footprint overheads.)
>>>>
>>>> C has been in that era since the bad I32LP64 decision of the people
>>>> who did the first 64-bit Unix compilers in the early 1990s.
>>
>>I presume the main reason for this was the size and cost of memory at
>>the time? Or do you know any other reason? Maybe some of the early
>>64-bit cpus were faster at 32-bit, just as some early 32-bit cpus were
>>faster at 16-bit.

> I know no implementation of a 64-bit architecture where ALU operations
> (except maybe division where present) is slower in 64 bits than in 32
> bits. I would have chosen ILP64 at the time, so I can only guess at
> their reasons:

The ALU operations were slower because when you IADD x and y to give z
if you then want z to have no significance above 32-bits you require
a second instruction to smash the value back into the container range.
So 1 ALU in 64-bits takes 1 instruction while 1 ALU requiring 32-bits
requires 2. This is the reason RISC-V has 32-bit ALU instructions.

> Guess 1: There was more software that depended on sizeof(int)==4 than
> software that depended on sizeof(int)==sizeof(char *).

There remains a lot of SW that is dependent on INT being smaller than LONG.

> Guess 2: When benchmarketing without adapting the source code (as is
> usual), I32LP64 produced better numbers then ILP64 for some
> benchmarks, because arrays and other data structures with int elements
> are smaller and have better cache hit rates.

Some truth in here.

> My guess is that it was a mixture of 1 and 2, with 2 being the
> decisive factor. I have certainly seen a lot of writing about how
> 64-bit (pointers) hurt performance, and it even led to the x32
> nonsense (which never went anywhere, not surprising to me). These
> days support for 32-bit applications is eliminated from ARM cores,
> another indication that the performance advantages of 32-bit pointers
> are minor.

Try programming array codes where the arrays are TB in size with P32.

My ONLY argument is that int was SUPPOSED to be the fastest arithmetic.
It was in PDP-11 days and VAX days, but it is no longer.

>>> BTW, some people here have advocated the use of unsigned instead of
>>> int. Which of the two results in better code depends on the
>>> architecture. On AMD64 where the so-called 32-bit instructions
>>> perform a 32->64-bit zero-extension, unsigned is better. On RV64G
>>> where the so-called 32-bit instructions perform a 32->64-bit sign
>>> extension, signed int is better. But actually the best way is to use
>>> a full-width type like intptr_t or uintptr_t, which gives better
>>> results than either.
>>
>>I would suggest C "fast" types like int_fast32_t (or other "fast" sizes,
>>picked to fit the range you need).

The semantics of unsigned are better when you are twiddling bits than
when signed. My programming practice is to use unsigned everywhere that
a negative number is unexpected.

> Sure, and then the program might break when an array has more the 2^31
> elements; or it might work on one platform and break on another one.

> By contrast, with (u)intptr_t, on modern architectures you use the
> type that's as wide as the GPRs. And I don't see a reason why to use
> something else for a loop counter.

This is equivalent to my argument above--int SHOULD be the fastest kind
of arithmetic; sadly this tenet has been cast aside.

> For a type of which you store many in an array or other data
> structure, you probably prefer int32_t rather than int_fast32_t if 32
> bits is enough. So I don't see a reason for int_fast32_t etc.

> These adapt suitably for different
>>targets. If you want to force the issue, then "int64_t" is IMHO clearer
>>than "long long int" and does not give a strange impression where you
>>are using a type aimed at pointer arithmetic for general integer arithmetic.

> Why do you bring up "long long int"? As for int64_t, that tends to be
> slow (if supported at all) on 32-bit platforms, and it is more than
> what is necessary for indexing arrays and for loop counters that are
> used for indexing into arrays.

>>If you want fast local variables, use C's [u]int_fastN_t types. That's
>>what they are for.

> I don't see a point in those types. What's wrong with (u)intptr_t IYO?

In reality, this is a dusty deck problem.

>> Don't use "-fwrapv" unless you actually need it - in most
>>code, if your arithmetic overflows, you have a mistake in your code, so
>>letting the compiler assume that will not happen is a good thing.

> Thank you for giving a demonstration for Scott Lurndal. I assume that
> you claim to be a programmer.

> Anyway, if I have made a mistake in my code, why would let the
> compiler assume that I did not make a mistake be a good thing?

There are more people willing to pay good money for a wrong answer fast
than there are willing to pay good money for correct answer slow.

> I OTOH prefer if the compiler behaves consistently, so I use -fwrapv,
> and for good performance, I write the code appropriately (e.g., by
> using intptr_t instead of int).

Everything I do is inherently 64-bits except for interfaces to OS
services.

>>(And
>>it lets you check for overflow bugs using run-time sanitizers.)

> If the compiler assumes that overflow does not happen, how do these
> "sanitizers" work?

> Anyway, I certainly have code that relies on modulo arithmetic.

> - anton

Anton Ertl wrote:

> scott@slp53.sl.home (Scott Lurndal) writes:
>>Or maybe changing int from 32-bit to 64-bit would have caused
>>as many (or likely more) problems as changing from 16-bit to 32-bit did back in the
>>day.

> In Unix sizeof(int) == sizeof(int *) on both 16-bit and 32-bit
> architectures. Given the history of C, that's not surprising: BCPL
> and B have a single type, the machine word, and it eventually became
> C's int. You see this in "int" declarations being optional in various
> places. So code portable between 16-bit and 32-bit systems could not
> assume that int has a specific size (such as 32 bits), but if it
> assumed that sizeof(int) == sizeof(int *), that would port fine
> between 16-bit and 32-bit Unixes. There may have been C code that
> assumed that sizeof(int)==4, but why cater to this kind of code which
> did not even port to 16-bit systems?

> In any case, I32LP64 caused breakage for my code, and I expect that

# define int int64_t
# define long int64_t
# define unsigned uint64_t
# define ...

> there was more code around with the assumption sizeof(int)==sizeof(int
> *) than with the assumption sizeof(int)==4. Of course, we worked
> around this misfeature of the C compilers on Digital OSF/1, but those
> who assumed sizeof(int)==4 would have adapted their code if the
> decision had been for ILP64.

> - anton

Scott Lurndal wrote:

> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>Or maybe changing int from 32-bit to 64-bit would have caused
>>>as many (or likely more) problems as changing from 16-bit to 32-bit did back in the
>>>day.
>>
>>In Unix sizeof(int) == sizeof(int *) on both 16-bit and 32-bit
>>architectures. Given the history of C, that's not surprising: BCPL
>>and B have a single type, the machine word, and it eventually became
>>C's int. You see this in "int" declarations being optional in various
>>places. So code portable between 16-bit and 32-bit systems could not
>>assume that int has a specific size (such as 32 bits), but if it
>>assumed that sizeof(int) == sizeof(int *), that would port fine
>>between 16-bit and 32-bit Unixes. There may have been C code that
>>assumed that sizeof(int)==4, but why cater to this kind of code which
>>did not even port to 16-bit systems?

> Most of the problems encountered when moving unix (System V)
> from 16-bit to 32-bit were more around missing typedefs for certain
> data types (e.g. uids, gids, pids, etc), so there was
> a lot of code that declared these as shorts, but the 32-bit
> kernels defined these as 32-bit (unsigned) values).

> That's when uid_t, pid_t, gid_t were added.

> Then there were the folks who used 'short [int]' instead of 'int'
> since they were the same size on the PDP-11.

This is a good reason to build a time machine and send back a few
of the Sopranos to take care of those programmers.

> The Unix code ported relatively easily to I32LP64 because uintptr_t
> had been used extensively rather than assumptions about
> sizeof(int) == sizeof(int *).

At least the sense of forward progress.

"Brian G. Lucas" <bagel99@gmail.com> writes:
>What I would like is a compiler flag that did "IFF when an int (or unsigned)
>ends up in a register, promote it to the 'fast' type".

That used to be the point of C's promotion-to-int rule, until the
I32LP64 mistake. Now, despite architectural workarounds like RISC-V's
addw, we see the fallout of this mistake.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

scott@slp53.sl.home (Scott Lurndal) writes:
>The Unix code ported relatively easily to I32LP64 because uintptr_t
>had been used extensively rather than assumptions about
>sizeof(int) == sizeof(int *).

I only heard about (u)intptr_t long after my first contact with
I32LP64 in 1995. I don't think it existed at the time. Of course we
defined our own (u)intptr_t-like types, but there are problems to this
day, e.g., when I want to use printf on that type, which is an int on
one platform and a long on another platform; I guess the solution is
to always use %ld etc, and cast the integer data to be printed to
long/unsigned long.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Thomas Koenig <tkoenig@netcologne.de> writes:

[some incidental text removed]

> David Brown <david.brown@hesbynett.no> schrieb:
>
>> On 17/02/2024 19:58, Terje Mathisen wrote:
>>
>>> int8_t sum(int len, int8_t data[])
>>> {
>>> int8_t s = 0;
>>> for (unsigned i = 0 i < len; i++) {
>>> s += data[i];
>>> }
>>> return s;
>>> }
>>>
>>> will overflow if called with data = [127, 1, -2], right?
>>
>> No. In C, int8_t values will be promoted to "int" (which is always
>> at least 16 bits, on any target) and the operation will therefore
>> not overflow.
>
> Depending on len and the data...

The code as written does not overflow regardless of the
values in the data array or how many are processed.

> [...]
>
> Signed integer overflow is undefined behavior in C and prohibited
> in Fortran. Yet, there is no straightforward, standard-compliant
> way to check for signed overflow (and handle this appropriately)
> in either language. [...]

It isn't hard to write standard C code to determine whether a
proposed addition or subtraction would overflow, and does so
safely and reliably. It's a little bit tedious perhaps but not
difficult. Checking code can be wrapped in an inline function
and invoke whatever handling is desired, within reason.

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>>The Unix code ported relatively easily to I32LP64 because uintptr_t
>>had been used extensively rather than assumptions about
>>sizeof(int) == sizeof(int *).
>
>I only heard about (u)intptr_t long after my first contact with
>I32LP64 in 1995. I don't think it existed at the time.

Sorry, I meant ptrdiff_t, which was used for pointer math.

uintptr_t came later.

On 20/02/2024 18:47, Anton Ertl wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 20/02/2024 13:00, Anton Ertl wrote:
>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>> mitchalsup@aol.com (MitchAlsup1) writes:
>>>>> We are in an era where long has higher performance than ints (except for
>>>>> cache footprint overheads.)
>>>>
>>>> C has been in that era since the bad I32LP64 decision of the people
>>>> who did the first 64-bit Unix compilers in the early 1990s.
>>
>> I presume the main reason for this was the size and cost of memory at
>> the time? Or do you know any other reason? Maybe some of the early
>> 64-bit cpus were faster at 32-bit, just as some early 32-bit cpus were
>> faster at 16-bit.
>
> I know no implementation of a 64-bit architecture where ALU operations
> (except maybe division where present) is slower in 64 bits than in 32
> bits. I would have chosen ILP64 at the time, so I can only guess at
> their reasons:
>
> Guess 1: There was more software that depended on sizeof(int)==4 than
> software that depended on sizeof(int)==sizeof(char *).
>
> Guess 2: When benchmarketing without adapting the source code (as is
> usual), I32LP64 produced better numbers then ILP64 for some
> benchmarks, because arrays and other data structures with int elements
> are smaller and have better cache hit rates.
>
> My guess is that it was a mixture of 1 and 2, with 2 being the
> decisive factor.

Sounds reasonable.

Another possible reason is that it is very useful to have integer types
with sizes 1, 2, 4 and 8 bytes. C doesn't have many standard integer
types, so if "int" is 64-bit, you have "short" as either 16-bit and have
no 32-bit type, or "short" is 32-bit and you have no 16-bit type. With
32-bit "int", it's easy to have each size without having to add extended
integer types or add new standard integer types (like "short short int"
for 16-bit and "short int" for 32-bit).

> I have certainly seen a lot of writing about how
> 64-bit (pointers) hurt performance, and it even led to the x32
> nonsense (which never went anywhere, not surprising to me). These
> days support for 32-bit applications is eliminated from ARM cores,
> another indication that the performance advantages of 32-bit pointers
> are minor.

I saw benchmarks showing x32 being measurably faster, but it's not
unlikely that the differences got less with more modern x86-64
processors (with bigger caches), and it's simply not worth the effort
having another set of libraries and compiler targets just to make some
kinds of code marginally faster.

And support for 32-bit has /not/ been "eliminated from ARM cores". It
may have been eliminated from the latest AArch64 cores - I don't keep
good track of these. But for every such core sold, there will be
hundreds (my guestimate) of 32-bit ARM cores sold in microcontrollers
and embedded systems. You might not be interested in anything that
isn't running on modern 64-bit x86 or AArch64 systems (and that's
absolutely fine - no one is interested in everything), but 32-bit is not
going away any time soon. Even 8-bit has not gone away.

>
>>> BTW, some people here have advocated the use of unsigned instead of
>>> int. Which of the two results in better code depends on the
>>> architecture. On AMD64 where the so-called 32-bit instructions
>>> perform a 32->64-bit zero-extension, unsigned is better. On RV64G
>>> where the so-called 32-bit instructions perform a 32->64-bit sign
>>> extension, signed int is better. But actually the best way is to use
>>> a full-width type like intptr_t or uintptr_t, which gives better
>>> results than either.
>>
>> I would suggest C "fast" types like int_fast32_t (or other "fast" sizes,
>> picked to fit the range you need).
>
> Sure, and then the program might break when an array has more the 2^31
> elements; or it might work on one platform and break on another one.
>

You need to pick the appropriate size for your data, as I said.

> By contrast, with (u)intptr_t, on modern architectures you use the
> type that's as wide as the GPRs. And I don't see a reason why to use
> something else for a loop counter.

I like my types to say what they mean. "uintptr_t" says "this object
holds addresses for converting pointer values back and forth with an
integer type". "uint_fast64_t" says "this holds an unsigned integer
with a range of at least 64 bits, as fast as the target can manage".
And if you want a type that says "this can hold a value as big as the
size of the biggest object on this target", "size_t" is the correct type.

I expect that on most 64-bit platforms, uint_fast16_t, uint_fast32_t,
uint_fast64_t, uintptr_t, size_t, and many other types are all 64-bit
unsigned integers, and all are typedef's of unsigned long int or
unsigned long long int. The same goes for the signed types.
Nonetheless, it is good design to use appropriate type names for
appropriate usage. This makes the code clearer, and increases portability.

So "[u]intptr_t" is - IMHO - the wrong choice for anything other than
dealing with pointers that are converted to an integer type.

>
> For a type of which you store many in an array or other data
> structure, you probably prefer int32_t rather than int_fast32_t if 32
> bits is enough.

Agreed.

(You could even use "int_least32_t" if you wanted extreme portability,
but I have difficulty imagining a platform where that would be anything
other than int32_t. There are DSP ISAs that are still current which
don't support int8_t or int16_t, but code for such devices is usually
highly specialised for such devices, and portability is not an issue.)

> So I don't see a reason for int_fast32_t etc.

Use it when you want a 32-bit range, and as fast as possible.

>
> These adapt suitably for different
>> targets. If you want to force the issue, then "int64_t" is IMHO clearer
>> than "long long int" and does not give a strange impression where you
>> are using a type aimed at pointer arithmetic for general integer arithmetic.
>
> Why do you bring up "long long int"?

If you want a standard integer type in C that has at least 64-bit, you
use "long long int". "long int" is only specified as being at least
32-bit. All other integer types, such as "intptr_t", "size_t" and
"int64_t", are aliases for the standard integer types. (They could be
"extended integer types", but no major C implementation has any of these.)

> As for int64_t, that tends to be
> slow (if supported at all) on 32-bit platforms, and it is more than
> what is necessary for indexing arrays and for loop counters that are
> used for indexing into arrays.
>

And that is why it makes sense to use the "fast" types. If you need a
16-bit range, use "int_fast16_t". It will be 64-bit on 64-bit systems,
32-bit on 32-bit systems, and 16-bit on 16-bit and 8-bit systems -
always supporting the range you need, as fast as possible.

>> If you want fast local variables, use C's [u]int_fastN_t types. That's
>> what they are for.
>
> I don't see a point in those types. What's wrong with (u)intptr_t IYO?
>

I've answered that above.

(I believe we are in close agreements about the facts - when different
sizes are faster - but differ in our opinions of which type names to use.)

>> Don't use "-fwrapv" unless you actually need it - in most
>> code, if your arithmetic overflows, you have a mistake in your code, so
>> letting the compiler assume that will not happen is a good thing.
>
> Thank you for giving a demonstration for Scott Lurndal. I assume that
> you claim to be a programmer.
>

Sorry, that comment went over my head - I don't know what
"demonstration" you are referring to.

> Anyway, if I have made a mistake in my code, why would let the
> compiler assume that I did not make a mistake be a good thing?

If you have a mistake in your code, you want all the help you can get to
find it and fix it - leaving integer overflow as UB means compilers can
provide tools such as sanitizers to aid here, without having to break
conformance with the language.

And if you have /not/ made a mistake in your code, presumably you want
the compiler to assume you have not make a mistake if that assumption
lets it generate more efficient object code. (I realise there are times
when minimising the consequences of possible mistakes is more important
than object code efficiency, and there can be many other factors to take
into account.)

On 20/02/2024 21:58, MitchAlsup1 wrote:
> Anton Ertl wrote:
>
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 20/02/2024 13:00, Anton Ertl wrote:

>
>> Guess 1: There was more software that depended on sizeof(int)==4 than
>> software that depended on sizeof(int)==sizeof(char *).
>
> There remains a lot of SW that is dependent on INT being smaller than LONG.
>

Really? They are the same size on all 32-bit platforms. And they are
the same size on one of the most common 64-bit platforms (Win64).

>
> My ONLY argument is that int was SUPPOSED to be the fastest arithmetic.
> It was in PDP-11 days and VAX days, but it is no longer.

It still is on 32-bit and smaller. But it is not on 64-bit platforms.

It used to be that "int" meant the same as "int_fast16_t" and "long"
meant "int_fast32_t". As you say, that is no longer the case. That is
why I prefer types with explicit ranges for many purposes, though I will
also use "int" for simplicity (or laziness, as some might say!).

>>> I would suggest C "fast" types like int_fast32_t (or other "fast"
>>> sizes, picked to fit the range you need).
>
> The semantics of unsigned are better when you are twiddling bits than
> when signed.

I agree on that - I don't think signed types are appropriate for any
kind of bit twiddling.

> My programming practice is to use unsigned everywhere that
> a negative number is unexpected.

That is a popular practice, but it is not necessarily the best choice.

>> Anyway, if I have made a mistake in my code, why would let the
>> compiler assume that I did not make a mistake be a good thing?
>
> There are more people willing to pay good money for a wrong answer fast
> than there are willing to pay good money for correct answer slow.
>

I prefer tools to find my mistakes quickly and then give the right
answers fast. It seems a better choice than either of your options.
That is particularly the case in the real-time programming I do, where
getting the right answer too slow is as wrong as getting the wrong
answer fast. Time requirements can be part of the correctness
requirements. (But if yours are your only options, then of course
correctness trumps speed.)

On 20/02/2024 20:18, Brian G. Lucas wrote:
> On 2/20/24 10:25, David Brown wrote:

>> I would suggest C "fast" types like int_fast32_t (or other "fast"
>> sizes, picked to fit the range you need).  These adapt suitably for
>> different targets.  If you want to force the issue, then "int64_t" is
>> IMHO clearer than "long long int" and does not give a strange
>> impression where you are using a type aimed at pointer arithmetic for
>> general integer arithmetic.
>>
> What I would like is a compiler flag that did "IFF when an int (or
> unsigned)
> ends up in a register, promote it to the 'fast' type".  This would be great
> when compiling dusty C decks. (Was there ever C code on punched cards?)
>

Well, that will happen to at least some extent (with an optimising
compiler), at least as long as the answer is the same in the end. It
can be done a bit more often with "int" rather than "unsigned int",
precisely because you promised the compiler that your arithmetic won't
overflow so it does not need to worry about that possibility.

On 20/02/2024 19:42, Anton Ertl wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 20/02/2024 16:17, Terje Mathisen wrote:
>>> x86 has had an 'O' (Overflow) flags bit since the very beginning, along
>>> with JO and JNO for Jump on Overflow and Jump if Not Overflow.
>>>
>>
>> Many processors had something similar. But I think they fell out of
>> fashion for 64-bit RISC,
>
> No, it didn't. All the RISCs that had flags registers for their
> 32-bit architectures still have it for their 64-bit architectures.
>

I was thinking more in terms of /using/ these flags, rather than ISA
support for them. ISAs would clearly have to keep the flag registers
and the instructions that used them if they wanted to keep compatibility
with 32-bit code.

But I think it was fairly rare to use the "add 32-bit and update flags"
instruction in 32-bit RSIC systems (except for 64-bit arithmetic), and
much rarer to use the "add 64-bit and update flags" version in 64-bit
versions.

>> as flag registers are a bottleneck for OOO and
>> superscaling
>
> No, it isn't, as demonstrated by the fact that architectures with
> flags registers (AMD64, ARM A64) handily outperform architectures
> without (but probably not because they have a flags register).

I think it would mainly be /despite/ having a flag register, rather than
/because/ of it?

Sometimes having flags for overflows, carries, etc., can be very handy.
So having it in the ISA is useful. But I think you would normally want
your code to avoid setting or reading flags.

> Implementing a flags register in an OoO microarchitecture does require
> execution resources, however.
>

It would, I think, be particularly cumbersome to track several parallel
actions that all act on the flag register, as it is logically a shared
resource.

Do you think it is an advantage for a RISC architecture to have a flags
register compared to alternatives? Say we want to have a double-width
addition so that "res_hi:res_lo = 0:reg_a + 0:reg_b". (I hope my
pseudo-code is clear enough here.) With flags and an "add with carry"
instruction you could have :

carry = 0;
carry, res_lo = reg_a + reg_b + carry
carry, res_hi = 0 + 0 + carry

Alternatively, you could have a double-register result, at the cost of
having more complex register banks :

res_hi:res_lo = reg_a + reg_b

Or you could have an "add and take the high word" instruction and use
two additions :

res_hi = (reg_a + reg_b) >> N
res_lo = reg_a + reg_b

>
>> overflow is a lot less common for 64-bit arithmetic, and
>> people were not really using the flag except for implementation of
>> 64-bit arithmetic.
>
> That's nonsense. People use carry for implementing multi-precision
> arithmetic (e.g., for cryptography) and for Bignums, and they use
> overflow for implementing Bignums. And the significance of these
> features has increased over time.
>

Fair enough, you do want carry (or an equivalent) for big number work.
But I would still contend that the vast majority of integers and integer
arithmetic used in code will fit within 32 bits, and the vast majority
of those that don't, will fit within 64 bits. Once you go beyond that,
you will need lots of bits (such as, as you say, cryptography).

MitchAlsup1 wrote:
> Anton Ertl wrote:
>> My guess is that it was a mixture of 1 and 2, with 2 being the
>> decisive factor.  I have certainly seen a lot of writing about how
>> 64-bit (pointers) hurt performance, and it even led to the x32
>> nonsense (which never went anywhere, not surprising to me).  These
>> days support for 32-bit applications is eliminated from ARM cores,
>> another indication that the performance advantages of 32-bit pointers
>> are minor.
>
> Try programming array codes where the arrays are TB in size with P32.

That _does_ work (for some definition of "work") if those TB arrays are
near-square matrices: Both x and y will easily stay in the 32-bit range,
it is up to the compiler to realize that the effective address of
element[x,y] needs more than those 32 bits, i.e. you need to generate
something like

(uint64_t) y * (uint64_t) y_stride + (uint64_t) x * (uint64_t) x_stride

[snip]>
> The semantics of unsigned are better when you are twiddling bits than
> when signed. My programming practice is to use unsigned everywhere that
> a negative number is unexpected.

Ditto.

>
>> Sure, and then the program might break when an array has more the 2^31
>> elements; or it might work on one platform and break on another one.
>
>> By contrast, with (u)intptr_t, on modern architectures you use the
>> type that's as wide as the GPRs.  And I don't see a reason why to use
>> something else for a loop counter.

You are not alone in thinking that, i.e. usize being the only legal
array index in Rust.

Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

David Brown <david.brown@hesbynett.no> writes:
>On 20/02/2024 18:47, Anton Ertl wrote:

>And support for 32-bit has /not/ been "eliminated from ARM cores". It
>may have been eliminated from the latest AArch64 cores

The ARMv8 architecture fully supports the A32 and T32 instruction sets.

Implementations of the architecture can choose not to implement
the A32 and T32 instruction sets. Some ARMv8 implementations
(e.g. Cavium's) never implemented A32 or T32. Many (if not most) ARM
implementations of ARMv8 implemented the A32/T32 instruction
sets for EL0 (user-mode) only - I'm not aware of any that
supported A32 at privileged exception levels (EL1, EL2 or EL3).

Some of the more recent ARM neoverse cores support A32/T32 at EL0,
and some of them don't. Cavium's cores were 64-bit only.

>good track of these. But for every such core sold, there will be
>hundreds (my guestimate) of 32-bit ARM cores sold in microcontrollers

Indeed, and many ARMv8 SoCs include arm 32-bit M-series microcontrollers on-chip.

On Wed, 21 Feb 2024 14:34:59 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

> David Brown <david.brown@hesbynett.no> writes:
> >On 20/02/2024 18:47, Anton Ertl wrote:
>
> >And support for 32-bit has /not/ been "eliminated from ARM cores".
> >It may have been eliminated from the latest AArch64 cores
>
> The ARMv8 architecture fully supports the A32 and T32 instruction
> sets.
>
> Implementations of the architecture can choose not to implement
> the A32 and T32 instruction sets. Some ARMv8 implementations
> (e.g. Cavium's) never implemented A32 or T32. Many (if not most) ARM
> implementations of ARMv8 implemented the A32/T32 instruction
> sets for EL0 (user-mode) only - I'm not aware of any that
> supported A32 at privileged exception levels (EL1, EL2 or EL3).
>

W.r.t. Arm Inc. Cortex-A cores that's simply wrong.
All 64-bit Cortex-A cores from the very first two (A53 and A57, 2012)
and up to A75 support A32/T32 at all four exception levels. Of those,
A53 and A55 are still produced and used in huge quantities.
The first Cortex-A 64-bit core that supports aarch32 only at EL0 is
Cortex-A76 (2018).

> Some of the more recent ARM neoverse cores support A32/T32 at EL0,
> and some of them don't. Cavium's cores were 64-bit only.
>
>
> >good track of these. But for every such core sold, there will be
> >hundreds (my guestimate) of 32-bit ARM cores sold in
> >microcontrollers
>
> Indeed, and many ARMv8 SoCs include arm 32-bit M-series
> microcontrollers on-chip.

Still, I don't think that the ratio of all ARM cores combined to cores
in smartphone application processors is really hundreds. I'd say,
something between 15 and 30.
By now, some of smartphone cores in current production, most notable
"LITTLE" Cortex-A510, still support T32/A32, but in few years
everything in this space will be aarch64-only.

On Wed, 21 Feb 2024 13:27:23 +0100
David Brown <david.brown@hesbynett.no> wrote:

> On 20/02/2024 20:18, Brian G. Lucas wrote:
> > On 2/20/24 10:25, David Brown wrote:
>
> >> I would suggest C "fast" types like int_fast32_t (or other "fast"
> >> sizes, picked to fit the range you need).  These adapt suitably
> >> for different targets.  If you want to force the issue, then
> >> "int64_t" is IMHO clearer than "long long int" and does not give a
> >> strange impression where you are using a type aimed at pointer
> >> arithmetic for general integer arithmetic.
> >>
> > What I would like is a compiler flag that did "IFF when an int (or
> > unsigned)
> > ends up in a register, promote it to the 'fast' type".  This would
> > be great when compiling dusty C decks. (Was there ever C code on
> > punched cards?)
>
> Well, that will happen to at least some extent (with an optimising
> compiler), at least as long as the answer is the same in the end. It
> can be done a bit more often with "int" rather than "unsigned int",
> precisely because you promised the compiler that your arithmetic
> won't overflow so it does not need to worry about that possibility.
>

In case of array indices I'd replace your "a bit more" by "a lot
more".
If one wants top performance on 64-bit architectures then avoiding
'unsigned int' indices is a very good idea. Hoping that compiler will
somehow figure out what you meant instead of doing what you wrote is a
naivety.

Michael S <already5chosen@yahoo.com> writes:
>On Wed, 21 Feb 2024 14:34:59 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:
>
>> David Brown <david.brown@hesbynett.no> writes:
>> >On 20/02/2024 18:47, Anton Ertl wrote:
>>
>> >And support for 32-bit has /not/ been "eliminated from ARM cores".
>> >It may have been eliminated from the latest AArch64 cores
>>
>> The ARMv8 architecture fully supports the A32 and T32 instruction
>> sets.
>>
>> Implementations of the architecture can choose not to implement
>> the A32 and T32 instruction sets. Some ARMv8 implementations
>> (e.g. Cavium's) never implemented A32 or T32. Many (if not most) ARM
>> implementations of ARMv8 implemented the A32/T32 instruction
>> sets for EL0 (user-mode) only - I'm not aware of any that
>> supported A32 at privileged exception levels (EL1, EL2 or EL3).
>>
>
>W.r.t. Arm Inc. Cortex-A cores that's simply wrong.
>All 64-bit Cortex-A cores from the very first two (A53 and A57, 2012)
>and up to A75 support A32/T32 at all four exception levels. Of those,
>A53 and A55 are still produced and used in huge quantities.
>The first Cortex-A 64-bit core that supports aarch32 only at EL0 is
>Cortex-A76 (2018).

I'm looking at it from a server-grade core (neoverse) perspective. Even
with the Cortex-A cores, there wasn't much -demand- for
aarch32 support at higher levels (except for Rasp Pi, which
granted there are a considerable number of them).

On 21/02/2024 17:23, Michael S wrote:
> On Wed, 21 Feb 2024 14:34:59 GMT
> scott@slp53.sl.home (Scott Lurndal) wrote:
>
>> David Brown <david.brown@hesbynett.no> writes:

>>> good track of these. But for every such core sold, there will be
>>> hundreds (my guestimate) of 32-bit ARM cores sold in
>>> microcontrollers
>>
>> Indeed, and many ARMv8 SoCs include arm 32-bit M-series
>> microcontrollers on-chip.
>
> Still, I don't think that the ratio of all ARM cores combined to cores
> in smartphone application processors is really hundreds. I'd say,
> something between 15 and 30.

32-bit ARM Cortex-M cores are /everywhere/. Your smart phone probably
has several of them for the cellular modem, the wireless interface, and
other devices. Your TV will have them, your microwave, your keyboard,
your games console controllers. But my guestimate is no more than a
guestimate, and the ratio is perhaps less than it used to be as
smartphones and other such things get more and more cores.