From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: ARM optimisations
Date: Thu, 28 Feb 2013 18:30:51 -0500 [thread overview]
Message-ID: <20130228233051.GO20323@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAPfzE3aKWgRhNuvM846xTSB2eHS5AZugME6ruLmgwCcuCOPDOA@mail.gmail.com>
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
next prev parent reply other threads:[~2013-02-28 23:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-28 23:15 Andre Renaud
2013-02-28 23:30 ` Rich Felker [this message]
2013-03-02 4:33 ` Rob Landley
2013-03-02 6:21 ` Rich Felker
2013-03-04 18:55 ` Rob Landley
2013-03-02 11:34 ` Szabolcs Nagy
2013-03-02 20:33 ` Andre Renaud
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130228233051.GO20323@brightrain.aerifal.cx \
--to=dalias@aerifal.cx \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).