On 2/19/2025 11:31 AM, MitchAlsup1 wrote:------------------On Wed, 19 Feb 2025 16:35:41 +0000, Terje Mathisen wrote:
>
Based on how IEEE 754 wo9rked throughout its history::>>sign+ULP+Gard+sticky is all you ever need for any rounding mode>
IEEE or beyond.
That's what I believed all through the 2019 standards process and up to
a month or two ago:
>
In reality, the "NearestOrEven" rounding rule has an exception if/when
you need to round the largest possible fp number, with guard=1 and
sticky=0:
>
I.e. exactly halfway to the next possible value (which would be Inf)
>
In just this particular case, the OrEven part is skipped in favor of not
rounding up, so leaving a maximum/odd mantissa.
>
In the same case but sticky=1 we do round up to Inf.
>
This unfortunately means that the rounding circuit needs to be combined
with an exp+mant==0b111...111 input. :-(
You should rename that mode as "Round but stay finite"
>
So, does it overflow?...
If the calculation overflows without the need for rounding;
yes, it overflows. It is just that rounding all by itself does
not overflow that is different.
----------------
>Con: it can't compare to a constant
Admittedly part of why I have such mixed feelings on full
compare-and-branch:
Pro: It can offer a performance advantage (in terms of per-clock);
Con: Branch is now beholden to the latency of a Subtract.
Con: it can't compare floating point
----------------
Where, detecting all zeroes is at least cheaper than a subtract. But,1 gate 4-inputs inverted
detecting all zeroes still isn't free (for 64b, ~ 10 LUTs and 3 LUTs
delay).
2 gates 16-inputs true
3-gates 64-inputs inverted
Les messages affichés proviennent d'usenet.