Path: ...!3.eu.feeder.erje.net!feeder.erje.net!newsfeed.bofh.team!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Sat, 14 Sep 2024 19:11:30 +0000
Organization: Rocksolid Light
Message-ID: <d93c1dc0455692767c89ea9f7bd47ed1@www.novabbs.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="2062221"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$JhbHamPw9tTrEytmde6xleU4b6pxow4cItkcroK4TRLOqYaPh2keO
Bytes: 2526
Lines: 29

On Sat, 14 Sep 2024 13:26:52 +0000, 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.

Until the advent of int32_t the only way to get a known 32-bit container
was int. But I agree with the notion that ILP64 should be universal now,
and if you want/need something smaller, use some other type indicator
than int.

In many cases int is slower now than long -- which violates the notion
of int from K&R days.

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