From owner-freebsd-current@FreeBSD.ORG Fri Aug 5 07:49:21 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4122F16A41F for ; Fri, 5 Aug 2005 07:49:21 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 599B943D46 for ; Fri, 5 Aug 2005 07:49:20 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail14.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j757nHrW029812 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 5 Aug 2005 17:49:18 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id j757nHSR003461; Fri, 5 Aug 2005 17:49:17 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j757nHpL003460; Fri, 5 Aug 2005 17:49:17 +1000 (EST) (envelope-from pjeremy) Date: Fri, 5 Aug 2005 17:49:16 +1000 From: Peter Jeremy To: Steve Kargl Message-ID: <20050805074916.GD2104@cirb503493.alcatel.com.au> References: <20050804162618.GA96657@troutmask.apl.washington.edu> <20050804191547.GB2104@cirb503493.alcatel.com.au> <20050804193030.GA97987@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050804193030.GA97987@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.2i Cc: freebsd-current@freebsd.org Subject: Re: Number of significand bits in long double? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2005 07:49:21 -0000 On Thu, 2005-Aug-04 12:30:30 -0700, Steve Kargl wrote: >fpsetprec is deprecated. In addition, one finds "... fpsetprec() >functions provide functionality unavailable on many platforms. At >present, they are implemented only on the i386 and amd64 platforms". So I see. I didn't read the man page in detail, I just tracked down a function that could change the precision. fpsetprec() refers to fenv(3) but that doesn't appear to (publicly) include provision for changing precision. On the i386 and amd64, you could fiddle with the control word in fenv_t but that's not portable either. AFAIK, only i386 (and presumably amd64) support the sort of default rounding that fpsetprec() fiddles with. Therefore it doesn't really make sense to implement them elsewhere. The underlying instruction is fldcw. By default, FreeBSD initialises the FPU using __INITIAL_NPXCW__ (defined in /sys/i386/include/npx.h). Long double on various FreeBSD architectures is: Alpha: 53 bits (no hardware long double) ARM: 53 bits (not sure if ARM supports anything else) amd64: 64 bits (can be restricted to 24 or 53 bits) i386: 64 bits (can be restricted to 24 or 53 bits) iA64: 64 bits PPC: 53 bits (though I believe the h/w supports 106 or 112 bits) SPARC: 113 bits You are going to need to implement at least two different sets of long double math routines (since the polynomial expansions will be be different for 64 and 113 bits). I don't see the problem with adding machine-dependent fldcw/fstcw calls on the i386 code. >> See the LDBL_* macros in for native precision. > >That's the problem. The LDBL* macros misrepresent the >actual precision used. I had a closer look. In 4.x, LDBL_* just points to DBL_*. imp@ changed it to reflect the native hardware precision in v1.9. IMHO, it would be nice to run the i386 in native precision but that opens up a can of worms (since expressions will wind up being evaluated in different precisions depending on whether the compiler needs to spill registers onto the stack and whether temporary variables are registers or stack). You probably need to have a chat to bde@ -- Peter Jeremy