Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Cost of handling misaligned access
Date: Wed, 19 Feb 2025 17:31:08 +0000
Organization: Rocksolid Light
Message-ID: <a56e446b2e2df9f01eb558aa68279d35@www.novabbs.org>
References: <5lNnP.1313925$2xE6.991023@fx18.iad> <vnosj6$t5o0$1@dont-email.me> <2025Feb3.075550@mips.complang.tuwien.ac.at> <volg1m$31ca1$1@dont-email.me> <voobnc$3l2dl$1@dont-email.me> <0fc4cc997441e25330ff5c8735247b54@www.novabbs.org> <vp0m3f$1cth6$1@dont-email.me> <74142fbdc017bc560d75541f3f3c5118@www.novabbs.org> <20250218150739.0000192a@yahoo.com> <0357b097bbbf6b87de9bc91dd16757e3@www.novabbs.org> <vp2sv2$1skve$1@dont-email.me> <a34ce3b43fab761d13b2432f9e255fab@www.novabbs.org> <vp518t$2bhib$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="813043"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
X-Rslight-Site: $2y$10$C.07S/8XUCl9vteX//8AEuDnjwZdYKgC6QodS/wuDPkBqC3F0AmAS

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