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.
