[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: convertFormat and signaling NaN

On 2011-03-13 17:47:46 -0700, Dan Zuras IEEE wrote:
      Some architectures (a la 8086 et al) load all operands
      into a subsumptive or nearly typeless register.  In
      this case, double extended.  All operations are carried
      out in this 'type' which has a larger range & precision
      than all supported basic types.  In this case, when a
      result is returned to memory a type conversion (either
      implicit or explicit) of a particular format (thus,
      formatOf) is required to fit the result into the
      desired memory object.

      Other architectures keep track of the type of operands
      & must routinely deal with problems of heterogeneous
      dyadic operations like single + double & the like.
      Such architectures have rules for the type of results
      & may or may not need to convert a result on store.

      Our problem as a standards body was how to correct the
      1985 oversight of not specifying language bindings &
      still support both architectural styles.

      formatOf was part of our solution.

      So, on the one hand we DID spend a lot of time
      considering issues along these lines.  On the other
      hand, I think Steven is correct in that we never
      considered an instance of convert to one's own type
      as anything more serious than a copy.

      This is why I feel you are free to use either
      interpretation in C.

      My personal preference would be to interpret it as
      a copy.

If you allow the C implementation to have an extended precision for
results of expressions, this is no longer a copy, but a conversion
between different formats. In

  double x, y;

  /* ... */
  y = x;

x already has this extended type. BTW, that's why 1 * x and x are
equivalent, ignoring signaling NaN's (F.8.2).

Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

754 | revision | FAQ | references | list archive