/FLOAT

    /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.