Path: ...!news.roellig-ltd.de!open-news-network.org!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Mon, 16 Sep 2024 09:01:08 +0200
Organization: A noiseless patient Spider
Lines: 71
Message-ID: <vc8l3k$2mrq3$1@dont-email.me>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at>
 <vbcob9$dvp4$1@dont-email.me> <vbd6ia$e0ld$2@dont-email.me>
 <UxpCO.174965$Hld5.7714@fx15.iad> <vc41rl$1fhjd$1@dont-email.me>
 <2024Sep14.152652@mips.complang.tuwien.ac.at> <vc5olr$1vbml$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 16 Sep 2024 09:01:08 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d1583d3c65366d20e8e7bb3dd5deb61e";
	logging-data="2846531"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+Zt4okrrdz9dJIRQTzQj8x6apoP90qLQg="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:92pS7oktUsoAbuO9JX2j+JC+Tu8=
Content-Language: en-GB
In-Reply-To: <vc5olr$1vbml$1@dont-email.me>
Bytes: 4993

On 15/09/2024 06:42, BGB wrote:
> 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, ...
> 

uintptr_t is usually a more natural choice - on almost all systems, it 
is representing an address, and those are unsigned.

The other biggest hinder (apart from breaking unwarranted assumptions 
about sizes in existing code) to 64-bit int is the number of fundamental 
integer types in C.  You have char, short, int, long and long long.  So 
if int is 64-bit, there are not sufficient standard types to have 8-bit, 
16-bit and 32-bit types as well.  But at the other end you have int, 
long and long long that are all 64-bit (perhaps one of them might be 
128-bit).  The integer type system in C was made at a time when 16-bit 
systems were common and 32-bit would be more than enough for anyone, and 
before the world settled on 8-bit bytes and powers of two for integer sizes.

I think using the <stdint.h> types for anything size-specific makes a 
lot of sense.  For a lot of things, exact sizes don't matter, 32-bit int 
(but often not unsigned int) is as efficient as anything else, and 
assuming at least 32 bits is not a hinder to portability.  But I would 
be reluctant to use "short", "long" or "long long" in any code - 
<stdint.h> types do a much better job.