On 29 November 2010 19:54, Nathan Froyd <froy...@codesourcery.com> wrote: > On Mon, Nov 29, 2010 at 07:25:18PM +0000, Peter Maydell wrote: >> (b) add to and extend the softfloat API whenever you have some >> floating-point related thing it doesn't currently support > > I think this is the best approach whenever possible. I would not be too > worried about the third-party-ness of softfloat; it's extremely stable, > unlikely to change anytime in the near or far future, and we've already > extended in it non-trivial ways anyway.
OK. Do we care about maintaining consistency of the API between softfloat and softfloat-native (the latter used only on x86, x86_64, cris, sh4, sh4eb)? I didn't in these patchsets because there didn't seem any point adding functions to softfloat-native that weren't going to be used by anything and so couldn't be tested. >> (c) do something suboptimal where the softfloat API provides >> some-API-but-not-quite-the-ideal-API (which I'm not particularly >> keen on and is what I see the "is_nan() || is_signalling_nan()" >> approach as) > > Yes, this is ugly. Are you up for running: > > perl -p -i -e 's/float(\d+)_is_nan/float\1_is_quiet_nan/g' target-*/*.c > > (and also carefully in fpu/*) or similar and moving the bit-twiddling > float_is_nan into fpu/? I'm happy to produce a patch doing that if it will be committed :-) -- PMM
