these changes are the outcome of a long mailing list thread that took
place March 2016, "musl licensing". among minor other issues,
prospective users were not confident that the whole-project MIT
license would grant permission for files to which the COPYRIGHT file
expressed a belief that copyright not apply, if it turned out that
these files were actually subject to copyright.
in accordance with the original intent of applying a permissive
license to the project, which was that license issues not be an
obstacle to use, the text which was causing confusion is removed. no
new claims of copyright are made, but new text is added to clarify
that the grant of permissions applies to all files, and an explicit
grant of permission to use public headers and crt files without
attribution has been made.
this patch was reviewed and approved by all substantial contributors
to the affected files: Bobby Bingham, John Spencer (rofl0r), Nicholas
J. Kain, Rich Felker, Richard Pennington, Stefan Kristiansson, and
Szabolcs Nagy.
these additions were made based on scanning commit authors since the
last update, at the time of the 1.1.7 release, and adding everyone
with either substantial code contributions or a pattern of ongoing
simple patch submission.
the approach of this implementation was heavily investigated prior to
adopting it. attempts to obtain similar performance with pure C code
were capping out at about 75% of the performance of the asm, with
considerably larger code size, and were fragile in that the compiler
would sometimes compile part of memcpy into a call to itself.
therefore, just using the asm seems to be the best option.
this commit is the first to make use of the new subarch-specific asm
framework. the new armel directory is the location for arm asm that
should not be used for all arm subarchs, only the default one. armhf
is the name of the little-endian hardfloat-ABI subarch, which can use
the exact same asm. in both cases, the build system finds the asm by
following a memcpy.sub file.
the other two subarchs, armeb and armebhf, would need a big-endian
variant of this code. it would not be hard to adapt the code to big
endian, but I will hold off on doing so until there is demand for it.
these changes are based on the following communication via email:
"I hereby grant that all of the code I have contributed to musl on or
before April 23, 2012 may be licensed under the terms of the following
MIT license:
Copyright (c) 2011-2012 Nicholas J. Kain
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE."
Smoothsort is an adaptive variant of heapsort. This version was
written by Valentin Ochs (apo) specifically for inclusion in musl. I
worked with him to get it working in O(1) memory usage even with giant
array element widths, and to optimize it heavily for size and speed.
It's still roughly 4 times as large as the old heap sort
implementation, but roughly 20 times faster given an almost-sorted
array of 1M elements (20 being the base-2 log of 1M), i.e. it really
does reduce O(n log n) to O(n) in the mostly-sorted case. It's still
somewhat slower than glibc's Introsort for random input, but now
considerably faster than glibc when the input is already sorted, or
mostly sorted.
Rich Felker
nsz