Re: Computer architects leaving Intel...

On 9/14/2024 8:26 AM, Anton Ertl wrote:

kegs@provalid.com (Kent Dickey) writes:

Bringing it back to "architecture" Like Anton Ertl has said, LP64 for
C/C++ is a mistake.  It should always have been ILP64, and this nonsense
would go away.  Any new architecture should make C ILP64 (looking at you
RISC-V, missing yet another opportunity to not make the same mistakes as
everyone else).

 We now have had more than 30 years of catering for this mistake by
everyone involved.  Given their goals, I think that RISC-V made the
right choice for int in their ABI, even if it was the original choice
by the MIPS and Alpha people that they follow, like everyone else, was
wrong.
 That being said, one option would be to introduce another ABI and API
with 64-bit int (and maybe 32-bit long short int), and programmers
could choose whether to program for the ILP API, or the int=int32_t
API.  Would the ILP API/ABI fare better then x32?  I doubt it, even
though I would support it.  This ship probably has sailed.
 

Changing the size of 'int' would likely be a massive pain from a software compatibility POV (possibly effecting things much more than changing the size of pointers, or the size of 'long'; which was a major source of pain during the 32 to 64 bit migration).
When my project got started, I was originally going with 32-bit 'long', like MSVC, but then switched over to keeping 'long' matched with the pointer size, as code that assumed sizeof(long)==sizeof(void *) was more common than code that assumed sizeof(long)==4 (it was more common for code to use 'int' as the de-facto 32-bit type), as well as this being a more useful assumption (though this assumption breaks with 128 bit pointers).
Changing sizeof(int) to be anything other than 4 is likely to break significant amounts of code, and pretty much anything that reads/writes structs to files or similar for data storage.
But, yes, this is even with the whole thing that on a 64-bit machine, 32-bit integers are typically handled in a way where they are sign or zero extended to 64 bits.
Granted, a better alternative might be to rework code to generally use the "stdint.h" types, and to use "intptr_t" for integer types matched to the size of a pointer, ...
...

- anton