From: robfi680@gmail.com   
      
   On 2025-11-11 2:30 p.m., MitchAlsup wrote:   
   >   
   > Robert Finch  posted:   
   >   
   >> Typical process for NaN boxing is to set the high order bits of the   
   >> value which causes the value to appear to be a NaN at higher precision.   
   >   
   > Any FP value representable in lower precision can be exactly represented   
   > in higher precision.   
   >   
   >> I have been thinking about using some of the high order bits of the NaN   
   >> (eg bits 32 to 51) to indicate the precision of the boxed value.   
   >   
   > When My 66000 generates a NaN it inserts the cause in the 3 HoBs and   
   > inserts IP in the LoBs. Nothing prevents you from overwriting the NaN,   
   > but I thought it was best to point at the causing-instruction and an   
   > encoded "why" the nan was generated. The cause is a 3-bit index to the   
   > 7 defined IEEE exceptions.   
   >   
   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.   
      
   > There are rules when more than 1 NaN are an operand to an instruction   
   > designed to leave the more important NaN as the result. {Where more   
   > important is generally the first to be generated.}   
   >   
   Hopefully the package follows the rules correctly. NaN operation is one   
   thing not tested yet.   
      
   >>                                                                   This   
   >> would allow detection of the use of a lower precision value in   
   >> arithmetic. Suppose a convert from single to double precision is being   
   >> done, but the value to be converted is only half precision. If it were   
   >> indicated by the NaN software might be able to fix the result.   
   >   
   > I think it is better to fix the SW that thinks a (half) is a (float).   
   >   
   It would be better, but some software is so complex it may be unknown   
   the values coming in. The SW does not really need to croak if its a   
   lower precision value as they are always represent-able in a higher   
   precision.>>   
        I also   
   >> preserve the sign bit of the number in the NaN box.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)