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: Thu, 20 Feb 2025 03:02:56 +0000
Organization: Rocksolid Light
Message-ID: <2dc33514bc664e667173b132601e6ce0@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> <a56e446b2e2df9f01eb558aa68279d35@www.novabbs.org> <vp5mnu$2fjhi$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="874480"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$leKsLwQO1H6tPm1O/uu1t.0p.yAiQRYLwKtUzk6.rwdWGnL/AJQt2
Bytes: 3335
Lines: 53

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