FLOAT

Pragma equivalent

None.

Purpose

Selects different strategies for speeding up or improving the accuracy of floating-point calculations.

Syntax


             .-,-----------------------------------------.      
             V                                           |      
>>-FLOAT--(----+-HEX | IEEE----------------------------+-+--)--><
               +-FOLD | NOFOLD-------------------------+        
               +-MAF | NOMAF---------------------------+        
               +-RRM | NORRM---------------------------+        
               '-AFP | NOAFP--+----------------------+-'        
                              |    .-NOVOLATILE-.    |          
                              '-(--+-VOLATILE---+--)-'

Defaults

FLOAT(HEX, FOLD, NOMAF, NORRM, AFP(NOVOLATILE))
For LP64, the default suboption is IEEE.
For ILP32, the default is HEX.
For METAL, the default is IEEE.
If NOSTRICT and FLOAT(IEEE) are specified, MAF is the default.
If NOSTRICT, FLOAT(HEX), and ARCH(9) are specified, MAF is the default.
For ARCH(2), the default suboption is NOAFP.
For ARCH(3) or higher, the default suboption is AFP(NOVOLATILE).
When there is no suboption specified for AFP, the default is NOVOLATILE.

Parameters

HEX | IEEE

Specifies the format of floating-point numbers and instructions:

IEEE instructs the compiler to generate binary floating-point numbers and instructions. The unabbreviated form of this suboption is IEEE754.
HEX instructs the compiler to generate hexadecimal floating-point formatted numbers and instructions. The unabbreviated form of this suboption is HEXADECIMAL.

FOLD | NOFOLD

Specifies that constant floating-point expressions in function scope are to be evaluated at compile time rather than at run time. This is known as folding.

In binary floating-point mode, the folding logic uses the rounding mode set by the ROUND option.

In hexadecimal floating-point mode, the rounding is always towards zero. If you specify NOFOLD in hexadecimal mode, the compiler issues a warning and uses FOLD.

MAF | NOMAF

Makes floating-point calculations faster and more accurate by using floating-point multiply-add instructions where appropriate. The results may not be exactly equivalent to those from similar calculations performed at compile time or on other types of computers. Negative zero results may be produced. This option may affect the precision of floating-point intermediate results.

Note: The suboption MAF does not have any effect on extended floating-point operations.

For ARCH(8) or lower, MAF is not available for hexadecimal floating-point mode.

RRM | NORRM

Runtime Rounding Mode (RRM) prevents floating-point optimizations that are incompatible with runtime rounding to plus and minus infinity modes. It informs the compiler that the floating-point rounding mode may change at run time or that the floating-point rounding mode is not round to nearest at run time.

RRM is not available for hexadecimal floating-point mode.

AFP(VOLATILE | NOVOLATILE) | NOAFP

AFP instructs the compiler to generate code which uses the full complement of 16 floating point registers. These include the four original floating-point registers, numbered 0, 2, 4, and 6, and the Additional Floating Point (AFP) registers, numbered 1, 3, 5, 7 and 8 through 15.

AFP is not available before ARCH(3). If the code generated using AFP registers must run on a pre-ARCH(3) machine, emulation is provided by the operating system. Code with AFP registers will not run on a system that is older than G5 and OS/390® V2R6.

Note: This emulation has a significant performance cost to the execution of the application on the non-AFP processors. This is why the default is NOAFP when ARCH(2) or lower is specified.

If VOLATILE is specified then AFP FPRs 8-15 are considered volatile, which means that FPRs 8-15 are not expected to be preserved by the called program.

Note: The AFPs are FPR1, 3, 5, 7 and 8-15. However, FPRs 0-7 are always considered volatile. The AFP(VOLATILE | NOVOLATILE) option only controls how the compiler handles AFP FPRs 8-15, and not all the AFP registers.

Compiling with AFP(VOLATILE) for floating point code under CICS® is no longer necessary with CICS Transaction Server for z/OS® V4.1, which includes extended z/Architecture® MVS™ linkage support. If you are at CICS Transaction Server for z/OS V4.1, you might realize a performance improvement by recompiling the relevant floating point code with the default FLOAT(AFP(NOVOLATILE)). However, if you have floating point code that runs on an earlier CICS Transaction Server for z/OS release, you should use the AFP(VOLATILE) suboption on the relevant source files to avoid potential exposure of data corruption or undetected loss of data. For information about the Load Module Analyzer, which can detect programs that need to be compiled with FLOAT(AFP(VOLATILE)), see support document at http://www-01.ibm.com/support/docview.wss?rs=1083&uid=swg24010925. See Table 1 for a summary of the various scenarios:

Table 1. Various scenarios for FLOAT(AFP) a CICS environment
CICS TS Version	FLOAT(AFP) Suboptions Used	Result	Action
2.3, 3.1 and 3.2	FLOAT(AFP) FLOAT(AFP(NOVOLATILE)) (this is the default value)	Potential exposure of data corruption or undetected loss of data.	Recompile with FLOAT(AFP(VOLATILE)).
2.3, 3.1 and 3.2	FLOAT(AFP(VOLATILE))	Removes potential exposures of data corruption or undetected loss of data, at some performance cost.	No action required.
4.1	FLOAT(AFP) FLOAT(AFP(NOVOLATILE)) (this is the default value)	No potential exposures for data corruption or undetected loss of data, optimal performance.	No action required.
4.1	FLOAT(AFP(VOLATILE))	No potential exposures for data corruption or undetected loss of data, at some performance cost.	No action required, but recompiling with FLOAT(AFP(NOVOLATILE)) is designed to improve performance.

NOAFP limits the compiler to generating code using only the original four floating-point registers, 0, 2, 4, and 6, which are available on all IBM® System z® machine models.

Usage

When the FLOAT option is in effect, you can select the format of floating-point numbers. The format can be either base 2 IEEE-754 binary format, or base 16 z/Architecture hexadecimal format.

You should use IEEE floating-point in the following situations:

You deal with data that are already in IEEE floating-point format
You need the increased exponent range (see z/OS XL C/C++ Language Reference for information on exponent ranges with IEEE-754 floating-point)
You want the changes in programming paradigm provided by infinities and NaN (not a number)

For more information about the IEEE format, refer to the IEEE 754-1985 IEEE Standard for Binary Floating-Point Arithmetic.

When you use IEEE floating-point, make sure that you are in the same rounding mode at compile time (specified by the ROUND(mode) option), as at run time. Entire compilation units will be compiled with the same rounding mode throughout the compilation. If you switch runtime rounding modes inside a function, your results may vary depending upon the optimization level used and other characteristics of your code; switch rounding mode inside functions with caution.

If you have existing data in hexadecimal floating-point (the original base 16 z/Architecture hexadecimal floating-point format), and have no need to communicate this data to platforms that do not support this format, there is no reason for you to change to IEEE floating-point format.

Applications that mix the two formats are not supported.

The binary floating-point instruction set is physically available only on processors that are part of the ARCH(3) group or higher. You can request FLOAT(IEEE) code generation for an application that will run on an ARCH(2) or earlier processor, if that processor runs on the OS/390 Version 2 Release 6 or higher operating system. This operating system level is able to intercept the use of an "illegal" binary floating-point instruction, and emulate the execution of that instruction such that the application logic is unaware of the emulation. This emulation comes at a significant cost to application performance, and should only be used under special circumstances. For example, to run exactly the same executable object module on backup processors within your organization, or because you make incidental use of binary floating-point numbers.

IPA effects

The IPA compile step generates information for the IPA link step. This option also affects the regular object module if you request one by specifying the IPA(OBJECT) option.

Note: The option FLOAT(AFP(VOLATILE)) is not supported by IPA. If the option FLOAT(AFP(VOLATILE)) is passed to the IPA Compile or Link phase, then the IPA phase will emit a severe diagnostic message.

The IPA link step merges and optimizes the application code, and then divides it into sections for code generation. Each of these sections is a partition. The IPA link step uses information from the IPA compile step to determine if a subprogram can be placed in a particular partition. Only compatible subprograms are included in a given partition. Compatible subprograms have the same floating-point mode, and the same values for the FLOAT suboptions, and the ROUND and STRICT options:

Floating-point mode (binary or hexadecimal)
The floating-point mode for a partition is set to the floating-point mode (binary or hexadecimal) of the first subprogram that is placed in the partition. Subprograms that follow are placed in partitions that have the same floating-point mode; a binary floating-point mode subprogram is placed in a binary floating-point mode partition, and a hexadecimal mode subprogram is placed in a hexadecimal mode partition.

If you specify FLOAT(HEX) or FLOAT(IEEE) during the IPA link step, the option is accepted, but ignored. This is because it is not possible to change the floating-point mode after source analysis has been performed.

The Prolog and Partition Map sections of the IPA link step listing display the setting of the floating-point mode.
AFP | NOAFP
The value of AFP for a partition is set to the AFP value of the first subprogram that is placed in the partition. Subprograms that have the same AFP value are then placed in that partition.

You can override the setting of AFP by specifying the suboption on the IPA link step. If you do so, all partitions will contain that value, and the Prolog section of the IPA link step listing will display the value.

The Partition Map section of the IPA link step listing and the END information in the IPA object file display the current value of the AFP suboption.
FOLD | NOFOLD
Hexadecimal floating-point mode partitions are always set to FOLD.

For binary floating-point partitions, the value of FOLD for a partition is set to the FOLD value of the first subprogram that is placed in the partition. Subprograms that have the same FOLD value are then placed in that partition. During IPA inlining, subprograms with different FOLD settings may be combined in the same partition. When this occurs, the resulting partition is always set to NOFOLD.

You can override the setting of FOLD | NOFOLD by specifying the suboption on the IPA link step. If you do so, all binary floating-point mode partitions will contain that value, and the Prolog section of the IPA link step listing will display the value.

For binary floating-point mode partitions, the Partition Map section of the IPA link step listing displays the current value of the FOLD suboption.
MAF | NOMAF
For IPA object files generated with the FLOAT(IEEE) option, the value of MAF for a partition is set to the MAF value of the first subprogram that is placed in the partition. Subprograms that have the same MAF for this suboption are then placed in that partition.

For IPA object files generated with the FLOAT(IEEE) option, you can override the setting of MAF | NOMAF by specifying the suboption on the IPA link step. If you do so, all binary floating-point mode partitions will contain that value, and the Prolog section of the IPA link step listing will display the value.

For binary floating-point mode partitions, the Partition Map section of the IPA link step listing displays the current value of the MAF suboption.

Hexadecimal mode partitions are always set to NOMAF for ARCH(8) or lower. You cannot override this setting.
RRM | NORRM
For IPA object files generated with the FLOAT(IEEE) option, the value of RRM for a partition is set to the RRM value of the first subprogram that is placed in the partition. During IPA inlining, subprograms with different RRM settings may be combined in the same partition. When this occurs, the resulting partition is always set to RRM.

For IPA object files generated with the FLOAT(IEEE) option, you can override the setting of RRM | NORRM by specifying the suboption on the IPA link step. If you do so, all binary floating-point mode partitions will contain that value, and the Prolog section of the IPA link step listing will display the value.

For binary floating-point mode partitions, the Partition Map section of the IPA link step listing displays the current value of the RRM suboption.

Hexadecimal mode partitions are always set to NORRM. You cannot override this setting.
ROUND option
For IPA object files generated with the FLOAT(IEEE) option, the value of the ROUND option for a partition is set to the value of the first subprogram that is placed in the partition.

You can override the setting of ROUND by specifying the option on the IPA link step. If you do so, all binary floating-point mode partitions will contain that value, and the Prolog section of the IPA link step listing will display the value.

For binary floating-point mode partitions, the Partition Map section of the IPA link step listing displays the current value of the ROUND suboption.

Hexadecimal mode partitions are always set to round towards zero. You cannot override this setting.
STRICT option
The value of the STRICT option for a partition is set to the value of the first subprogram that is placed in the partition. During IPA inlining, subprograms with different STRICT settings may be combined in the same partition. When this occurs, the resulting partition is always set to STRICT.

If there are no compilation units with subprogram-specific STRICT options, all partitions will have the same STRICT value.

If there are any compilation units with subprogram-specific STRICT options, separate partitions will continue to be generated for those subprograms with a STRICT option, which differs from the IPA Link option.

The Partition Map sections of the IPA link step listing and the object module display the value of the STRICT option.

Note: The inlining of subprograms (C functions, C++ functions and methods) is inhibited if the FLOAT suboptions (including the floating-point mode), and the ROUND and STRICT options are not all compatible between compilation units. Calls between incompatible compilation units result in reduced performance. For best performance, compile your applications with consistent options.

Predefined macros

__BFP__ is defined to 1 when you specify binary floating point (BFP) mode by using the FLOAT(IEEE) compiler option.