aboutsummaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorJoseph Myers <joseph@codesourcery.com>2020-06-11 23:45:48 +0000
committerPaolo Bonzini <pbonzini@redhat.com>2020-06-26 09:39:37 -0400
commiteca30647fc078f4d9ed1b455bd67960f99dbeb7a (patch)
tree5294a8dd65cd8ef57a7f548e3f126dba936a797b /include
parentb00de3a51fc8e86d1678c57e65d57aa9ed052422 (diff)
downloadqemu-eca30647fc078f4d9ed1b455bd67960f99dbeb7a.zip
qemu-eca30647fc078f4d9ed1b455bd67960f99dbeb7a.tar.gz
qemu-eca30647fc078f4d9ed1b455bd67960f99dbeb7a.tar.bz2
target/i386: reimplement f2xm1 using floatx80 operations
The x87 f2xm1 emulation is currently based around conversion to double. This is inherently unsuitable for a good emulation of any floatx80 operation, even before considering that it is a particularly naive implementation using double (computing with pow and then subtracting 1 rather than attempting a better emulation using expm1). Reimplement using the soft-float operations, including additions and multiplications with higher precision where appropriate to limit accumulation of errors. I considered reusing some of the m68k code for transcendental operations, but the instructions don't generally correspond exactly to x87 operations (for example, m68k has 2^x and e^x - 1, but not 2^x - 1); to avoid possible accumulation of errors from applying multiple such operations each rounding to floatx80 precision, I wrote a direct implementation of 2^x - 1 instead. It would be possible in principle to make the implementation more efficient by doing the intermediate operations directly with significands, signs and exponents and not packing / unpacking floatx80 format for each operation, but that would make it significantly more complicated and it's not clear that's worthwhile; the m68k emulation doesn't try to do that. A test is included with many randomly generated inputs. The assumption of the test is that the result in round-to-nearest mode should always be one of the two closest floating-point numbers to the mathematical value of 2^x - 1; the implementation aims to do somewhat better than that (about 70 correct bits before rounding). I haven't investigated how accurate hardware is. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Message-Id: <alpine.DEB.2.21.2006112341010.18393@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions