On 2017-07-21 10:32, Alex Bennée wrote: > > Richard Henderson <r...@twiddle.net> writes: > > > On 07/20/2017 05:04 AM, Alex Bennée wrote: > >> +# so they can still be linked when needed. We build these files > >> surpressing so of the normal CFLAGS. > > > > "surpressing so" -> "suppressing some" > > > > Do we gain any confidence for our still supported but less tested > > 32-bit hosts (all of which do support a 64-bit type) by dropping the > > FAST_INT64 distinction? > > I guess so. Certainly I can cross-compile aarch64-softmmu on armhf > defining all the: > > softfloat3_fastint64="yes" > softfloat3_fastdiv32to16="yes" > softfloat3_fastdiv64to32="yes" > > without any issue. I guess it might mean our 32 bit guests might run > slightly slower but none of our FP is fast anyway. > > There is also a slight intermingling in the build setup between the > FASTINT64 and the specialisation even though there are for different > things. > > The 8086 code basically makes NaN propagation match old x86 whereas SSE > is the more recent and more IEEE like SSE behaviour. See section 5 of: > > http://www.jhauser.us/arithmetic/SoftFloat-3c/doc/SoftFloat-source.html > > I suspect what we should have here are specialisation for each of our > guests. We do something similar in the softfloat2a code in it's > specialise header. Maybe we should rename 8086-SSE to default and then > create a specialisation for each guest that needs it?
For the sNaN is 0 or 1 specialisation we actually need to be able to select this at runtime, as we have implemented it in the QEMU softfloat version. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
