From owner-freebsd-numerics@FreeBSD.ORG Sun Nov 10 01:43:44 2013 Return-Path: Delivered-To: freebsd-numerics@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DDDD873A; Sun, 10 Nov 2013 01:43:44 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (poofydog.net [198.0.194.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 354CE2E7B; Sun, 10 Nov 2013 01:43:43 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.7/8.14.2) with ESMTP id rA88oe18001907; Fri, 8 Nov 2013 00:50:40 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.7/8.14.2/Submit) id rA88odhp001906; Fri, 8 Nov 2013 00:50:39 -0800 (PST) (envelope-from das@FreeBSD.ORG) Date: Fri, 8 Nov 2013 00:50:39 -0800 From: David Schultz To: Bruce Evans Subject: Re: MUSL math functions Message-ID: <20131108085039.GA1821@zim.MIT.EDU> References: <20131031133352.GA59918@troutmask.apl.washington.edu> <20131101072032.P1002@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131101072032.P1002@besplex.bde.org> Cc: "freebsd-numerics@FreeBSD.org" , David Chisnall , Steve Kargl X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 01:43:44 -0000 On Fri, Nov 01, 2013, Bruce Evans wrote: > >> What are the current blockers for getting them in? > > > > 1) Code freeze for FreeBSD-10 came at the wrong time. > > 2) Got sidetracked on fixing a bug in roundl. > > 3) Can't update my development systems to FreeBSD-11 (where new > > code should appear) because news/pan does not compile with > > clang++ because clang++ appears to have problems compiling > > headers associated with libc++. > > 4) ENOTIME. > > das AWOL :-). I don't commit. Others not very active. Not entirely, but sign me up for the ENOTIME excuse. > > Have you looked at the code? Hint, I have. Here's ccoshl(). > > > > #include "libm.h" > > > > //FIXME > > long double complex ccoshl(long double complex z) > > { > > return ccosh(z); > > } Is there anything usable in there? Thanks for the pointer in any case! > > Yes. I object to importing anything from MUSL or OpenBSD or NetBSD > > without review or testing. It also appears that these functions are > > only available for ld80 archs. FreeBSD has both ld80 and ld128. > > Supporting ld128 can be a blocker. Apart from increasing the amount of > code needed, the extra precision sometimes expands the technical > complications a lot. I think I was the one who proposed several years ago that we should develop the ld80 and ld128 versions at the same time because (a) it's more efficient to do both while you have the algorithm in your head and (b) the ld128 versions probably would never happen otherwise. However, several things have happened since then. For one, years have passed and there's still quite a bit of work to do. For two, the only ld128 platform, sparc64, doesn't look as important as it used to be. For a long time, we had trouble even finding a viable test machine. Therefore, I think any incremental improvement would be welcome -- even if it means doing ld80 only. From owner-freebsd-numerics@FreeBSD.ORG Sun Nov 10 10:05:31 2013 Return-Path: Delivered-To: freebsd-numerics@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 83EF16DE; Sun, 10 Nov 2013 10:05:31 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 520D42127; Sun, 10 Nov 2013 10:05:30 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginm.net [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id rAAA5Ldn096911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 10 Nov 2013 10:05:22 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: MUSL math functions From: David Chisnall In-Reply-To: <20131108085039.GA1821@zim.MIT.EDU> Date: Sun, 10 Nov 2013 10:05:18 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <15792BD0-C47C-4DCA-A112-D3C54F211E67@FreeBSD.org> References: <20131031133352.GA59918@troutmask.apl.washington.edu> <20131101072032.P1002@besplex.bde.org> <20131108085039.GA1821@zim.MIT.EDU> To: David Schultz X-Mailer: Apple Mail (2.1508) Cc: "freebsd-numerics@FreeBSD.org" , Steve Kargl , Bruce Evans X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 10:05:31 -0000 On 8 Nov 2013, at 08:50, David Schultz wrote: > However, several things have happened since then. For one, years > have passed and there's still quite a bit of work to do. For two, > the only ld128 platform, sparc64, doesn't look as important as it > used to be. For a long time, we had trouble even finding a viable > test machine. Therefore, I think any incremental improvement would > be welcome -- even if it means doing ld80 only. The PowerPC SysV ABI says that it's ld128 - we only use 64 bit because = of lack of compiler support when the architecture was brought up, every = other OS uses 128 bit (although I think PPC 128-bit floats are not quite = the same as IEEE 128-bit floats, which may cause some problems). It's = quite likely that we'll change it to ld128 at some point, although that = will involve some ABI breakage which is unfortunate. =20 ARMv8 is ld128 and, although it support hasn't landed yet (it's under = development), it is likely to be a very important platform for FreeBSD = in coming years. MIPS is also ld128 on most systems, but the fact that there is no = 128-bit floating point hardware for MIPS (except in one ASE, where there = is one 128-bit floating point accumulator register) makes this quite a = silly choice, so it will probably stay ld64. David From owner-freebsd-numerics@FreeBSD.ORG Sun Nov 10 17:55:04 2013 Return-Path: Delivered-To: freebsd-numerics@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1ED28720; Sun, 10 Nov 2013 17:55:04 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id D465B27CC; Sun, 10 Nov 2013 17:55:03 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id B38B6D6EBAE; Mon, 11 Nov 2013 04:54:50 +1100 (EST) Date: Mon, 11 Nov 2013 04:54:48 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: David Chisnall Subject: Re: MUSL math functions In-Reply-To: <15792BD0-C47C-4DCA-A112-D3C54F211E67@FreeBSD.org> Message-ID: <20131111040050.D29424@besplex.bde.org> References: <20131031133352.GA59918@troutmask.apl.washington.edu> <20131101072032.P1002@besplex.bde.org> <20131108085039.GA1821@zim.MIT.EDU> <15792BD0-C47C-4DCA-A112-D3C54F211E67@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=bpB1Wiqi c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=1RzFHNT0_LQA:10 a=6I5d2MoRAAAA:8 a=NwZ1TphebqQAfokDLZkA:9 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 Cc: David Schultz , "freebsd-numerics@FreeBSD.org" , Steve Kargl , Bruce Evans X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 17:55:04 -0000 On Sun, 10 Nov 2013, David Chisnall wrote: > On 8 Nov 2013, at 08:50, David Schultz wrote: > >> However, several things have happened since then. For one, years >> have passed and there's still quite a bit of work to do. For two, >> the only ld128 platform, sparc64, doesn't look as important as it >> used to be. For a long time, we had trouble even finding a viable >> test machine. Therefore, I think any incremental improvement would >> be welcome -- even if it means doing ld80 only. > The PowerPC SysV ABI says that it's ld128 - we only use 64 bit because of lack of compiler support when the architecture was brought up, every other OS uses 128 bit (although I think PPC 128-bit floats are not quite the same as IEEE 128-bit floats, which may cause some problems). It's quite likely that we'll change it to ld128 at some point, although that will involve some ABI breakage which is unfortunate. One net reference says that it is the same as sparc, but wikipedia says that it is double-double and gcc implements this. An ibm reference says that sparc has [only] 64-bit registers. Double-double in software would be horrible, possibly slower than IEEE in software on sparc64 where ld128 is about 100 times slower than double precision (old sparc64 is several thousand times slower in nanoseconds than modern i387 with long double precision for both). Double-double is not supported by FreeBSD libm. Sparc64 defines IEEE format in hardware, but no old gcc and current wikipedia say that no sparc CPU ever implemented it. When not emulated via libcalls, it is emulated via traps; this is slower but easier to debug. > ARMv8 is ld128 and, although it support hasn't landed yet (it's under development), it is likely to be a very important platform for FreeBSD in coming years. > > MIPS is also ld128 on most systems, but the fact that there is no 128-bit floating point hardware for MIPS (except in one ASE, where there is one 128-bit floating point accumulator register) makes this quite a silly choice, so it will probably stay ld64. Does anyone have it in hardware? Wikipedia doesn't mention either arm or mips under where I found this for powerpc (Quadruple precision floating- point format). Searching for it for arm gives wikipedia at the top again. It says that arm v8-A has 32x 128-bit SIMD registers and supports double precision floating point. Intel didn't bother with it for 256-bit AVX registers. gcc has some support for it in software on x86. It was silly on old sparc too. Unfortunately, some APIs encourage use of long double, so when it is excessively wide these are slow. Bruce From owner-freebsd-numerics@FreeBSD.ORG Sun Nov 10 18:15:42 2013 Return-Path: Delivered-To: freebsd-numerics@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DABA0B97; Sun, 10 Nov 2013 18:15:42 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9E8C328C1; Sun, 10 Nov 2013 18:15:42 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id rAAIFf3K083686; Sun, 10 Nov 2013 10:15:41 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id rAAIFfxk083685; Sun, 10 Nov 2013 10:15:41 -0800 (PST) (envelope-from sgk) Date: Sun, 10 Nov 2013 10:15:41 -0800 From: Steve Kargl To: David Chisnall Subject: Re: MUSL math functions Message-ID: <20131110181541.GA83590@troutmask.apl.washington.edu> References: <20131031133352.GA59918@troutmask.apl.washington.edu> <20131101072032.P1002@besplex.bde.org> <20131108085039.GA1821@zim.MIT.EDU> <15792BD0-C47C-4DCA-A112-D3C54F211E67@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15792BD0-C47C-4DCA-A112-D3C54F211E67@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: David Schultz , "freebsd-numerics@FreeBSD.org" , Bruce Evans X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 18:15:42 -0000 On Sun, Nov 10, 2013 at 10:05:18AM +0000, David Chisnall wrote: > On 8 Nov 2013, at 08:50, David Schultz wrote: > > > However, several things have happened since then. For one, years > > have passed and there's still quite a bit of work to do. For two, > > the only ld128 platform, sparc64, doesn't look as important as it > > used to be. For a long time, we had trouble even finding a viable > > test machine. Therefore, I think any incremental improvement would > > be welcome -- even if it means doing ld80 only. > > The PowerPC SysV ABI says that it's ld128 The use of ld128 in msun means the IEEE 128-bit binary format with a 113-bit significand. With (at least 32-bit) powerpc, long double is represented by a double-double format with a 106-bit significand. msun has no support for a double-double format. -- Steve From owner-freebsd-numerics@FreeBSD.ORG Mon Nov 11 11:06:53 2013 Return-Path: Delivered-To: freebsd-numerics@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9B5B3997 for ; Mon, 11 Nov 2013 11:06:53 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8822E2CC0 for ; Mon, 11 Nov 2013 11:06:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rABB6rTx082157 for ; Mon, 11 Nov 2013 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rABB6rWa082151 for freebsd-numerics@FreeBSD.org; Mon, 11 Nov 2013 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 11 Nov 2013 11:06:53 GMT Message-Id: <201311111106.rABB6rWa082151@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-numerics@FreeBSD.org Subject: Current problem reports assigned to freebsd-numerics@FreeBSD.org X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 11:06:53 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o stand/175811 numerics libstdc++ needs complex support in order use C99 o bin/170206 numerics [msun] [patch] complex arcsinh, log, etc. o stand/82654 numerics C99 long double math functions are missing 3 problems total. From owner-freebsd-numerics@FreeBSD.ORG Tue Nov 12 05:20:48 2013 Return-Path: Delivered-To: freebsd-numerics@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EDDE18B8; Tue, 12 Nov 2013 05:20:48 +0000 (UTC) Received: from zim.MIT.EDU (poofydog.net [198.0.194.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C2C283FD1; Tue, 12 Nov 2013 05:20:48 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.7/8.14.7) with ESMTP id rAB2mcDD015182; Sun, 10 Nov 2013 18:48:38 -0800 (PST) (envelope-from das@freebsd.org) Received: (from das@localhost) by zim.MIT.EDU (8.14.7/8.14.7/Submit) id rAB2lrh7015172; Sun, 10 Nov 2013 18:47:53 -0800 (PST) (envelope-from das@freebsd.org) Date: Sun, 10 Nov 2013 18:47:53 -0800 From: David Schultz To: Bruce Evans Subject: Re: MUSL math functions Message-ID: <20131111024753.GA15115@zim.MIT.EDU> References: <20131031133352.GA59918@troutmask.apl.washington.edu> <20131101072032.P1002@besplex.bde.org> <20131108085039.GA1821@zim.MIT.EDU> <15792BD0-C47C-4DCA-A112-D3C54F211E67@FreeBSD.org> <20131111040050.D29424@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131111040050.D29424@besplex.bde.org> Cc: "freebsd-numerics@FreeBSD.org" , David Chisnall , Steve Kargl X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 05:20:49 -0000 On Mon, Nov 11, 2013, Bruce Evans wrote: > On Sun, 10 Nov 2013, David Chisnall wrote: > > MIPS is also ld128 on most systems, but the fact that there is no 128-bit floating point hardware for MIPS (except in one ASE, where there is one 128-bit floating point accumulator register) makes this quite a silly choice, so it will probably stay ld64. > > Does anyone have it in hardware? Not as far as I know. The format is fairly impractical, for three reasons: 1. Lack of hardware support means it's slow. 2. Given that it's already slow, those who need the extra precision would probably prefer to just use an arbitrary-precision library. 3. People who don't know any better frequently use 'long double' in their code, even when double would suffice. This is okay on x86, but their programs run exceptionally slowly on platforms that use the ld128 format.