From: robfi680@gmail.com   
      
   On 2025-11-22 11:36 p.m., Robert Finch wrote:   
   > On 2025-11-22 11:16 p.m., Robert Finch wrote:   
   >> On 2025-11-22 10:20 p.m., MitchAlsup wrote:   
   >>>   
   >>> Robert Finch  posted:   
   >>>   
   >>>> 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.   
   >>>   
   >>> Suggest you read::   
   >>> https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/   
   >>> background/ nan-propagation.pdf   
   >>> For conversation about LoBs versus HoBs.   
   >>>   
   >>   
   >> Okay, it sounds like there are good reasons to use the HoBs. But I   
   >> think it is only when converting precisions that it makes a   
   >> difference. I have the float package moving the LoBs of a larger   
   >> precision to the LoBs of the lower precision if a NaN (or infinity) is   
   >> present. I do not think this consumes any more logic. It looks like   
   >> just wires. It looks to be a three bit mux on the low order bits going   
   >> the other way.   
   >>   
   >> I suppose I could code the package to accept NaN values either way.   
   >>   
   >> The following NaN values are in use.   
   >>   
   >> `define    QSUBINFD     63'h7FF0000000000001    // - infinity -   
   infinity   
   >> `define QINFDIVD     63'h7FF0000000000002    // - infinity / infinity   
   >> `define QZEROZEROD  63'h7FF0000000000003    // - zero / zero   
   >> `define QINFZEROD    63'h7FF0000000000004    // - infinity X zero   
   >> `define QSQRTINFD    63'h7FF0000000000005    // - square root of   
   infinity   
   >> `define QSQRTNEGD    63'h7FF0000000000006    // - square root of   
   >> negaitve number   
   >>   
   >>   
   > When converting a NaN from higher to lower precision, the float package   
   > preserves both the low order four bits and as many high order bits of   
   > the NaN that will fit. The middle bits are dropped.   
   >   
   >>>>> 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.   
   >>>>   
   >>   
   >   
   Added a NaN tracing facility as an core option. It can only log two NaNs   
   per clock to a buffer, possibly slowing the core down. The NaN addresses   
   are logged in order to a 512 entry buffer. The core already tracks   
   exceptions so it was not too bad to add a NaN flag to the re-order buffer.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)