Re: Making Lemonade (Floating-point format changes)

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