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

*To*: "Fred J. Tydeman" <tydeman@xxxxxxxxx>*Subject*: Re: Questions on data transfer and non-arithmetic handling rules*From*: "Hossam A. H. Fahmy" <hfahmy@xxxxxxxxxxxxxxxxxxxxxxx>*Date*: Sun, 1 May 2011 12:54:37 +0300*Cc*: Charles Stevens <charles.stevens@xxxxxxxx>, IEEE 754 <stds-754@xxxxxxxxxxxxxxxxx>*In-reply-to*: <000.08040d00d191bc4d.002@tybor.com>*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>*Sender*: stds-754@xxxxxxxx

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

On Sat, 30 Apr 2011 14:26:33 -0600 Charles Stevens wrote:A very similar question:

>

>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?

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

Egypt

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

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

**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

- Prev by Date:
**Re: Questions on data transfer and non-arithmetic handling rules** - Next by Date:
**"reasonability" check** - Previous by thread:
**Re: Questions on data transfer and non-arithmetic handling rules** - Next by thread:
**RE: Questions on data transfer and non-arithmetic handling rules** - Index(es):