home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / compiler / 1909 < prev    next >
Encoding:
Text File  |  1992-11-18  |  2.8 KB  |  58 lines
  1. Newsgroups: comp.compilers
  2. Path: sparky!uunet!think.com!spdcc!iecc!compilers-sender
  3. From: tmb@arolla.idiap.ch (Thomas M. Breuel)
  4. Subject: Re: IEEE arithmetic handling
  5. Reply-To: tmb@arolla.idiap.ch (Thomas M. Breuel)
  6. Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle Perceptive)
  7. Date: Wed, 18 Nov 1992 17:53:37 GMT
  8. Approved: compilers@iecc.cambridge.ma.us
  9. Message-ID: <92-11-100@comp.compilers>
  10. Keywords: arithmetic
  11. References: <92-11-041@comp.compilers> <92-11-086@comp.compilers>
  12. Sender: compilers-sender@iecc.cambridge.ma.us
  13. Lines: 43
  14.  
  15. eggert@twinsun.com (Paul Eggert) writes:
  16.  
  17.    The IEEE floating point standard recommends that the user be able to
  18.    request a trap whenever operations like .LT. are applied to NaNs, so
  19.    for operations like .LT., Breuel's ``alternative approach'' should
  20.    simply be a matter of enabling a trap handler.  However, .EQ. and .NE.
  21.    never trap, so (contra Breuel) Cownie's example still works even if
  22.    traps are enabled.  See IEEE Std 754-1985, page 13, table 4.
  23.  
  24. I didn't say that they did trap. I said that I think it's a bad idea for a
  25. language standard to make any guarantees about how the built-in operators
  26. work with IEEE NaN's. I believe that built-in operators should have no
  27. defined behavior for any IEEE-specific features, not after "enabling a
  28. trap handler" nor in any other case. If you define such behavior, programs
  29. written with IEEE semantics in mind will not be forced to clearly document
  30. where they rely on IEEE-specific properties, and they will be very
  31. difficult to port to non-IEEE machines.
  32.  
  33. The situation is analogous to the many unportable assumptions about
  34. pointers and representations made in C programs: those assumptions are
  35. true on many machines ("32bit workstations") but not all. They make
  36. porting C programs to "unusual" architectures a major headache, since
  37. there is no simple way to identify all the places in which such
  38. assumptions are being made.
  39.  
  40. Fortunately, whether or not to adopt specific aspects of the IEEE floating
  41. point standard is up to the individual language standards and can't be
  42. mandated by the IEEE floating point standard. So, a C implementation that
  43. chooses to optimize away "x != x" for "double x;" is still within the
  44. current C standard, although it may not be truly "IEEE conforming" (I
  45. believe the same is true for FORTRAN).
  46.  
  47. I would regret if my compiler gave up opportunities for optimization to
  48. cater to some IEEE specific properties of operators like "!=", but I
  49. suspect the overhead isn't all that large for workstation-class machines.
  50. Ultimate, it is you yourself who pays the price when you use unportable
  51. tricks like "x != x" instead of using self-documenting, clear interfaces
  52. to implementation dependent floating point properties.
  53.  
  54.                     Thomas.
  55. -- 
  56. Send compilers articles to compilers@iecc.cambridge.ma.us or
  57. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  58.