From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33599) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WER9u-0001kd-P2 for qemu-devel@nongnu.org; Fri, 14 Feb 2014 17:23:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WER9o-0006m0-Oa for qemu-devel@nongnu.org; Fri, 14 Feb 2014 17:22:58 -0500 Message-ID: <52FE970F.6020104@gmail.com> Date: Fri, 14 Feb 2014 16:22:07 -0600 From: Tom Musta MIME-Version: 1.0 References: <52FA5A65.5080004@gmail.com> <767F99CE-BBF8-4682-969C-CE77389024AF@suse.de> <52FE8928.300@twiddle.net> In-Reply-To: <52FE8928.300@twiddle.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-ppc] PowerPC Decimal Floating Point List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson , Alexander Graf Cc: Peter Maydell , "qemu-ppc@nongnu.org" , QEMU Developers On 2/14/2014 3:22 PM, Richard Henderson wrote: > On 02/11/2014 11:38 PM, Alexander Graf wrote: >>>> My proposal is to incorporate the libdecnumber component of libdfp >>>> (http://www.eglibc.org/cgi-bin/viewvc.cgi/libdfp/trunk/) in a manner analogous to how >>>> softfloat is used for binary floating point. So, for example, the helper for the dadd >>>> instruction would look something like the following: >>>> >>>> - map FPSCR state to a decContext. >>>> - convert the contents of the source FPRs to decNumbers (decimal64ToNumber). >>>> - call decNumberAdd >>>> - convert the resultant decNumber to DPD (decimal64FromNumber) >>>> - update FPSCR per the decContext.status and result. >>>> >>>> Comments? >> I think that approach makes a lot of sense, but let's ask Richard and Peter as well. > > Reasonable, as far as the implementation details go. > > I am a teeny bit concerned which version of libdecnumber is considered most > "upstream". Ordinarily I'd point to the copy in gcc, but that is of course > GPLv3 + GCC runtime exception. I see the version from eglibc you quote above > is LGPLv2.1. I also see that the last change is 18 months old. On the other > hand, there is only one non-autoconf change in the gcc sources in the same period. > > The original import is from IBM sources. Is there somewhere "upstream" at IBM > that we ought to be importing from instead? > Richard: I will check with folks inside of IBM here that I have the latest and greatest. FWIW ... I have about 20 instructions prototyped and running in a test harness (not QEMU) and comparing results against actual P7/P8 hardware. So far, this looks pretty good. I haven't yet worked through any details of importing the library into QEMU.