Re: [Qemu-devel] [PATCH 7/9] asn1_input-visitor.diff

[Stefan Berger <stefanb@linux.vnet.ibm.com>]

On 03/13/2013 09:22 PM, Joel Schopp wrote:
>
>>>> +    case 0x41:
>>>> +    case 0x40:
>>>> +        num.mpn.sign = ((number.first & 0x1) != 0);
>>>> +        num.mpn.biased_exponent = ~0;
>>>> +        num.mpn.mantissa_low = 0;
>>>> +        num.mpn.mantissa_high = 0;
>>>> +        *obj = num.v_double;
>>> Is this really portable enough?  In other words, do we really require
>>> that qemu only compiles on platforms where double is in IEEE format?
>>>
>> Good question. I don't know in what format the other platforms are,
>> though. I know it's used on i386, x86_64, ppc, ppc64. My guess is that
>> it would have to be a really exotic CPU to not use this standard.
>>
>> I hope this applies to ARM in general...
>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0067d/Cihgejjg.html 
>>
>>
>
> There are chips without hardware floating point, for example the ppc 
> 404.  However, these use software emulation of IEE floating point when 
> doing floating point math.  What we are looking for is a platform that 
> has floating point that isn't IEEE.
>
> Cell SPE comes to mind, though I don't think qemu emulates it and it 
> is a dead architecture (RIP).  It also has an IEEE mode that makes its 
> non-standard floating point compliant.  Even in non-compliant mode the 
> code above would work, it's more rounding that might be off.
>
> In summary I can't think of a platform we run on or emulate that has a 
> floating point mode the above would not work on.  If somebody can 
> think of one please let me know so we can #ifdef a special case for 
> it. Otherwise let's assume the above works for all the platforms we 
> care about.

One other choice could be string-encoding as also suggested by the 
standard with possible loss of precision. Though I think that any exotic 
processor could be dealt with a #ifdef around the code pressing its 
format into 2 bytes of exponent and 8 bytes of mantissa.

    Stefan