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

COBOL and IEEE Std 754-2008



I've been off working on proposals for the upcoming COBOL standard in an effort to get it as clean as possible before publication, particularly with respect to the interaction between the COBOL standard and IEEE Std 754-2008. 
 
The decision as to what goes in from these proposals and what doesn't is largely up to ISO/IEC JTC1/SC22/WG4, for which the next meeting is currently scheduled for May. 
 
I believe the working group is in basic agreement with me on the following directions. 
 
1)  Largely, the current status -- and the minimum the standard will contain -- specifies the decimal encoding, and only the decimal encoding, of decimal formats both for arithmetic operands and for data declarations.  It also allows the binary formats for both contexts (there are a few minor tweaks outstanding to accomplish this).  The draft is already silent on the subject of endianness.  There is no override capability for encoding; it's decimal, and any implementor that internally uses binary encoding will have to perform the conversions both on the way into and on the way out of the "arithmetic engine".   I don't much like that approach. 
 
2)  What I believe the MINIMUM enhancement beyond that is to eliminate any reference to the decimal encoding from the draft, leaving the choice of the encoding in standard-decimal arithmetic and in data declarations up to the implementor.  The implementor has to specify which encoding is used for basic decimal floating-point formats, but not necessarily for the arithmetic operands "fed into" IEEE 754 "arithmetic engine".  I've written a proposal to do that.  I don't much like that approach either. 
 
3)  Insofar as possible, what formats a user may specify in a data declaration should be independent of what the implementor uses directly in the "arithmetic engine".  The following two further proposals reflect that intent. 
 
3)  A proposal has been written to eliminate the requirement that the operands used in arithmetic be in a particular format in favor of a specification that whatever the results are (including exception conditions) are consistent with those for binary128 (for standard-binary arithmetic) and decimal128 (for standard-decimal arithmetic).  In the context of interface to the "arithmetic engine", it is silent on the subject of encoding for standard-decimal arithmetic, and on the subject of endianness for both standard-decimal and standard-binary arithmetic operands.  The working group feels that it's really none of the standard's business what the "intermediate data item" looks like.  It might well be a decimal128 or binary128 item, and that's fine, but the draft should require only that the results be the same as if it were, and if the implementor chooses not to use the formats directly, it's their business how they accomplish the desired results.    
 
4)  A proposal has been written to establish new syntax:  a) to allow the USER to specify explicitly whether the MSB is on the left or on the right for each data item declared in basic binary or decimal floating-point formats; 2) to allow the USER to specify a program-wide default for this characteristic, separately for binary and decimal formats, absent an individual data declaration override; 3)  to allow the USER to specify whether the decimal or the binary encoding is used for each data item in basic decimal floating-point formats; and 4) to allow the USER to specify a program-wide default for the encoding, absent an individual override.  The implementor is not required to provide ANY of these syntactic elements, but of course, their presence in the standard, and the defense that full compatibility and interoperability is compromised without them, is strong encouragement for them to do so. 
 
Some of the proposals I've made to the working group in pursuit of this goal have already been endorsed for inclusion in the draft; sone have yet to be examined in detail.  What the final outcome will be is up to WG4, but I have strong hopes that both 3 and 4 will be in the soon-to-be-published new COBOL standard. 
 
Comments?  Further refinement suggestions? 
 
    -Chuck Stevens

754 | revision | FAQ | references | list archive