[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: <hfahmy@xxxxxxxxxxxxxxxxxxxxxxx>, <tydeman@xxxxxxxxx>*Subject*: RE: Questions on data transfer and non-arithmetic handling rules*From*: Charles Stevens <charles.stevens@xxxxxxxx>*Date*: Sun, 1 May 2011 15:40:44 -0600*Cc*: IEEE 754 <stds-754@xxxxxxxxxxxxxxxxx>*Importance*: Normal*In-reply-to*: <COL112-W37D180B30BDADB748B5885839C0@phx.gbl>*List-help*: <http://listserv.ieee.org/cgi-bin/wa?LIST=STDS-754>, <mailto:LISTSERV@LISTSERV.IEEE.ORG?body=INFO%20STDS-754>*List-owner*: <mailto:STDS-754-request@LISTSERV.IEEE.ORG>*List-subscribe*: <mailto:STDS-754-subscribe-request@LISTSERV.IEEE.ORG>*List-unsubscribe*: <mailto:STDS-754-unsubscribe-request@LISTSERV.IEEE.ORG>*References*: <COL112-W129FC9BCF42EA29088D5C9839D0@phx.gbl>,<000.08040d00d191bc4d.002@tybor.com>,<BANLkTinniko5=NLNztiovKyaN4BH80boqQ@mail.gmail.com>,<COL112-W37D180B30BDADB748B5885839C0@phx.gbl>*Sender*: stds-754@xxxxxxxx

PS: I forgot to mention this: The reason COMPUTE always goes through the arithmetic mechanism is that EVERYTHING between the equal sign and the end of the statement is treated as an "arithmetic _expression_", including the simplest of cases. -Chuck From: charles.stevens@xxxxxxxx To: hfahmy@xxxxxxxxxxxxxxxxxxxxxxx; tydeman@xxxxxxxxx CC: stds-754@xxxxxxxxxxxxxxxxx Subject: RE: Questions on data transfer and non-arithmetic handling rules Date: Sun, 1 May 2011 15:32:59 -0600 I think there's an easier way to describe this. COBOL proposes two new forms of arithmetic: "standard-decimal" and "standard-binary", in which all source numeric data is converted into decimal128 or binary128 form respectively, as input to all arithmetic operations, and converted back to whatever form is required for the destination. COBOL also has an "intermediate rounding" specification, intended to cover all the various "modes" in IEEE, and some extras as well. COBOL's default, for historical reasons for what it deems "arithmetic" operations, is roundTiesToAway. For the conversions in MOVE, it's roundTowardZero. COMPUTE A = B: The ONLY cases I can thing of in which this MIGHT (and probably will) produce an identically bit-mapped result must meet ALL OF the following requirements: 1) Arithmetic mode is standard-binary, and both operands are binary128 formats, or arithmetic mode is standard-decimal and both operands are decimal128; AND 2) the sizes of the two operands are identical, AND 3) IF the arithmetic mode is standard-decimal, the encoding specification for both operands matches the implementor's encoding specification for the standard-decimal mode of arithmetic. The intermediate rounding mode is still specified "to the engine", but it doesn't apply because the result is exact (unless I'm missing something). In other words, it is PERMITTED, but not REQUIRED, that the result be bit-for-bit the same as the source. Seems to me EVERYTHING ELSE in COMPUTE A = B will go through some sort of convertFormat and/or encode/decode operation, and will likely result in a different bit pattern. If the mode of arithmetic differs from the format (mode is binary, format is decimal, and vice versa), inexactness from radix conversion is likely, and the "intermediate rounding" specification applies in the conversion process. The content of A might not end being identical to the content of B. Moreover, if the mode of arithmetic is standard-binary, and the operands are decimal128, and the source is normalized and has an exponent of, say, 5000, DECIMAL exponents that large won't fit in a binary128 item, and a fatal exception condition will be raised, with undefined results. MOVE: COBOL MOVE explicitly specifies that the bit-pattern is transferred exactly when the source and destination are of the same format (and encoding), and does not "engage" any IEEE conversions. Since COBOL also has a "bit-ordering" specification, all other things being equal, it allows for a "reverse the bit order" operation when the source and the destination are described the same except for that ordering specification. In all other cases involving basic interchange formats in COBOL, the functionality implicit in the likes of convertFormat, convertFromDecimalCharacter, convertToDecimalCharacter, etc., is needed to accomplish what is required for MOVE. The implementor doesn't HAVE TO use IEEE packaged routines to do this, but it makes the most sense to do so I think we're covered both ways for "identically-described" operands. -Chuck Stevens and enmarger than around 41operations, AND 4) If the arithmetic mode is standard-decimal, the encoding of BOTH operands : 1"nonarithmetic" operations, it's "roundTiesToIEEE 754's is, as I understand it, roundTiesToEven. The intermediate rounding specification has to be supplied to ANYTWhat that implies is that just about everything that goes into is COMPUTE A = B may ONLY be an exact tr Date: Sun, 1 May 2011 12:54:37 +0300 Subject: Re: Questions on data transfer and non-arithmetic handling rules From: hfahmy@xxxxxxxxxxxxxxxxxxxxxxx To: tydeman@xxxxxxxxx CC: charles.stevens@xxxxxxxx; stds-754@xxxxxxxxxxxxxxxxx 2011/5/1 Fred J. Tydeman <tydeman@xxxxxxxxx>
To answer Charles' original question following the same path that Fred took, we get the following: 5.4.2 Conversion operations says: "These operations shall not propagate non-canonical results. " so a formatOf-convertFormat(source) from a source in one format to a destination in the same format will canonize any non-canonical input, i.e. it is not a bit for bit transfer. On the other hand, 5.5.1 Sign bit operations says: "These operations may propagate non-canonical encodings." so a copy(x) operation **may** be a bit for bit transfer. I am not a COBOL writer but, in view of the above, I would propose that you can translate (COMPUTE B = A) to a convertFormat and translate (MOVE A TO B) to a copy(x) unless the A and B in the MOVE are not of the same format in which case you should use the convertFormat. -- Hossam A. H. Fahmy Associate Professor Electronics and Communications Department Cairo University Egypt |

**References**:**Questions on data transfer and non-arithmetic handling rules***From:*Charles Stevens

**Re: Questions on data transfer and non-arithmetic handling rules***From:*Fred J. Tydeman

**Re: Questions on data transfer and non-arithmetic handling rules***From:*Hossam A. H. Fahmy

**RE: Questions on data transfer and non-arithmetic handling rules***From:*Charles Stevens

- Prev by Date:
**RE: Questions on data transfer and non-arithmetic handling rules** - Next by Date:
**ISO/IEC Technical Report on programming language vulnerabilities** - Previous by thread:
**RE: Questions on data transfer and non-arithmetic handling rules** - Next by thread:
**"reasonability" check** - Index(es):