From: kegs@provalid.com   
      
   In article <1763868010-5857@newsgrouper.org>,   
   MitchAlsup   wrote:   
   >   
   >Robert Finch  posted:   
   >> My float package puts the cause in the 3 LoBs. The cause is always in   
   >> the low order bits of the register then, even when the precision is   
   >> different. But the address is not tracked. The package does not have   
   >> access to the address. Seems like NaN trace hardware might be useful.   
   >   
   >Suggest you read::   
   >https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/back   
   round/nan-propagation.pdf   
   >For conversation about LoBs versus HoBs.   
      
   I wasn't sure where to join the NaN conversation, but this seems like a   
   good spot.   
      
   We've had 40+ years of different architectures handling NaNs, (what to   
   encode in them to indicate where the first problem occurred) and all   
   architectures do something different when operating on two NaNs:   
      
   From that paper:   
   - Intel using x87 instructions: NaN2 if both quiet, NaN1 if NaN2 is signalling   
   - Intel using SSE instructions: NaN1   
   - AMD using x87 instructions: NaN2   
   - AMD using SSE instructions: NaN1   
   - IBM Power PC: NaN1   
   - IBM Z mainframe: NaN1 if both quiet, [precedence] to signalling NaN   
   - ARM: NaN1 if both quiet, [precedence] to signalling NaN   
      
   And adding one more not in that paper:   
   - RISC-V: Always returns canonical NaN only, for Single: 0x7fc00000   
      
   I'll just say whatever your NaN handling is, for the source code:   
      
   	A = B + C + D + E   
      
   then for whatever values B,C,D,E having NaN or not, the value of A should   
   be well defined and not dependent on the order of operations.  How can you   
   use bits in the NaN value for debugging if the hardware is returning arbitrary   
   results when NaNs collide?  Users have almost no control over whether   
   A = B + C treats B as the first argument or the second.   
      
   I think encoding stuff in NaN is a very 80's idea:  turning on exceptions   
   costs performance, so we want to debug after-the-fact using NaNs.   
      
   But I think RISC-V has the right modern idea: make hardware fast so you can   
   simply always enable Invalid Operation Traps (and maybe Overflow, if   
   infinities are happening), and then stop right at the point of NaN being   
   first created.  So the NaN propagation doesn't matter.   
      
   I think the common current debug strategy for NaNs is run at full speed   
   with exceptions masked, and if you get NaNs in your answer, you re-run   
   with exceptions on and then debug the traps that occur.  And no one looks at   
   the NaN values at all, just their presence.   
      
   So rather than spending time on NaN encoding, make it so that FP performance   
   is not affected by enabling exceptions, so we can skip the re-running step,   
   and just run with Invalid Operations trapping enabled.  And then just   
   return canonical NaNs.   
      
   Kent   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)