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

Potential modifications to COBOL relative to IEEE 754

I've completed, and submitted for review in the COBOL working group, the first draft of a proposal to add support for the binary encoding of decimal floating-point formats alongside the current specification using the decimal encoding to the current FCD.  
Syntax is provided such that the user may specify either of the two modes of decimal encoding to produce arguments for arithmetic.  
New data declaration entry clauses are introduced such that a given item conforming to the decimal64 and decimal128 specifications is additionally identified as being of decimal or binary encoding (for a total of four USAGE phrases for IEEE decimal floating-point formats, instead of two).    
A high priority for me in developing these proposed changes was to do my best to ensure that there is NO preference in the standard between the use of the decimal encoding and the binary encoding, fior either the mode of arithmetic or for user-declared data.  Some of the changes made to further this priority have included changing the keywords in syntax so that the syntax for the binary encoding doesn't "look junior" to the decimal encoding; others have included rearranging the sequence of rules to minimize the possibility that the order in which they were presented could be taken as "prejudicial" toward one encoding over the other.  
The encodings are equally valid from the COBOL standard's viewpoint; each has its strengths and its weaknesses; and which one is preferable in what environment for what reasons (including portability as well as efficiency) is outside the purview of the COBOL standard.
A caveat:  In the FCD, the implementor was free to choose to support all, none, or some part of, the IEEE floating-point features, and that's equally true of the new ones.  I would personally prefer that every implementor of this standard provide BOTH forms of encoding, in both data declaration and mode of arithmetic, regardless of their particular encoding preference, as a value-add to their users in terms of easy migration of existing software in the future.  But the new intermediate modes, as well as the new data declaration capabilities, remain "pick and choose" on the part of the implementor, however much I would prefer everyone choosing to produce a COBOL implementation of this standard provide support for all of the features associated with both encodings.  
At this point, the future of this proposal is out of my hands.  I intend to continue to lobby to get this into the version of the draft to be reviewed at the ISO/IEC JTC1/SC22/WG4 meeting in May, but I do not have the authority or the power to force the COBOL working group, or the national bodies, or WG4, to make this happen.  
    -Chuck Stevens

754 | revision | FAQ | references | list archive