Re: Cost of handling misaligned access

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

MitchAlsup1 wrote:

On Tue, 18 Feb 2025 21:09:54 +0000, Terje Mathisen wrote:
>

MitchAlsup1 wrote:

On Tue, 18 Feb 2025 13:07:39 +0000, Michael S wrote:
>

On Tue, 18 Feb 2025 02:55:33 +0000
mitchalsup@aol.com (MitchAlsup1) wrote:

>
It takes Round Nearest Odd to perform Kahan-Babashuka Summation.
>

>
Are you aware of any widespread hardware that supplies Round to Nearest
with tie broken to Odd? Or of any widespread language that can request
such rounding mode?

>
No, No
>

Until both, implementing RNO on niche HW looks to me as wastage of both
HW resources and of space in your datasheet.

>
They way I implement it, it is only an additional 10± gates.

>
With discrete logic, it should be identical to RNE, except for flipping
the ulp bit when deciding upon the rounding direction, right?

>
Yes,
>

With a full 4-bit lookup table you need a few more gates, but that is
still the obvious way to implement rounding in SW. (It is only ceil()
and floor() that requires the sign bit as input, the remaining rounding
modes can make do with ulp+guard+sticky.

>
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"

Terje