|
From: | Stefan Berger |
Subject: | Re: [Qemu-devel] [PATCH 7/9] asn1_input-visitor.diff |
Date: | Wed, 13 Mar 2013 21:53:03 -0400 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 |
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.htmlThere 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
[Prev in Thread] | Current Thread | [Next in Thread] |