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