From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_LOW,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15021 invoked from network); 31 May 2023 17:03:44 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 31 May 2023 17:03:44 -0000 Received: (qmail 13830 invoked by uid 550); 31 May 2023 17:03:41 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 13792 invoked from network); 31 May 2023 17:03:40 -0000 Date: Wed, 31 May 2023 13:03:28 -0400 From: Rich Felker To: Jens Gustedt Cc: musl@lists.openwall.com Message-ID: <20230531170328.GI4163@brightrain.aerifal.cx> References: <20230531144128.GD4163@brightrain.aerifal.cx> <20230531165545.29eb823f@inria.fr> <20230531145724.GF4163@brightrain.aerifal.cx> <20230531170700.65bd9c11@inria.fr> <20230531151406.GG4163@brightrain.aerifal.cx> <20230531173718.3d7d499f@inria.fr> <20230531154043.GH4163@brightrain.aerifal.cx> <20230531175628.168043d2@inria.fr> <84a7a59e-afe9-2b63-7039-25f9638cfb0b@ispras.ru> <47E67930-DACE-4475-86F2-022A0EAA5F30@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <47E67930-DACE-4475-86F2-022A0EAA5F30@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [C23 128 bit 4/4] C23: implement proper support for int128_t and uint128_t On Wed, May 31, 2023 at 06:58:15PM +0200, Jens Gustedt wrote: > Am 31. Mai 2023 18:30:16 MESZ schrieb Alexander Monakov : > > > > On Wed, 31 May 2023, Jā‚‘ā‚™ā‚› Gustedt wrote: > > > > > Again, this is not an extension but an optional feature, and this has > > > nothing of bleeding edge. This is present in compilers since ages, and > > > everybody is using their specific ways to go around the restrictions > > > of previous C standards. > > > > So, to make sure, by compiler support do you mean __int128 here? > > yes > > > It is > > not supported on 32-bit platforms neither by GCC nor by LLVM. On 64-bit > > platforms it is piggy-backing on double-word operations support required > > for implementing 64-bit 'long long' on 32-bit platforms. > > So what? On the arch where it exist, it is used and useful. (And I > also think that implementations improved over the state from 20 > years ago that you describe.) > > Nobody is talking about offering it on compilers where there is no > support. With the proposed patches this becomes an optional feature > with feature tests. A real improvement for users, that up to now > have to guess on their own. _BitInt, and knowing the max available via BITINT_MAXWIDTH, provides the same functionality to users without the burden on the library implementation, which will necessarily keep doubling for the reason Alexander mentioned -- once you have size N, size 2N gets added as a consequence of supporting mul/div. Nobody has been asking to be able to printf 128-bit numbers in decimal. They've been asking to be able to use 128- or even 256-bit integers in vector ops, crypto math, ipv6 routing, etc. Rich