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.