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.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15874 invoked from network); 4 May 2023 16:15:08 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 4 May 2023 16:15:08 -0000 Received: (qmail 5693 invoked by uid 550); 4 May 2023 16:15:05 -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 5661 invoked from network); 4 May 2023 16:15:04 -0000 Date: Thu, 4 May 2023 12:14:52 -0400 From: Rich Felker To: =?utf-8?B?SuKCkeKCmeKCmw==?= Gustedt Cc: musl@lists.openwall.com Message-ID: <20230504161451.GE4163@brightrain.aerifal.cx> References: <20230503000045.GU4163@brightrain.aerifal.cx> <20230503111246.00ba409e@inria.fr> <20230503141619.GW4163@brightrain.aerifal.cx> <20230503171111.15092dbb@inria.fr> <20230503172802.GY4163@brightrain.aerifal.cx> <20230503204656.152f59b8@inria.fr> <20230503193325.GZ4163@brightrain.aerifal.cx> <20230504084846.3f8152d7@inria.fr> <20230504143052.GB4163@brightrain.aerifal.cx> <20230504175357.43346100@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230504175357.43346100@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] patches for C23 On Thu, May 04, 2023 at 05:53:57PM +0200, Jā‚‘ā‚™ā‚› Gustedt wrote: > Rich, > > on Thu, 4 May 2023 10:30:53 -0400 you (Rich Felker ) > wrote: > > > > > You're confusing > > > > > > ?? > > > Note that you can use gcc -S to generate the asm, > > sure > > > clean up any cruft > > in it, and commit the output to git, using a function like this: > > > > struct int128_s { uint64_t a, b; }; > > union u { __int128 x; struct int128_s s; }; > > > > struct int128_s __pop_arg_int128(va_list *ap) > > { > > return (union u){ .x = va_arg(*ap, __int128) }.s; > > } > > > > > This leaves us with fallback code to write that will probably rarely > > > be used. Also, I have difficulties to asses the effort that is > > > needed. > > > > See above. > > Yes, sure, what is worrying me is not to do that for one architecture > that I have and know some about (well certainly have to learn things, > but that's ok) but to have that for all architectures, to which I > don't have access and that may have asm fiddling that I don't know > about. I don't expect you do to this work for us. It's something myself or anyone else working on musl stuff can do and that your patches can just assume is already present in musl by a name like __pop_arg_int128 or something. > > The main remaining code is writing explicit long mul/div for operating > > on a struct representing int128 in two int64s which can be used in > > printf and scanf/strto*. The div is only /10, so I think it can be > > quite compact (vs arbitrary 128-bit division which would be nasty). > > Yes, I figured that. Some of that for bases 16 and 10 should already > be there in the floating point code, I imagine. But still this is not > so easy to read from the start, and would need good review and > testing. And our internal dispatch `__intscan` accept bases from 2 to > 36, so there is either a bit more than 10 and 16 to cover, or a > special instantiation of the function as used by `scanf` for 128 types > has to be created. __intscan only needs mul, not div, and mul is the easy side. It's printf that needs div, and 10 is the only non-power-of-two base there. In the case of __intscan, I'd just change the signature to return an int128 tuple struct, and switch to using it when the value no longer fits in smaller type. The "lim" argument mechanism needs some change too I think. No need for a different variant of the function for int128; the whole point of the way it's implemented is not to have multiple versions of it for different types. Rich