From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9290 Path: news.gmane.org!not-for-mail From: David Edelsohn Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: musl libc for PPC64 Date: Mon, 8 Feb 2016 18:52:55 -0500 Message-ID: References: <20160208161758.GG9915@port70.net> <20160208165143.GA9349@brightrain.aerifal.cx> <20160208201802.GB9349@brightrain.aerifal.cx> <20160208225921.GD9349@brightrain.aerifal.cx> <20160208232945.GE9349@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1454975594 14844 80.91.229.3 (8 Feb 2016 23:53:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Feb 2016 23:53:14 +0000 (UTC) Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-9303-gllmg-musl=m.gmane.org@lists.openwall.com Tue Feb 09 00:53:13 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aSvcF-0006yw-1u for gllmg-musl@m.gmane.org; Tue, 09 Feb 2016 00:53:11 +0100 Original-Received: (qmail 9633 invoked by uid 550); 8 Feb 2016 23:53:09 -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 9610 invoked from network); 8 Feb 2016 23:53:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=meKJsaHuH9PPwSPw9yvj2KrW0UL4iiOIzkdFqqhd+vI=; b=bSxo3YKKBFPpGnIMcslLc5K3Mu+TW3cKL/SKwMSr73hgqTh6VaPEr76BUgJPIUUTbm Y2USOem5pFr+S/jfUr+2uoVrp5fj/4DOkJ5VR3mEEz59P9nq0s7vehbFQi4WLTT33eUq pIYy3A4mlnaak+HZeC7CQgiAE8gY3lvSO4L4NqFk98jq9Jdmtt+hT6cO6PGwukDYhUey RCR501u2ouoSCW0551TqS1freFPFUF8iKp8G+CiGrfudd88ZtxENnTzjbWMgmfe6pJmU L8jzBsTbo+c1r+1zQnzaN8xSnaZcKGiBoYE+qRNKY5z3Q0jRoGn7MnHlQODzbyISZOZ2 h6nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=meKJsaHuH9PPwSPw9yvj2KrW0UL4iiOIzkdFqqhd+vI=; b=nADLhfeQJed9+MymmHSgGp78DHiBUJ9tZE7vCdY58AKalbhIwsITIEZTD+M/UeHaRB uma4cSSgafS2ePJHpKPF4zrduPp+YEASvyZPSeIWKDFHdjN+QldUBK46Q+6VDhwQg/fW Kp1mkkIk772ZHEIPyO9lo8i1mwnXnmYX33GeeoZWTC1Psk08luhTP//1dapSD5XNmpCf XnurEbsH1sOjFVgRdmRYj/rsbHlM7okpbCJtpcXeSw/1dLX93IuYKmmgg8Q5uRSY6mct jmHm33fWD3PwWYsNqn+aD14XcHmt6WyI8PaMaPEUYDBJwZxf6AVgEXvQ/zQcXCqyWuHD btDw== X-Gm-Message-State: AG10YOTPbGxSWJUZ1EIcRVMVGyr2T0riEb8x0on0e1c8su+snUexAiX9YS3+8nszfJMwj4TaZX1VI8ac2StjIg== X-Received: by 10.25.141.129 with SMTP id p123mr10331603lfd.65.1454975575836; Mon, 08 Feb 2016 15:52:55 -0800 (PST) In-Reply-To: <20160208232945.GE9349@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:9290 Archived-At: On Mon, Feb 8, 2016 at 6:29 PM, Rich Felker wrote: > On Mon, Feb 08, 2016 at 06:24:27PM -0500, David Edelsohn wrote: >> You *can* use v2 ABI for BE, but there is no software to run. There >> is no software or ecosystem or operating system that runs v2 ABI BE. >> It's not a hardware limitation, but there is no environment for the >> alternate combination. > > Indeed. At this point there's no musl ecosystem for ppc64 at all > though; whatever we add is a fresh start. > >> >> IBM has announced that the next generation of the processor will >> >> support native IEEE128 floating point in hardware. There will be >> >> software emulation for the current processors. Support is included in >> >> the forthcoming GCC 6. >> > >> > OK. Does the existing software emulation properly update the hardware >> > floating point status (exception flags) and use the rounding mode? >> >> I'm not sure what you mean. The software emulation assumes the >> hardware support is not present. It doesn't mirror back the state to >> the processor in 64 bit mode. But the emulation is fully IEEE128 >> compliant. > > if fesetround(FE_DOWNWARD) succeeds but then long double math still > rounds to nearest, that's not IEEE compliant. > > The big obstacle to having fenv with softfloat on fully-softfloat > archs is the lack of register state for the rounding mode and > exception flags, so it should be possible to do this right as long as > the cpu has status/mode registers for single/double, which the > soft-quad code can then access/set. If this isn't done right already > we could either try to get it fixed in libgcc or punt and go with > ld64. Who would be interested in working on this? Thanks, David