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 13372 invoked from network); 25 May 2023 14:34:31 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 25 May 2023 14:34:31 -0000 Received: (qmail 17449 invoked by uid 550); 25 May 2023 14:34:28 -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 17411 invoked from network); 25 May 2023 14:34:27 -0000 Date: Thu, 25 May 2023 10:34:15 -0400 From: Rich Felker To: =?utf-8?B?SuKCkeKCmeKCmw==?= Gustedt Cc: musl@lists.openwall.com Message-ID: <20230525143415.GJ4163@brightrain.aerifal.cx> References: <1fe28ea2525f112264a1a819d8ce50a97504ab8b.1684932892.git.Jens.Gustedt@inria.fr> <20230524212835.GC4163@brightrain.aerifal.cx> <20230525111653.4b0175d3@inria.fr> <20230525130723.GH4163@brightrain.aerifal.cx> <20230525160501.787872b2@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230525160501.787872b2@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [C23 new stdlib 2/4] C23: add the memalignment function On Thu, May 25, 2023 at 04:05:01PM +0200, Jā‚‘ā‚™ā‚› Gustedt wrote: > > on Thu, 25 May 2023 09:07:23 -0400 you (Rich Felker ) > wrote: > > > > So you want me to use the ctz and clz interfaces from the internal > > > atomics for the implementation of ? Are they not overkill > > > for this simple purpose? (I mean they are meant to be atomic, > > > arent't they?) > > > > No, I think you're mixing up code which is part of musl and code which > > is (included as) part of the application. atomic.h is a musl > > implementation detail and is not even present for application code > > included from stdbit.h to use. > > I am not clear to which question you are answering "no". Fact is that > these functions are used for `ffs` and friends, so they are the > natural candidates to base the implementation upon. (`ffs` cannot be > used directly because they have intefaces with signed integers.) OK, maybe I misunderstood. They can and should be used in musl sources for implementing these interfaces as external functions, just not for macro definitions in the headers. I thought we were talking about the latter. It looks like the primitives we have cover everything needed for stdbit.h functions except popcnt. Not sure what the best way to add that is. Perhaps with a new a_popcnt that archs can override. This would also allow configure to probe for a builtin and select use of that if desired. It looks like that generates a call to libgcc on archs with no native version. > I'd very much like to avoid to reinvent the wheel, here, and in the > internal code that I have looked at I have not detected much which > would be specific for atomics. But maybe I am overlooking something, > thus the question. Having them in "atomics" is a historical misnomer, but it's vacuous since they operate on values not objects. The effort to move them to a separate file and setup per-arch machinery for defining them there is nontrivial and the value seems near-zero, so I haven't pursued it. Rich