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> <2025Feb3.075550@mips.complang.tuwien.ac.at> <0fc4cc997441e25330ff5c8735247b54@www.novabbs.org> <74142fbdc017bc560d75541f3f3c5118@www.novabbs.org> <20250218150739.0000192a@yahoo.com> <0357b097bbbf6b87de9bc91dd16757e3@www.novabbs.org> 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