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=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 10487 invoked from network); 4 Jun 2020 22:27:01 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 4 Jun 2020 22:27:01 -0000 Received: (qmail 11286 invoked by uid 550); 4 Jun 2020 22:26:58 -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 11268 invoked from network); 4 Jun 2020 22:26:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=octaforge.org; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm3; bh=5Ng38xOvRHvf9fTa0aUIZD6HVbxY wrDC4S5AQaE8ML0=; b=HahTIaQ/e/ddIfHk+NZdwxi7I61owFLRWQd3hnkz601f PYcl93ah48wKG1cW8GRvXZjgXwkQHMxZqwnvi95yUI4z6mMIn+HpX0+j/amn+6ST /Z9bPFA/9kalQoD7NWlSw4e3+MJ0UjQq0zSYKJLt3/nz4inVRdGEcYOJrEUSHFME pWvRNsGw1PFt2NgPH4TY6/sqBJNBduUZx4dgdzfMgCeKkhJWcvW4O6N2pGT3bbdS b9cWlyGkJETO6mzuMtpLMkIEQIf1ItJVFix5l0cXSzF2mvJBYQe9YwrP1d+XgscP QwMuwY/24aLO5DviPmyfGhUl9dN1kRdOwzz7myjI1w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=5Ng38x OvRHvf9fTa0aUIZD6HVbxYwrDC4S5AQaE8ML0=; b=WXJXKXY+a2BuvzEKcM4e8p 26lg47ZxHS9LOEux35u8qUudBW50CRqQatqRi75/OsS8yNF6kRAk98CPnmgUflW3 YXxUxFIQQq5OMrIe94Ruojymk/tFtc3dS0Rfegc58k7uEAqX+0UxgP1AMENKT2Bk uFUBGUCP7HPuv5INO9R/dGa2QKRtj3CZS8kZobUsVzHU4pR035f3d09x7WjHhAOK YIPtVBygkoRFV5MLOQujsLJpWBOFQa3hpMI6Z0ppMBZcui5NKhUh3uOz15VLWxrp +FImS9yPi3gtVFUinVUMJGJe9AQnpz3Yt3DEAjHX2ldw7+X65ilAJUskXX1r5DyQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudegvddgtdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdffrghn ihgvlhcumfholhgvshgrfdcuoegurghnihgvlhesohgtthgrfhhorhhgvgdrohhrgheqne cuggftrfgrthhtvghrnhepieevvddvjeehiedtvdelgfeuiefhgfetvdeuhfffteehuddu fffgudfhfffhleefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepuggrnhhivghlsehotghtrghfohhrghgvrdhorhhg X-ME-Proxy: X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6 Mime-Version: 1.0 Message-Id: <4ca9d8f4-4d61-4e99-969c-03a99e4fd3cc@www.fastmail.com> In-Reply-To: References: <20200602142337.GS25173@kitsune.suse.cz> <3aeb6dfe-ae23-42f9-ac23-16be6b54a850@www.fastmail.com> <20200604171232.GG31009@gate.crashing.org> <20200604171844.GO1079@brightrain.aerifal.cx> <20200604173312.GI31009@gate.crashing.org> <20200604211009.GK31009@gate.crashing.org> <60fa8bd7-2439-4403-a0eb-166a2fb49a4b@www.fastmail.com> Date: Fri, 05 Jun 2020 00:26:22 +0200 From: "Daniel Kolesa" To: "Joseph Myers" Cc: "Segher Boessenkool" , musl@lists.openwall.com, "Rich Felker" , =?UTF-8?Q?Michal_Such=C3=A1nek?= , libc-alpha@sourceware.org, eery@paperfox.es, "Will Springer" , "Palmer Dabbelt via binutils" , "via libc-dev" , linuxppc-dev@lists.ozlabs.org Content-Type: text/plain Subject: Re: [musl] Re: ppc64le and 32-bit LE userland compatibility On Fri, Jun 5, 2020, at 00:08, Joseph Myers wrote: > On Thu, 4 Jun 2020, Daniel Kolesa wrote: > > > The ELFv2 document specifies things like passing of quadruple precision > > floats. Indeed, VSX is needed there, but that's not a concern if you > > *don't* use quadruple precision floats. > > My understanding is that the registers used for argument passing are all > ones that exactly correspond to the Vector registers in earlier > instruction set versions. In other words, you could *in principle* > produce an object, or a whole libm shared library, that (a) passes or > receives _Float128 values in registers, (b) does not use any instructions > beyond those available with -mcpu=970, (c) would work as intended whether > executed on a 970 or on POWER8 and (d) when executed on POWER8, would > fully interoperate with objects receiving or passing _Float128 values and > compiled for POWER8 to use VSX instructions for that purpose. GCC may not > support _Float128 for older processors, but that doesn't prevent you from > maintaining patches to add such support. (But if you want to support > those 64-bit processors that don't have Vector registers at all, you > indeed can't use binary128 and interoperate with code using VSX for that > format in POWER8.) There's a potential userbase with 64-bit BE processors from Freescale/NXP that don't have any AltiVec support, I believe they are still in production - I'd like to retain support for these targets, as well as older IBM processors. The userland generally also supports that, and we've had multiple requests for support of this kind of hardware. And while implementing it with just VMX may be possible, most hardware running this ABI wouldn't have any support for quad precision FP, and would perform better with using just double-precision. We're not a commercial project, so we're just trying to support users within the FOSS community; I definitely wouldn't mind having this be just an ABI variant parallel to the others. Using 64-bit long doubles also has the benefit of being the same ABI as musl, which would enable things such as gcompat to work. Either way I'll think about it some more and possibly prepare an RFC port. I'm definitely willing to put in the work and later maintenance effort if that's what it takes to make it happen. > > (Cf. how the Arm hard-float ABI variant works even on processors with > single-precision-only VFP, because such processors still have the > double-precision loads and stores although not double-precision > arithmetic. When working on that ABI support in GCC some years ago, I > also made sure that GNU vector types corresponding to NEON vector types > were passed consistently for the hard-float ABI whether or not any vector > instructions were present - thus, avoiding depending on the machine modes > for those vector types because GCC could choose a different machine mode > depending on the instructions available.) > > -- > Joseph S. Myers > joseph@codesourcery.com > Daniel