qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 4/4] target-m68k: add fscale, fgetman and fgetex


From: Laurent Vivier
Subject: Re: [Qemu-devel] [PATCH 4/4] target-m68k: add fscale, fgetman and fgetexp
Date: Mon, 3 Jul 2017 21:50:26 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0

Le 03/07/2017 à 21:26, Richard Henderson a écrit :
> On 07/03/2017 09:23 AM, Laurent Vivier wrote:
>> +void HELPER(fgetman)(CPUM68KState *env, FPReg *res, FPReg *val)
>> +{
>> +    if (floatx80_is_infinity(val->d)) {
>> +        res->d = floatx80_default_nan(NULL);
>> +        /* FIXME: set the OPERR bit int he FPSR */
>> +        return;
>> +    }
>> +    if (floatx80_is_zero(val->d) ||
>> +        floatx80_is_any_nan(val->d)) {
>> +        *res = *val;
>> +        return;
>> +    }
>> +
>> +    res->l.upper = (val->l.upper & 0x8000) | 0x3fff;
>> +    if (floatx80_is_zero_or_denormal(val->d)) {
>> +        res->l.lower = val->l.lower << 1;
> 
> Surely you have to do more than this for denormals?  There may be more
> than one leading zero bit in the mant.  Do you actually need to
> re-normalize?  Or does real hardware produce a so-called "unnormal" in
> this situation?

I don't know. Do you have test values I can try on real hardware to know?

I've tried:

                fmove.x #0x000056789ABCDEF12345,%fp0
                fgetman.x %fp0,%fp6

fp0            1.135643728339893804160017756766172e-4932        (raw
0x0000000056789abcdef12345)
fp6            1.3511111111108837373479679699883604     (raw
0x3fff0000acf13579bde2468a)

                fmove.x #0x000086789ABCDEF12345,%fp0
                fgetman.x %fp0,%fp6

fp0            1.7660380676734113365842698475140006e-4932       (raw
0x0000000086789abcdef12345)
fp6            1.0505555555554418686739839849941802     (raw
0x3fff000086789abcdef12345)

                fmove.x #0x000000000ABCDEF12345,%fp0
                fgetman.x %fp0,%fp6
fp0            2.1518178707571747286191852003521627e-4938       (raw
0x0000000000000abcdef12345)
fp6            1.342222103012886691431049257516861      (raw
0x3fff0000abcdef1234500000)

So I guess the mantissa must be shifted to left until we have a 1 in the
explicit integer part bit?

Thanks,
Laurent



reply via email to

[Prev in Thread] Current Thread [Next in Thread]