J3/14-196
To: J3
From: Malcolm Cohen
Subject: Conformance to ISO/IEC/IEEE 60559:2011
Date: 2014 June 19
1. Introduction
This paper contains specification and syntax, with limited discussion, for
making Fortran 2015 conformant with ISO/IEC/IEEE 60559:2011.
A background paper with more discussion is 13-356r1. Discussion here
is limited to the options that are more likely to be controversial.
2. Specifications
That we conform as much as reasonably possible to ISO/IEC/IEEE 60559:2010,
aka IEEE 754-2008. In particular:
(a) Where there is a change of terminology from the old IEEE 754,
we should use the new terminology, both in text and in names
of module entities. In particular:
denormal/denormalized -> subnormal
(b) IEEE_RINT needs its description updated to say that it does the
IEEE operation roundIntegralToExact.
(c) New rounding mode, roundTiesToAway (not required for binary formats,
but required for decimal formats). This is rather like our i/o
rounding mode "COMPATIBLE".
(d) New rounding function(s) for rounding to an integral value according
to a particular scheme, corresponding to a rounding mode.
(e) New functions that compute nextUp and nextDown (changing existing
functions is less convenient as well as less compatible).
(f) Clarify description of IEEE_REM to say that it conforms to the
specification for "remainder".
(g) New functions for maxNum, maxNumMag, minNum, minNumMag, pairwise
only.
(h) No provision for quantize operation.
(i) No additional functions for scaleB and logB; logBFormat is type
REAL so scaleB is IEEE_SCALE(x,INT(y)).
(j) Provide fusedMultiplyAdd operation.
(k) Provide either convertToInteger{rounding} or
convertToIntegerExact{rounding} (processor-dependent).
(l) Provide convertFromInt operation.
(m) Do nothing about convert{From,To}DecimalCharacter operations.
(n) Provide convert{From,To}HexCharacter operations.
(o) Do nothing about copy/negate/abs/copySign operations.
(p) Provide compare{Quiet,Signalling}{Equal,Greater...} operations.
(q) Do not provide is754version1985 and is754version2008 operations.
(r) Provide isSignMinus operation.
(s) Leave provision of the totalOrder operation as an exercise for the
programmer. Don't document that.
(t) Provide for getDecimalRoundingDirection and
setDecimalRoundingDirection, separately from binary.
See discussion.
(u) Provide saveModes and restoreModes operations.
Remaining operations are reasonably programmable via short code sequences
by the user, so we need not provide them.
3. Discussion
(a) For backwards compatibility it is good to require that the old names
will still work. Of course any vendor could (and would?) do that even
if we were silent on the issue, but requiring compatibility is best.
(e) We could remove IEEE_NEXT_AFTER since its purpose is better provided by
IEEE_NEXT_UP and IEEE_NEXT_DOWN. The syntax and edits leave
IEEE_NEXT_AFTER in place (for backwards compatibility).
(h) quantize is a decimal-only operation, and (it seems to me) one more
tailored to Cobol operations than to Fortran ones. A vendor who
provides decimal floats can add IEEE_QUANTIZE themselves. Portability
might argue that we should describe it for guidance purposes, but it
would have to be optional (there being no such thing as an empty
generic).
(i) Perhaps we should document this? No edits for that yet.
(j) This is the easiest-to-understand and least burdensome way to satisfy
the requirement. Otherwise we should say just exactly when it is that
a user-written a*b+c will do FMA. Also an explicit function imposes
less burden on hardware without FMA.
(k) The only difference between the two operations is whether IEEE_INEXACT
is raised; processor-dependent to remove potential hardware burden, as
few if any users will care about the INEXACT flag (those who do need
to know can write portable code to do whichever one they want given
the above).
(l) On some hardware/software combinations, REAL would do this as long as
it did not raise INEXACT and rounded according to the dynamic rounding
modes. A separate function avoids potential impact on REAL efficiency
for users who don't care about these.
(m) Because with appropriate ROUND= settings, READ and WRITE should already
do these. We might consider documenting that somewhere.
(o) These can all be synthesised from trivial code sequences if
IEEE_COPY_SIGN does not raise INVALID on a SNaN argument or result (we
allow, but do not require, this to be the case). We could make this
claim in the normative text, or even give the example code sequences.
Or if we wanted to be maximally useful, add four subroutines (these
are subroutines NOT functions) IEEE_{COPY,NEGATE,ABS,SIGNCOPY}.
(q) For the functions and functionality we provided before, there is
virtually no change. New functions and functionality is almost always
done with additional procedures, so use of them mostly needs to be a
compile-time thing (or link-time), there does not seem to be much one
can do at runtime. I.e. since we are providing 60559:2011 support,
the answer to "have we got 1985 support but not 2011 support" is almost
always going to be "no" anyway.
(r) We could claim IEEE_COPY_SIGN(x,1.0)<0 does this operation, but C has
a signbit macro so it is better for us to provide something easy.
(t) This will complicate our rounding mode discussions since there are two
of them (decimal and binary). We need to specify a reasonable default
for which one we are talking about, either that of the operands, both
decimal and binary, or just binary.
We could of course decide not to provide separate access to 60559's
binary and decimal rounding modes, i.e. the "Fortran/IEEE rounding
mode" would encompass both and both would change in lockstep. But
that might lead to later interoperability conflicts with other
languages that follow the "separate binary/decimal" path.
(u) The defaultModes operation can be performed by the user doing getModes
at program startup time.
4. Syntax
Specification feature (a):
In IEEE_FEATURES,
IEEE_DENORMAL -> IEEE_SUBNORMAL
In IEEE_ARITHMETIC,
IEEE_NEGATIVE_DENORMAL -> IEEE_NEGATIVE_SUBNORMAL
IEEE_POSITIVE_DENORMAL -> IEEE_POSITIVE_SUBNORMAL
IEEE_SUPPORT_DENORMAL -> IEEE_SUPPORT_SUBNORMAL
Plus require the old names to still work, i.e. they are synonyms for the
new names.
Specification feature (c):
New named constant of IEEE_ROUND_TYPE, IEEE_AWAY, for roundTiesToAway.
{An alternative spelling would be IEEE_ROUND_AWAY, but none of the other
rounding mode constants have the word "ROUND" in them.}
Specification feature (d):
New optional argument ROUND for IEEE_RINT, which specifies the rounding
mode to use. This does not affect the dynamic rounding mode.
Specification feature (e):
New functions IEEE_NEXT_UP(X) and IEEE_NEXT_DOWN(X) that follow the rules
for nextUp and nextDown; IEEE_SUPPORT_DATATYPE(X) restriction. Leave
the unnecessary IEEE_NEXT_AFTER in place for backwards compatibility.
Specification feature (f):
Leave description of IEEE_REM as is with the claim appended that this is
equivalent to 60559's remainder operation.
Specification feature (g):
New functions IEEE_MAX_NUM, IEEE_MAX_NUM_MAG, IEEE_MIN_NUM, and
IEEE_MIN_NUM_MAG, all with arguments (X,Y), X and Y being REAL with the
same kind and IEEE_SUPPORT_DATATYPE(X).
Specification feature (j):
New function IEEE_FMA(A,B,C).
Specification feature (k):
New function IEEE_INT which either does convertToInteger or
convertToIntegerExact (processor-dependent).
Arguments (X,ROUND[,KIND]). Dynamic rounding mode unaffected.
Specification feature (l):
New function IEEE_REAL(A[,KIND]), where KIND specifies a REAL type with
IEEE_SUPPORT_DATATYPE, and A is Integer or Real with
IEEE_SUPPORT_DATATYPE(A). For Integer A this is convertFromInt,
for Real A this is convertFormat.
Specification feature (n):
For output, new edit descriptors EXw.d and EXw.dEe. Format according
to 60559 subclause 5.12.3. Recognise on input. Don't provide as
literal constants.
Specification feature (p):
Add requirement that normal comparisons of IEEE floating values obey
the 60559 requirements for the signalling operations. Add new functions
for the quiet versions, IEEE_QUIET_EQ(X,Y), IEEE_QUIET_LT et al.
NOT Specification feature (q):
If we were to support this feature (instead of not supporting it), the
suggested syntax would be an optional YEAR argument to
IEEE_SUPPORT_STANDARD with acceptable values for YEAR being 1985 and 1989
(for old IEEE 754) and 2008 or 2011 for new IEEE 754. The default would
be 1985.
Specification feature (r):
New function IEEE_SIGNBIT(X), X is REAL with IEEE_SUPPORT_DATATYPE(X),
returns true if the signbit is set, false otherwise, without exception.
Specification feature (t):
Add optional RADIX argument to IEEE_{GET,SET}_ROUNDING_MODE. If omitted,
the default is 2.
Specification feature (u):
New data type in IEEE_ARITHMETIC, IEEE_MODES_TYPE.
New subroutines IEEE_GET_MODES (MODES) and IEEE_SET_MODES (MODES).
===END===