From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2866 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: ARM optimisations Date: Thu, 28 Feb 2013 18:30:51 -0500 Message-ID: <20130228233051.GO20323@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1362094261 21722 80.91.229.3 (28 Feb 2013 23:31:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Feb 2013 23:31:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2867-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 01 00:31:25 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UBCwf-0005BB-AK for gllmg-musl@plane.gmane.org; Fri, 01 Mar 2013 00:31:25 +0100 Original-Received: (qmail 5200 invoked by uid 550); 28 Feb 2013 23:31:04 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 5192 invoked from network); 28 Feb 2013 23:31:03 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2866 Archived-At: On Fri, Mar 01, 2013 at 12:15:21PM +1300, Andre Renaud wrote: > Hi, > Can anyone tell me what the policy for musl is regarding ARM optimised > assembly implementations of functions such as memcpy/memmove? I notice > that there are i386/x86_64 versions for some of these. Doing some > simple testing on an ARM platform I found that an ARM asm > implementation of memcpy is ~80% faster than the C one currently in > MUSL (this is on an ARMv5, so no NEON instructions or similar). > > I don't think I'm capable of writing the optimised version entirely > myself, however there are various implementations floating around in > libraries such as bionic etc... Is it possible to have BSD licensed > code brought in to musl (which is MIT licensed)? ARM optimizations are welcome as long as they're thoroughly tested, not heavily bloated, and support all v4 (including no-thumb) and later cpu models, either by using universally-available features or conditioning use of features on the .hidden __hwcap provided in musl. Modern BSD license without advert clause is fully compatible with MIT license, so I don't have an objection to such code, but I'm also not a fan of pure copy-and-paste coding. If nothing else, imported code would probably need to be cleaned up to build as .s rather than .S, removing #ifdefs and stuff like that. If you'd like to introduce some possible implementations we could use or just ideas for how these functions should work, myself and others on the project would be happy to review them. Rich