Fri, 14 Jun 91 10:28:49 PDT

Related articles |
---|

Optimizing IEEE Floating-Point Operations daryl@hpclopt.cup.hp.com (1991-06-06) |

Re: Optimizing IEEE Floating-Point Operations bron@sgi.com (1991-06-11) |

Optimizing IEEE Floating-Point Operations bill@hcx2.SSD.CSD.HARRIS.COM (1991-06-14) |

Optimizing IEEE Floating-Point Operations eggert@twinsun.com (1991-06-14) |

Optimizing IEEE Floating-Point Operations cfarnum@valhalla.cs.wright.edu (1991-06-17) |

Re: Optimizing IEEE Floating-Point Operations henry@zoo.toronto.edu (1991-06-17) |

Re: Optimizing IEEE Floating-Point Operations bill@hcx2.ssd.csd.harris.com (1991-06-18) |

Re: Optimizing IEEE Floating-Point Operations jbc@hpcupt3.cup.hp.com (1991-06-19) |

Newsgroups: | comp.compilers |

From: | eggert@twinsun.com (Paul Eggert) |

Keywords: | arithmetic, design, Fortran, C |

Organization: | Compilers Central |

References: | 91-06-005 |

Date: | Fri, 14 Jun 91 10:28:49 PDT |

[... the IEEE FP standard and the various language standards

talk past each other, leaving large grey areas. -John]

It's worse than that -- sometimes the standards flatly contradict each other.

E.g. IEEE 754 says that if you print -0 and read it back in again, you should

get -0, not 0; Fortran says that you can't tell the differences between

printing -0 and 0. Luckily these cases are few; in practice IEEE 754 loses

these battles.

However, when IEEE 754 says ``the implementation must do A'' and a language

standard says ``the implementation is free to do either A or B'',

implementers desiring high performance sometimes improperly take the latter

statement as a license to do B while claiming support for IEEE arithmetic.

As a programmer, sometimes I prefer performance, but usually I prefer

standard, repeatable arithmetic. A good compromise is for implementers to

have a compiler option like `-fast-but-loose' that means ``don't bother to

obey IEEE 754 exactly, just make it run fast.'' Clearly optimizing 0.0*X to

X falls in the fast-but-loose category in an IEEE environment where X might

be a NaN. Some implementers might get by with supporting only the

fast-but-loose semantics, but if so I hope they don't pretend that they

conform to IEEE 754.

Unfortunately, new standards continue to be developed with equally large grey

areas. E.g. a proposed international standard called LCAS aims to provide a

language-independent standard for computer arithmetic, but it ignores all

issues of NaNs, Infinities, -0, etc.

In a more hopeful development, the NCEG group is considering a standard for

IEEE 754 support for Standard C. Let's hope they address the 0*X issue!

--

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.