The FLOAT option controls the use of the additional floating-point
registers and whether Decimal Floating Point is supported.

.-+---+-------------------------------------.
| '-,-' |
V .-AFP-. |
>>-FLOAT--(----+-+-+-----+--+----------------------+-+-+-+--)--><
| | | .-NOVOLATILE-. | | |
| | '-(--+-VOLATILE---+--)-' | |
| '-NOAFP-----------------------------' |
| .-NODFP-. |
'-+-DFP---+-----------------------------'
- NOAFP
- Compiler-generated code uses the traditional 4 floating-point
registers.
- AFP
- Compiler-generated code may use all 16 floating-point registers.
- VOLATILE
- The compiler will not expect that the registers FPR8-FPR15
will be preserved by any called program. Consequently, the compiler
will generate extra code to protect these registers.
Extra code will be generated even if no floating-point registers are used,
and this will hurt performance.
If your application makes little or no use of floating-point, it would be
much better to compile with FLOAT(NOAFP) than with FLOAT(AFP(VOLATILE)).
- NOVOLATILE
- The compiler will expect that the registers FPR8-FPR15
will be preserved by any called program (as z/OS says they should be).
This option will produce the most optimal code and is highly
recommended if you have no CICS code.
However, it must be used with care in any code included in a CICS application.
For a CICS application,
- either: all code containing EXEC CICS statements must be compiled
with FLOAT(AFP(VOLATILE))
- or: all code using floating-point must be compiled
with FLOAT(NOAFP) or with FLOAT(AFP(VOLATILE))
It is safe and probably simplest not to use the FLOAT(AFP(NOVOLATILE)) option
in any code that runs as part of a CICS application.
- DFP
- The DFP facility is exploited: all DECIMAL FLOAT
data will be held in the DFP format described in the z/OS Principles of Operations
manual and operations using DECIMAL FLOAT will be carried using the DFP hardware
instructions described therein.
The ARCH option must be 7 (or greater) or this option will be rejected.
- NODFP
- The DFP facility is not exploited.
Under FLOAT(DFP),
- the maximum precision for extended DECIMAL FLOAT will be 34 (not 33 as it is for hex float)
- the maximum precision for short DECIMAL FLOAT will be 7 (not 6 as it is for hex float)
- the values for DECIMAL FLOAT for the following built-ins will all have the appropriate changes
- EPSILON
- HUGE
- MAXEXP
- MINEXP
- PLACES
- RADIX
- TINY
- the following built-in functions will all return the appropriate values for
DECIMAL FLOAT (and values that will be much easier for a human to understand;
for example SUCC(1D0) will be 1.000_000_000_000_001, and the ROUND function
will round at a decimal place of course)
- EXPONENT
- PRED
- ROUND
- SCALE
- SUCC
- decimal floating-point literals, when converted to "right-units-view", i.e. when
the exponent has been adjusted, if needed, so that no non-zero digits follow the
decimal point (for example, as would be done when viewing 3.1415E0 as 31415E-4),
must have an exponent within the range of the normal numbers for the precision
given by the literal. These bounds are given by the value of MINEXP-1 and MAXEXP-1.
In particular, the following must hold
- For short float, -95 <= exponent <= 90
- For long float, -383 <= exponent <= 369
- For extended float, -6143 <= exponent <= 6111
- when a DECIMAL FLOAT is converted to CHARACTER, the string will hold 4 digits for
the exponent (as opposed to the 2 digits used for hexadecimal float)
- the IEEE and HEXADEC attributes will be accepted only
if applied to FLOAT BIN, and
the DEFAULT(IEEE/HEXADEC) option will apply only to FLOAT BIN.
- the mathematical built-in functions (ACOS, COS, SQRT, etc) will accept DECIMAL FLOAT
arguments, but since the Language Environment support for these functions is
incomplete, these functions will convert their arguments to IEEE BINARY FLOAT,
invoke the corresponding IEEE BINARY FLOAT math routine and then convert the
result back to DECIMAL FLOAT. For the same reason, DECIMAL FLOAT exponentiation
will be handled in the analagous way.
- users of DFP need to be wary of the conversions that will arise in operations where one
operand is FLOAT DECIMAL and the other is binary (i.e. FIXED BINARY, FLOAT BINARY or BIT).
In such operations, the PL/I language rules dictate that the FLOAT DECIMAL operand be
converted to FLOAT BINARY, and that conversion will require a library call.
So, for example, for an assignment of the form A = A + B; where
A is FLOAT DECIMAL and B is FIXED BINARY, 3 conversions will be done
and 2 of those will be library calls:
- A will be converted via library call from FLOAT DECIMAL to FLOAT BINARY
- B will be converted via inline code from FIXED BINARY to FLOAT BINARY
- the sum A + B will be converted via library call from FLOAT BINARY to FLOAT DECIMAL
The use of the DECIMAL built-in function would help here: if the statement were
changed to A = A + DEC(B);, the library calls would be eliminated.
The library calls could be eliminated by previously assign B to a FLOAT DECIMAL
temporary variable and then adding that to A.
- the built-in function SQRTF will not be supported for DECIMAL FLOAT
arguments (as there is no hardware instruction to which it can be mapped)
- DFP is not supported by the CAST type function.
|
This information center is powered by Eclipse technology. (http://www.eclipse.org)