From: robfi680@gmail.com
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.
>>>
>
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
