From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13321 Path: news.gmane.org!.POSTED!not-for-mail From: "A. Wilcox" Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] powerpc64le: Add single instruction math functions Date: Thu, 27 Sep 2018 17:53:01 -0500 Organization: =?UTF-8?Q?Ad=c3=a9lie_Linux?= Message-ID: References: <20170623193533.GO1627@brightrain.aerifal.cx> <594DB66E.7030009@adelielinux.org> <594DDEC6.8030200@adelielinux.org> <594EFC63.3000707@adelielinux.org> <20170625142821.GC1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ChloEF3oH2JcFnAEy1hP6mgzSbso3sESq" X-Trace: blaine.gmane.org 1538088595 23284 195.159.176.226 (27 Sep 2018 22:49:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 27 Sep 2018 22:49:55 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux ppc64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 To: musl@lists.openwall.com Original-X-From: musl-return-13337-gllmg-musl=m.gmane.org@lists.openwall.com Fri Sep 28 00:49:51 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1g5f6U-0005yL-LR for gllmg-musl@m.gmane.org; Fri, 28 Sep 2018 00:49:50 +0200 Original-Received: (qmail 21978 invoked by uid 550); 27 Sep 2018 22:51:59 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 21960 invoked from network); 27 Sep 2018 22:51:58 -0000 Openpgp: preference=signencrypt In-Reply-To: <20170625142821.GC1627@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:13321 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ChloEF3oH2JcFnAEy1hP6mgzSbso3sESq Content-Type: multipart/mixed; boundary="OKb3F99mdQyVWlPnPWcZmGp9j849weAMb"; protected-headers="v1" From: "A. Wilcox" To: musl@lists.openwall.com Message-ID: Subject: Re: [musl] [PATCH] powerpc64le: Add single instruction math functions References: <20170623193533.GO1627@brightrain.aerifal.cx> <594DB66E.7030009@adelielinux.org> <594DDEC6.8030200@adelielinux.org> <594EFC63.3000707@adelielinux.org> <20170625142821.GC1627@brightrain.aerifal.cx> In-Reply-To: <20170625142821.GC1627@brightrain.aerifal.cx> --OKb3F99mdQyVWlPnPWcZmGp9j849weAMb Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable A little update for those interested. On 06/25/17 09:28, Rich Felker wrote: > On Sat, Jun 24, 2017 at 11:24:59PM -0400, David Edelsohn wrote: >>> Except those based on musl? I mean, we at Ad=C3=A9lie haven't /shipp= ed/ >>> anything PPC64 yet, but I have very good reasons for that (and will >>> get to them later in this email). We have definitely shipped on PPC64 now. We were actually the first distro in history (to my knowledge) to ship musl on PPC64. That's PPC64, as in 64-bit big endian PowerPC. KDE, LXQt, Firefox, Thunderbird, the whole lot. I'm using it on an iMac G5, several G5 towers, and a Talos 2. I actually threw out my last x86_64 system once the Talos 2 arrived. >> You can do whatever you want, but it has been difficult enough fixing >> all of the poor assumptions in the entire Open Source and proprietary >> source ecosystem for the change to PPC64LE ELFv2. If you and Adelie >> want to take on that challenge for PPC64BE ELFv2, great. The >> OpenPower Foundation and its members are not going to fight that >> battle. Keep talking like you speak for the Foundation... https://twitter.com/hughhalf/status/1027109176563064833 > I see where you're coming from, but I don't see where it's > significantly harder than fighting with and fixing software that > doesn't work with musl due to gratuitous (or sometimes moderately > reasonable) glibcisms. Having this type of ABI issue increases the > number of such cases a bit, but I don't expect it to be a significant > portion of the overall work. Rich is correct; it hasn't been significant, and it has been very little challenge when something is broken. >>> I apologise if my words seem strong, but I do not take this lightly. >>> We have a number of users clamouring for us to save their older PPC64= >>> hardware from unmaintained AIX, unmaintained Debian, or in some cases= >>> ten-or-more year old fruity OSes. I obviously do not expect ABI >>> compatibility with decades-old non-Linux Unixes. However, if there >>> needs to be an ELFv1 port for a technical reason, I may have to >>> investigate maintaining the port myself. >> >> As I wrote above, the entire external ecosystem makes the endianness /= >> ABI assumption. Golang assumes this. OpenJDK assumes this. ATLAS >> BLAS and OpenBLAS assume this. GMP assumes this. PyPy assumes this. >> Mono assumes this. libffi assumes this. Erlang probably assumes this. >> FFMPEG, x264, libvpx assume this. MongoDB may assume this. NVIDIA >> nvcc assumes this. Etc., etc., etc. * Golang: incorrect. The code is written correctly, and Go runs properly on BE PPC64 (though not correctly; this is unrelated to ELF ABI)= =2E * OpenJDK: correct, patch is fermenting. * BLAS/OpenBLAS: untested as of yet. * GMP: incorrect. Works fine and passes all tests on musl without any patching. * PyPy: incorrect, as above. * Mono: incorrect, as above. * libffi: incorrect, but did require patching for musl's insistence on using IEEE long doubles instead of IBM long doubles. * FFmpeg, x264: incorrect. Work fine, though did need a single patch to make AltiVec support build properly; this affected ppc32 and ppc64/ELFv1 as well. * libvpx: does not support PowerPC in any capacity anyway. * MongoDB: untested as of yet. * NVIDIA nvcc: violates our package policy in many ways, proprietary license being the largest. Also requires LE as far as I can tell, so completely orthogonal to supporting BE. > Several of these are trivially fixed with --disable-asm or similar -- > at least gmp, ffmpeg, x264, and libvpx should fall in that category. > Obviously it's desirable to get the asm working to improve > performance, but it can be done incrementally. It also should be > possible to heuristically test for this kind of thing by grepping for > ppc64 asm function prologue in the sources. The only --disable-asm required was OpenSSL, and we have a patch fermenting to fix that as well. (Most of their checks use _CALL_ELF correctly, but a few do not.) > Only stuff that actually does codegen (compilers, jits, etc.) has a > fundamental reason to be affected, and for the most part fixing it > should just be a matter of fixing the conditionals that look for > endianness to look for _CALL_ELF=3D=3D2 where that's what they really > meant to do. One semi-important JIT that wasn't named was ORC, which is used by gstreamer to help multimedia performance. I assume that wasn't named because nobody merged LE support either? We managed to patch it for ELFv2 cleanly, supporting both musl in BE *and* all the ELFv2 LE distros including glibc. :) We're also about to land a Valgrind patch to support ELFv2 on BE. I believe the last major issue that we haven't yet sent upstream is OpenJDK. (OpenSSL is a performance regression, but functionally complete= =2E) >> It's not that the packages fundamentally cannot be fixed, but the >> FLOSS ecosystem is much larger, richer, complex and more >> interdependent. If one wants to create an embedded system, one can >> exert control over the entire software ecosystem. For a >> Linux-compatible system, one cannot. >> >> If you accept that some parts of the software ecosystem simply won't >> build or function correctly for your system and configuration, or some= >> packages randomly will stop building or stop functioning correctly >> after a package is updated, fine. We do not accept that in the slightest. And neither should anyone else. We accept that parts of the software ecosystem need to be *fixed*. Best to you and yours, --arw --=20 A. Wilcox (awilfox) Project Lead, Ad=C3=A9lie Linux https://www.adelielinux.org --OKb3F99mdQyVWlPnPWcZmGp9j849weAMb-- --ChloEF3oH2JcFnAEy1hP6mgzSbso3sESq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjNyWOYPU1SaTSMHHyynLUZIrnRQFAlutX00ACgkQyynLUZIr nRQrtxAAukHhe+N4lQ5ESt553X+iFMaHryuFJ6DppeXmWCDmHZR4eJvuLDMQwIED xjC+djroi5HBZfLDCHySZfTPAGGC1Mmdj8MoQdO3Yn0x1BZ/T/f79RrA7+2tsne8 CPu2na+jFOGY5Fqxa8rT1N3V85A34ZVsDeSq+ta9vLlIOM1M4EneTetPAwtX2kfQ 6JQTArzmCMmVa+ill0uzd16hLoiFrdt0Coef/HOv0XNAzV1oRWcQ68qGfbC3Bvii bXLJPK7qGHvwsRYXclamNx11zCKCCzgdjIgA68eO5IM5/VetnqvIOhNq9qYwXVfn f1IpW8HVfrtyS5xdHCQBPs3G1RIk6AomrwqdiEf/z//YihrGSjUBf+regMuXkzek 2TkSafnTixO52fFYPM45FT7ccKqsQ9IRJh8G1kY3nsjkoVB0AW2K1U9zLvXAoB1C neHMrH62jJ3aE7hRUnthMOZKGkaf1tJMwis/mLIQpl9Q6lqEo/BjoXARvvEsPenQ tMtY3yqPo4RX+Dzn7m1lThziIWOx+1o3dpxrs7pyHTe7Z+XiR3EuFk9xxPMONZGL 6z1hvbmviCU2smDAhuDWCia2YKAvxsxfaXICgaVXN32x2cDsjtJC0bQ0gu0xRsdA qtSUdZiH4Hp26rj0Em4Gq3yIQviv09LkimncytIKF2v6rtczVjk= =i6i/ -----END PGP SIGNATURE----- --ChloEF3oH2JcFnAEy1hP6mgzSbso3sESq--