Path: ...!news.misty.com!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Making Lemonade (Floating-point format changes)
Date: Tue, 21 May 2024 12:11:47 -0500
Organization: A noiseless patient Spider
Lines: 90
Message-ID: <v2ikkn$mmds$1@dont-email.me>
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>
 <v2g529$4fn7$1@dont-email.me>
 <be08fc860572f2ea80b6d3530161aefd@www.novabbs.org>
 <v2guog$ctck$1@dont-email.me> <v2hcm3$f1pd$1@dont-email.me>
 <20240521111903.00004ca1@yahoo.com> <v2hvu8$ikpg$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 21 May 2024 19:11:51 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="46cc854e5f55f7c187177de16fb06ef0";
	logging-data="743868"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18m4NO0c2iciJBhs+tFFP8FDgTt+Ze5kgc="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:zSPyZFQOugRBktFIzfjcwhSNglk=
Content-Language: en-US
In-Reply-To: <v2hvu8$ikpg$1@dont-email.me>
Bytes: 4483

On 5/21/2024 6:18 AM, Terje Mathisen wrote:
> Michael S wrote:
>> On Tue, 21 May 2024 05:49:55 -0000 (UTC)
>> Thomas Koenig <tkoenig@netcologne.de> wrote:
>>
>>> BGB <cr88192@gmail.com> schrieb:
>>>
>>>> Granted, they are not necessarily the option one would go if they
>>>> wanted "cheapest possible FPU that is still good enough to be
>>>> usable".
>>>>
>>>> Though, the point at which an FPU manages to suck badly enough that
>>>> one needs to resort to software emulation to make software work, is
>>>> probably a lower limit.
>>>>
>>>>
>>>> Luckily, "uses 754 formats, but with aggressive cost cutting" can
>>>> be "good enough", and so long as they more-or-less deliver a full
>>>> width mantissa, and can exactly compute exact-value calculations,
>>>> most software is generally going to work.
>>>
>>> This will require extensive testing and possibly modification for
>>> a lot of software ported to such a system.  This will drive up
>>> the total cost, presumably far more than any hardware savings.
>>>
>>>> But OTOH, if 1.0+2.0 gives 2.999999, that is, not good enough, so
>>>> there is a lower limit here.
>>>
>>> An example of a more interesting question is
>>>
>>>    if (a >= 0.) {
>>>      if (b >= 0) {
>>>        if (a + b < a) {
>>>          printf("We should never get here!\n);
>>>     abort();
>>>        }
>>>      }
>>>    }
>>
>> If I am not mistaken, that should hold on VAX, which has floating-point
>> very close to BGB ideal. It looks like it would hold even on less
>> robust formats, like IBM's hex float. I wonder where it is not true?
>>
>> The biggest difference between IEEE and VAX is that on IEEE when (a > b)
>> then (a - b > 0) while on VAX (a - b >= 0).
>>
>> Of course, IEEE has non-intuitive cases as well.
>> if (!(a < 0)) {
>>    if (!(b < 0)) {
>>      if (!(a + b >= a)) {
>>        printf("It's IEEE 754, baby!\n);
>>      }
>>    }
>> }
>>
> What happens when a and/or b is a NaN?
> 
> Comparisons with NaN should return false, so !(NaN < 0) will be true 
> (and the same for b), while !(NaN+b >= NaN) will also return true.
> 
> Is that what you were thinking of?
> 

Had not considered NaN's here.


Currently, FCMPEQ will be false on NaN, whereas FCMPGT ignores NaN's.

I guess possible could be to add an FCMPGE instruction, and then make 
both FCMPGT and FCMPGE be false on NaN (where the LT and LE cases can be 
handled by flipping the arguments, so would still be false on NaN).

So, as-is:
   if(!(a==a))
   {
     //NaN
   }

But, as-is:
   if(a>0)
   {
     //May still potentially get here with NaN
   }

....


> Terje
>