On Sun, Jan 02, 2011 at 03:35:30PM +0000, Peter Maydell wrote: > On 2 January 2011 15:05, Aurelien Jarno <aurel...@aurel32.net> wrote: > > On Sun, Jan 02, 2011 at 02:04:11PM +0000, Peter Maydell wrote: > >> Could we have a target-specific "silence this SNaN" function? > > > > You mean a target-specific version of floatXX_maybe_silence_nan()? > > Actually what I had in mind was a target-specific floatXX_silence_snan() > which would be called from the propagateFloatXX_NaN() > and floatXX_maybe_silence_nan() functions. But now you mention > it, just allowing the target to override floatXX_maybe_silence_nan() > (and calling it in propagateFloatXX_NaN()) looks like the better thing. > > > At least having a default version (for !SNAN_BIT_IS_ONE) and a version > > for MIPS, HPPA (which is btw not emulated), etc. > > Yes. (Incidentally, HPPA says the rule for "silence this NaN" is: > * set the first bit of the significand to 0 > * set the second bit of the significand to 1 (implementations can do > this (a) always or (b) only if all the other bits of the significand are 0) > Of course we don't need to actually implement this since > as you say we don't have an HPPA target, but it does suggest > that "silencing rules are target-specific" is the right approach.) > > >> Then the top level functions could use those rather than doing > >> their own bit-flipping, and I think that would do the right thing > >> for MIPS (you'd implement silence-NaN as "return the default > >> QNaN", and you implement pickNaN() to return the SNaN.) > > > > It seems, it would be the good way to do it. I am going to do a quick > > hack to see if this solution can work and if it is the case (it seems > > to be), apply your patch. > > Cool. >
I confirm this solution works. I have applied your patches, I'll send a patch series to implement correct propagation on MIPS later this week. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net