From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56149) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XJU73-00059p-Hu for qemu-devel@nongnu.org; Mon, 18 Aug 2014 17:05:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XJU70-0005bF-8C for qemu-devel@nongnu.org; Mon, 18 Aug 2014 17:05:09 -0400 Received: from mail-vc0-x22e.google.com ([2607:f8b0:400c:c03::22e]:52392) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XJU70-0005Zr-3G for qemu-devel@nongnu.org; Mon, 18 Aug 2014 17:05:06 -0400 Received: by mail-vc0-f174.google.com with SMTP id la4so6352254vcb.5 for ; Mon, 18 Aug 2014 14:05:05 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Gaurav Sharma Date: Tue, 19 Aug 2014 02:34:45 +0530 Message-ID: Content-Type: multipart/alternative; boundary=047d7b343a4ca20fd20500edb9db Subject: Re: [Qemu-devel] [ARM - FCVT inst] : Difference in calculated value List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU-DEVEL --047d7b343a4ca20fd20500edb9db Content-Type: text/plain; charset=UTF-8 Hi Peter, I cross checked it with a AFM model, and the results are indeed different. The problem I think lies in how we treat de-normalized numbers which are too small to represent in half precision. In case of qemu >> if(exp < -10) >> return signed/unsigned zero. However, in case rounding is set, we ignore and we return zero. This may not be true and we may have a smallest possible denormalized number. Thanks, Gaurav On Sun, Aug 17, 2014 at 1:14 AM, Peter Maydell wrote: > On 16 August 2014 20:06, Gaurav Sharma wrote: > > Can some one confirm is this is an issue with qemu implementation ? > > It's on my todo list to look at. If you want to confirm it as a QEMU > bug your best bet is to write a short test program and compare > the output on QEMU against running it on real hardware. > > -- PMM > --047d7b343a4ca20fd20500edb9db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Peter,
I cross checked it with a AFM model, and the= results are indeed different.
The problem I think lies in how we= treat de-normalized numbers which are too small to represent in half preci= sion.
In case of qemu=C2=A0
>> if(exp < -10)=C2=A0
<= div>>> return signed/unsigned zero.
However, in case roundi= ng is set, we ignore and we return zero. This may not be true and we may ha= ve a smallest possible denormalized number.

Thanks,
Gaurav


On Sun, Aug 17, 2014 at 1:14 AM,= Peter Maydell <peter.maydell@linaro.org> wrote:
On 16 August 2014 20:06, Gau= rav Sharma <gauravs.2010@gmail= .com> wrote:
> Can some one confirm is this is an issue with qemu implementation ?
It's on my todo list to look at. If you want to confirm it as a Q= EMU
bug your best bet is to write a short test program and compare
the output on QEMU against running it on real hardware.

-- PMM

--047d7b343a4ca20fd20500edb9db--