Re: Cost of handling misaligned access

On Wed, 19 Feb 2025 22:42:04 +0000, BGB wrote:

On 2/19/2025 11:31 AM, MitchAlsup1 wrote:

On Wed, 19 Feb 2025 16:35:41 +0000, Terje Mathisen wrote:
>

------------------

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?...

Based on how IEEE 754 wo9rked throughout its history::
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.
----------------

>
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 to a constant
     Con: it can't compare floating point
----------------

Where, detecting all zeroes is at least cheaper than a subtract. But,
detecting all zeroes still isn't free (for 64b, ~ 10 LUTs and 3 LUTs
delay).

1 gate   4-inputs inverted
2 gates 16-inputs true
3-gates 64-inputs inverted