"Maciej W. Rozycki" <ma...@codesourcery.com> writes: >> I tested the calculation with the type "float". >> ABI o32 with -mhard-float and -msingle-float produces the following results: >> 1.000000 (0x3f800000) / 0.000000 (0x00000000) = nan (0x7fffffff) >> 0.000000 (0x00000000) / 0.000000 (0x00000000) = nan (0x7fffffff) >> 0.000000 (0x00000000) / nan (0x7fc00000) = 0.000000 (0x00000000) >> 1.000000 (0x3f800000) + 1.000000 (0x3f800000) = 2.000000 (0x40000000) >> 1.000000 (0x3f800000) + inf (0x7f800000) = inf (0x7f800000) >> inf (0x7f800000) + inf (0x7f800000) = nan (0x7fffffff) >> inf (0x7f800000) + -inf (0xff800000) = 0.000000 (0x00000000) >> nan (0x7fc00000) + nan (0x7fc00000) = nan (0x7fffffff) >> nan (0x7fc00000) + nan (0xffc00000) = 0.000000 (0x00000000) >> >> The r5900 manual calls the result of 0/0 Fmax. So 0x7fffffff seems to be >> Fmax. > > So presumably you can get 0x7fffffff as an arithmetic result of a > calculation involving regular numbers as well, right? Say 0x7f7ffffe + > 0x74000000 (using the binary-encoded notation)? That would be beyond the > IEEE-754 single range.
Yeah, if I recall correctly. We already support what I think is the same format for SPU (spu_single_format), which I suppose makes sense given its heritage. Hopefully the format itself won't need much work in GCC. Richard
