[Qemu-devel] [ARM - FCVT inst] : Difference in calculated value

[Qemu-devel] [ARM - FCVT inst] : Difference in calculated value

[Gaurav Sharma]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

I am trying to execute a 'fcvt' instruction for conversion from single
precision to half precision value.
with the following values :

[Instrn]
fcvt h16 s25

[register values]
SIMD register [25] = 0x9EA82A22AB98FBA8L
FPCR = 0x40ae2f54 [with according mask removing the UFE and other
unnecessary bit]

As per the softfloat algorithm, if the exp is < -10, we return a signed /
unsigned zero. In this case 0x8000 is the value set in h16.

However,  when trying to match the same with arm implementation, the value
for h16 comes out as 0x8001.
While trying to map the softfloat implementation with arm manual, depending
upon rounding mode  it seems we can get both 0x8000 and 0x8001.

I am still in the process of checking the algorithm for conversion in
softfloat, but in the arm manual, i do not see we returning a zero.

Thanks,
Gaurav

[-- Attachment #2: Type: text/html, Size: 1128 bytes --]

Re: [Qemu-devel] [ARM - FCVT inst] : Difference in calculated value

[Gaurav Sharma]

[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]

Can some one confirm is this is an issue with qemu implementation ?

Thanks,
Gaurav


On Thu, Aug 14, 2014 at 1:07 PM, Gaurav Sharma <gauravs.2010@gmail.com>
wrote:

> I am trying to execute a 'fcvt' instruction for conversion from single
> precision to half precision value.
> with the following values :
>
> [Instrn]
> fcvt h16 s25
>
> [register values]
> SIMD register [25] = 0x9EA82A22AB98FBA8L
> FPCR = 0x40ae2f54 [with according mask removing the UFE and other
> unnecessary bit]
>
> As per the softfloat algorithm, if the exp is < -10, we return a signed /
> unsigned zero. In this case 0x8000 is the value set in h16.
>
> However,  when trying to match the same with arm implementation, the value
> for h16 comes out as 0x8001.
> While trying to map the softfloat implementation with arm manual,
> depending upon rounding mode  it seems we can get both 0x8000 and 0x8001.
>
> I am still in the process of checking the algorithm for conversion in
> softfloat, but in the arm manual, i do not see we returning a zero.
>
> Thanks,
> Gaurav
>
>
>

[-- Attachment #2: Type: text/html, Size: 1640 bytes --]

Re: [Qemu-devel] [ARM - FCVT inst] : Difference in calculated value

[Peter Maydell]

On 16 August 2014 20:06, Gaurav 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 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

Re: [Qemu-devel] [ARM - FCVT inst] : Difference in calculated value

[Gaurav Sharma]

[-- Attachment #1: Type: text/plain, Size: 861 bytes --]

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 <peter.maydell@linaro.org>
wrote:

> On 16 August 2014 20:06, Gaurav 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 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
>

[-- Attachment #2: Type: text/html, Size: 1393 bytes --]

Re: [Qemu-devel] [ARM - FCVT inst] : Difference in calculated value

[Peter Maydell]

On 18 August 2014 22:04, Gaurav Sharma <gauravs.2010@gmail.com> wrote:
> 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.

Cool. Can you provide your test case, then, please?

thanks
-- PMM

Re: [Qemu-devel] [ARM - FCVT inst] : Difference in calculated value

[Gaurav Sharma]

[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]

I am running a simple bare metal program with only the above specified
instruction

[Instrn]
fcvt h16 s25

[register values]
SIMD register [25] = 0x9EA82A22AB98FBA8L
FPCR = 0x40ae2f54 [with according mask removing the UFE and other
unnecessary bit]

The FPCR will set the rounding mode to negative infinity.

Thanks,
Gaurav


On Tue, Aug 19, 2014 at 2:42 AM, Peter Maydell <peter.maydell@linaro.org>
wrote:

> On 18 August 2014 22:04, Gaurav Sharma <gauravs.2010@gmail.com> wrote:
> > 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.
>
> Cool. Can you provide your test case, then, please?
>
> thanks
> -- PMM
>

[-- Attachment #2: Type: text/html, Size: 1555 bytes --]

Re: [Qemu-devel] [ARM - FCVT inst] : Difference in calculated value

[Peter Maydell]

On 19 August 2014 13:39, Gaurav Sharma <gauravs.2010@gmail.com> wrote:
> I am running a simple bare metal program with only the above specified
> instruction
>
> [Instrn]
> fcvt h16 s25
>
> [register values]
> SIMD register [25] = 0x9EA82A22AB98FBA8L
> FPCR = 0x40ae2f54 [with according mask removing the UFE and other
> unnecessary bit]

Thanks. My test case produced from that:

===begin===
/* aarch64-linux-gnu-gcc -g -Wall -o fcvt fcvt.c -static */
#include <stdio.h>
#include <stdint.h>
#include <inttypes.h>

void do_fcvt(uint32_t fpcr, uint64_t a)
{
    uint64_t r;

    printf("a = 0x%016" PRIx64 " fpcr = 0x%08x\n", a, fpcr);

    __asm__ volatile(
        "fmov d25, %[a]\n"
        "mrs x3, FPCR\n"
        "msr FPCR, %[fpcr]\n"
        "isb\n"
        "fcvt h16, s25\n"
        "msr FPCR, x3\n"
        "isb\n"
        "fmov %[r], d16\n"
        : [r] "=r" (r)
        : [a] "r" (a),
          [fpcr] "r" (fpcr)
        : "d16", "d25", "x3"
        );

    printf("result = 0x%016" PRIx64 "\n", r);
}

int main(void)
{
    do_fcvt(0x40ae2f54 & 0x07f70000, 0x9EA82A22AB98FBA8ull);

    return 0;
}
===endit===

which on a Fast Model produces:
root@genericarmv8:~# ./fcvt
a = 0x9ea82a22ab98fba8 fpcr = 0x00a60000
result = 0x0000000000008001

and on QEMU:
e104462:trusty:qemu$ ./build/x86/aarch64-linux-user/qemu-aarch64 /tmp/fcvt
a = 0x9ea82a22ab98fba8 fpcr = 0x40ae2f54
result = 0x0000000000008000

so we are indeed getting the rounding wrong here.

thanks
-- PMM

Re: [Qemu-devel] [ARM - FCVT inst] : Difference in calculated value

[Gaurav Sharma]

[-- Attachment #1: Type: text/plain, Size: 1970 bytes --]

Great !!
As per my understanding this is because for minimum denormalized numbers we
are ignoring the rounding value and returning the denormalized value which
is rounded to zero.
Will have to check the behavior in case of single and double precision
value functions also.

Thanks,
Gaurav


On Fri, Aug 22, 2014 at 7:58 PM, Peter Maydell <peter.maydell@linaro.org>
wrote:

> On 19 August 2014 13:39, Gaurav Sharma <gauravs.2010@gmail.com> wrote:
> > I am running a simple bare metal program with only the above specified
> > instruction
> >
> > [Instrn]
> > fcvt h16 s25
> >
> > [register values]
> > SIMD register [25] = 0x9EA82A22AB98FBA8L
> > FPCR = 0x40ae2f54 [with according mask removing the UFE and other
> > unnecessary bit]
>
> Thanks. My test case produced from that:
>
> ===begin===
> /* aarch64-linux-gnu-gcc -g -Wall -o fcvt fcvt.c -static */
> #include <stdio.h>
> #include <stdint.h>
> #include <inttypes.h>
>
> void do_fcvt(uint32_t fpcr, uint64_t a)
> {
>     uint64_t r;
>
>     printf("a = 0x%016" PRIx64 " fpcr = 0x%08x\n", a, fpcr);
>
>     __asm__ volatile(
>         "fmov d25, %[a]\n"
>         "mrs x3, FPCR\n"
>         "msr FPCR, %[fpcr]\n"
>         "isb\n"
>         "fcvt h16, s25\n"
>         "msr FPCR, x3\n"
>         "isb\n"
>         "fmov %[r], d16\n"
>         : [r] "=r" (r)
>         : [a] "r" (a),
>           [fpcr] "r" (fpcr)
>         : "d16", "d25", "x3"
>         );
>
>     printf("result = 0x%016" PRIx64 "\n", r);
> }
>
> int main(void)
> {
>     do_fcvt(0x40ae2f54 & 0x07f70000, 0x9EA82A22AB98FBA8ull);
>
>     return 0;
> }
> ===endit===
>
> which on a Fast Model produces:
> root@genericarmv8:~# ./fcvt
> a = 0x9ea82a22ab98fba8 fpcr = 0x00a60000
> result = 0x0000000000008001
>
> and on QEMU:
> e104462:trusty:qemu$ ./build/x86/aarch64-linux-user/qemu-aarch64 /tmp/fcvt
> a = 0x9ea82a22ab98fba8 fpcr = 0x40ae2f54
> result = 0x0000000000008000
>
> so we are indeed getting the rounding wrong here.
>
> thanks
> -- PMM
>

[-- Attachment #2: Type: text/html, Size: 2913 bytes --]