On Wed, May 03, 2023 at 10:41:42AM +0100, Richard Henderson wrote: > On 5/3/23 10:14, Stafford Horne wrote: > > > > + set_default_nan_mode(1, &cpu->env.fp_status); > > > > + set_float_detect_tininess(float_tininess_before_rounding, > > > > + &cpu->env.fp_status); > > > > > > You don't mention the nan change in the commit message. > > > > Right, and I am not sure I need it. Let me remove it and run tests again. > > I > > was just adding it as a few other architectures did who set > > float_tininess_before_rounding. > > What that does is *not* propagate NaN payloads from (some) input to the > output. This is certainly true of RISC-V, which specifies this in their > architecture manual. OpenRISC does not specify any NaN behaviour at all.
Thanks, that is what I also gathered from reading up on it. > It's not a bad choice, really, and it almost certainly simplifies the design > of the FPU, as you can do NaN propagation and silencing in one step. Right, it makes sense to optimize. It doesn't look like any of our FPU implementation do that at the moment. I will check with bandvig who implemented the FPU to understand his thought on this. It at least deserves to be discussed how nan payload is to be handled in the architecture spec. -Stafford
