/FLOAT=option

  Controls the format of floating-point variables.

  Options:

   D_FLOAT         Double variables are represented in D_FLOAT
                   format.  The __D_FLOAT macro is predefined.

   G_FLOAT         Double variables are represented in G_FLOAT
                   format.  The __G_FLOAT macro is predefined.

   IEEE_FLOAT      Float and double variables are represented in IEEE
                   floating-point format (S_FLOAT and T_FLOAT,
                   respectively).  The __IEEE_FLOAT macro or _IEEE_FP
                   macro (if/IEEE_MODE=DENORM_RESULTS) is predefined.
                   See also the /IEEE_MODE qualifier for selecting an
                   IEEE floating-point mode.

                   If /IEEE_MODE is not specified, the default
                   behavior is /IEEE_MODE=FAST for Alpha systems and
                   DENORM_RESULTS for I64 systems.

  On OpenVMS I64 systems, /FLOAT=IEEE_FLOAT is the default
  floating-point representation.  The _IEEE_FP macro is predefined by
  default, IEEE format data is assumed, and IEEE floating-point
  instructions are used.  There is no hardware support for
  floating-point representations other than IEEE, although you can
  specify the /FLOAT=D_FLOAT or /FLOAT=G_FLOAT compiler option.
  These VAX floating-point formats are supported in the I64 compiler
  by generating run-time code that converts VAX floating-point
  formats to IEEE format to perform arithmetic operations, and then
  converts the IEEE result back to the appropriate VAX floating-point
  format.  This imposes additional run-time overhead and some loss of
  accuracy compared to performing the operations in hardware on Alpha
  and VAX systems.  The software support for the VAX formats is
  provided to meet an important functional compatibility requirement
  for certain applications that need to deal with on-disk binary
  floating-point data.

  On I64 systems, the default for /IEEE_MODE is DENORM_RESULTS.  This
  is a change from the default of /IEEE_MODE=FAST on Alpha systems.
  This means that by default, floating-point operations may silently
  generate values that print as Infinity or Nan (the
  industry-standard behavior), instead of issuing a fatal run-time
  error as they would when using VAX floating-point format or
  /IEEE_MODE=FAST.  Also, the smallest-magnitude nonzero value in
  this mode is much smaller because results are allowed to enter the
  denormal range instead of being flushed to zero as soon as the
  value is too small to represent with normalization.

  The conversion of VAX floating-point formats to IEEE single and
  IEEE double floating-point types on the Intel Itanium architecture
  is a transparent process that will not impact most applications.
  All you need to do is recompile your application.  Because IEEE
  floating-point format is the default, unless your build explicitly
  specifies VAX floating-point format options, a simple rebuild for
  I64 systems will use the native IEEE formats directly.  For the
  large class of programs that do not directly depend on the VAX
  formats for correct operation, this is the most desirable way to
  build for I64 systems.

  When you compile an OpenVMS application that specifies an option to
  use VAX floating-point on the Itanium architecture, the compiler
  automatically generates code for converting floating-point formats.
  Whenever the application performs a sequence of arithmetic
  operations, this code does the following:

   o  Converts VAX floating-point formats to either IEEE single or
      IEEE double floating-point formats.

   o  Performs arithmetic operations in IEEE floating-point
      arithmetic.

   o  Converts the resulting data from IEEE formats back to VAX
      formats.

  Where no arithmetic operations are performed (VAX float fetches
  followed by stores), no conversion will occur.  The code handles
  such situations as moves.

  VAX floating-point formats have the same number of bits and
  precision as their equivalent IEEE floating-point formats.  For
  most applications the conversion process will be transparent and
  thus a non-issue.

  In a few cases, arithmetic calculations might have different
  results because of the following differences between VAX and IEEE
  formats:

   o  Values of numbers represented

   o  Rounding rules

   o  Exception behavior

  These differences might cause problems for applications that do any
  of the following:

   o  Depend on exception behavior

   o  Measure the limits of floating-point behaviors

   o  Implement algorithms at maximal processor-specific accuracy

   o  Perform low-level emulations of other floating-point processors

   o  Use direct equality comparisons between floating-point values,
      instead of appropriately ranged comparisons (a practice that is
      extremely vulnerable to changes in compiler version or compiler
      options, as well as architecture)

  You can test an application's behavior with IEEE floating-point
  values by compiling it on an OpenVMS Alpha system using
  /FLOAT=IEEE_FLOAT/IEEE_MODE=DENORM.  If that produces acceptable
  results, simply build the application on the I64 system using the
  same qualifier.

  If you determine that simply recompiling with an /IEEE_MODE
  qualifier is not sufficient because your application depends on the
  binary representation of floating-point values, then first try
  building for your I64 system by specifying the VAX floating-point
  option that was in effect for your VAX or Alpha build.  This causes
  the representation seen by your code and on disk to remain
  unchanged, with some additional runtime cost for the conversions
  generated by the compiler.  If this is not an efficient approach
  for your application, you can convert VAX floating-point binary
  data in disk files to IEEE floating-point formats before moving the
  application to an I64 system.