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

RE: Questions on data transfer and non-arithmetic handling rules

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. 
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. 
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>
On Sat, 30 Apr 2011 14:26:33 -0600 Charles Stevens wrote:
>1)  I do not find any rule offhand in IEEE Std 754-2008
>    Clause 5.4.2 or elsewhere that says what happens when
>    the "source" item is exactly the same format (and encoding)
>    as the "sink" item.  My personal assumption is that this
>    would be a "bit-for-bit" transfer, with no reformatting at
>    all, and that's what the COBOL rules specify.
>QUESTION:  Is there a rule that specifies this?

A very similar question:
Must "conversion" to same type of a signaling NaN trigger?

IEEE allows either way.
   Signal required logic:
   5.1 Overview:  General-computational operations -- might signal
   5.4 formatOf general-computational operations
   5.4.2 convertFormat() -- is one "conversion" operator
   7.2 Invalid operation -- a) any general-computational ... operation
       on a sNaN

   No signal allowed logic:
   5.1 Overview:  Quiet-computational operations -- do not signal
   5.5 Quiet-computational operations
   5.5.1 Sign bit operations -- ... signal no exception.
       copy(x) -- is the other "conversion" operator

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

754 | revision | FAQ | references | list archive