/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,
                   DENORM_RESULTS for I64 and x86-64 systems.

  The default for /FLOAT is IEEE_FLOAT as the default floating-point
  This is a change from the default of /FLOAT=G_FLOATING on Alpha
  systems.  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 and x86-64 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.

  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 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 or x86-64 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 and x86-64 systems.

  When you compile an OpenVMS application that specifies an option to
  use VAX floating-point, 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 or x86-64 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 or x86-64 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 or x86-64 system.