Recent discussion on comp.arch about IEEE 754 rounding requirements makes me wonder whether OpenRISC ought to support a slightly different floating point model. Rather than guaranteeing 0.5ulp for all rounding (i.e., 'infinite' precision for generating the guard bit), OpenRISC might guarantee .625ulp (3 bits to generate guard bit?). (This would be less than the difference between different rounding modes [or operation orderings].) It might also be reasonable to support a double-extended precision format as an internal format that does not support certain standard features (e.g., denormals are always flushed to zero). This might make handling denormals in the lesser precisions somewhat easier. The larger internal format could also be used to hold reciprocals and accumulations (i.e., uses in which the values rarely need to be stored and loaded). Such could also be useful in providing a quad-precision FP format in software and allowing the multiplier to be used for 64-bit integers. It might also be interesting to provide a random rounding method (which might be useful in counter-balancing numerical instability). (I suspect that the _formats_ are the most important part of the IEEE 754 standard WRT broad consistency.) Paul A. Clayton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums/openrisc/attachments/20041004/901ba6ee/attachment-0001.htm

Dear friend, that comes very close to a (general though) topic I initiated at comp.arch.arithmetic a few months ago. Then, noone came to support my thoughts of supporting OpenEXR opposed to the heavy IEEE-754. This is the original message posted at: http://groups.google.com.gr/groups?start=25&hl=el&lr=&ie=UTF-8&group=comp.arch.arithmetic&selm=b7a879e0.0406090233.23abb5ba%40posting.google.com I think that OpenEXR proposal for a 16-bit floating point format is very interesting. If i remember the format is: 1 sign bit, 5 exponent bits, 10 mantissa bits. I think (they claim) for most imaging applications the required dynamic ranges are achieved. It would be interesting to use such arithmetic for SIMD FP processing. My question is: Anybody knows if IEEE will standardize OpenEXR (or any other) form of a "halfword" FP data type? Thanks Nikolaos Kavvadias Ph.D. Candidate -------------------------------------------------------------------------------- ----- Original Message ----- From: Dysthymicdolt@aol.com To: openrisc@opencores.org Sent: Tuesday, October 05, 2004 1:14 AM Subject: [openrisc] Non-IEEE 754 Floating Point? Recent discussion on comp.arch about IEEE 754 rounding requirements makes me wonder whether OpenRISC ought to support a slightly different floating point model. Rather than guaranteeing 0.5ulp for all rounding (i.e., 'infinite' precision for generating the guard bit), OpenRISC might guarantee .625ulp (3 bits to generate guard bit?). (This would be less than the difference between different rounding modes [or operation orderings].) It might also be reasonable to support a double-extended precision format as an internal format that does not support certain standard features (e.g., denormals are always flushed to zero). This might make handling denormals in the lesser precisions somewhat easier. The larger internal format could also be used to hold reciprocals and accumulations (i.e., uses in which the values rarely need to be stored and loaded). Such could also be useful in providing a quad-precision FP format in software and allowing the multiplier to be used for 64-bit integers. It might also be interesting to provide a random rounding method (which might be useful in counter-balancing numerical instability). (I suspect that the _formats_ are the most important part of the IEEE 754 standard WRT broad consistency.) Paul A. Clayton ------------------------------------------------------------------------------ _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums/openrisc/attachments/20041005/f9d3b600/attachment.htm