Deutsch English Français Italiano |
<66018d28f03351d9429690cee311253e@www.novabbs.org> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: mitchalsup@aol.com (MitchAlsup1) Newsgroups: comp.arch Subject: Re: Making Lemonade (Floating-point format changes) Date: Wed, 22 May 2024 16:52:32 +0000 Organization: Rocksolid Light Message-ID: <66018d28f03351d9429690cee311253e@www.novabbs.org> References: <abe04jhkngt2uun1e7ict8vmf1fq8p7rnm@4ax.com> <memo.20240512203459.16164W@jgd.cix.co.uk> <v1rab7$2vt3u$1@dont-email.me> <20240513151647.0000403f@yahoo.com> <v1to2h$3km86$1@dont-email.me> <20240514221659.00001094@yahoo.com> <v234nr$12p27$1@dont-email.me> <20240516001628.00001031@yahoo.com> <v2cn4l$3bpov$1@dont-email.me> <v2d9sv$3fda0$1@dont-email.me> <20240519203403.00003e9b@yahoo.com> <v2etr0$3s9r0$1@dont-email.me> <20240520113045.000050c5@yahoo.com> <v2ff99$3vq7q$1@dont-email.me> <20240520153630.00000b5a@yahoo.com> <v2g7js$4vi9$1@dont-email.me> <20240521104659.00003fa0@yahoo.com> <e6f23396245cccf5a852718d100d044a@www.novabbs.org> <cdn3O.2383$Qgge.1207@fx12.iad> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: i2pn2.org; logging-data="1891816"; mail-complaints-to="usenet@i2pn2.org"; posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A"; User-Agent: Rocksolid Light X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8 X-Rslight-Site: $2y$10$oiBRRQ0BT1s8cvkUj.b1fubPLYQ5HNZENbkO7RVR6ro5YaTWhn4.2 X-Spam-Checker-Version: SpamAssassin 4.0.0 Bytes: 3365 Lines: 43 EricP wrote: > MitchAlsup1 wrote: >> >> >> Imagine, instead, if IEEE 754 had defined positive underflow with the >> result of positive tiny, negative underflow with negative tiny, >> positive overflow with positive infinity-epsilon and negative >> overflow with negative infinity+epsilon. >> >> Here, the fact overflow or underflow happened is recorded in the >> result, and these results remain identifiable from real infinities >> or real zeros. >> >> But that ship sailed 50 years ago. > If an overflow occurs and that exception is masked, x86 returns a > value of either +-largest finite number (LFN) or +-infinity (INF), > depending on the rounding mode. > (vol-1 Arch manual, section 4.9.1.4, Numeric Overflow Exception, > Table 4-10. Masked Responses to Numeric Overflow) > Rounding_Mode Sign_of_Result Result > ------------- -------------- ------------------------------- > To nearest + +∞ > – –∞ > Toward –∞ + Largest finite positive number > – –∞ > Toward +∞ + +∞ > – Largest finite negative number > Toward zero + Largest finite positive number > – Largest finite negative number > The difference seems to be that INF is a sticky overflow, LFN is not. > Would this not satisfy everyone? > The problem is that it requires diddling the control register to change > the round mode, as opposed to round mode on each float instruction. > Or maybe even the LFN/INF overflow choice should be a separate option > independent of round control bits. Yes, what we need is a rounding mode that suppresses overflow and underflow but is otherwise RNE.