Path: ...!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: Tue, 18 Feb 2025 22:33:41 +0000
Organization: Rocksolid Light
Message-ID: <a34ce3b43fab761d13b2432f9e255fab@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="691374"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$TO8nHdbQacmgDQbuzPF.P.btCRq0yFqSobaGo4HCVxXRSKJg6S4PC
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
Bytes: 2538
Lines: 35

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.

> Terje