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

RE: Two technical questions on IEEE Std 754-2008

> So how can I convince Chuck that COBOL does not need separate ARITHMETIC
> attributes for the two possible DFP encodings? If they were needed, it
> would in fact be necessary to have FOUR arithmetics for STANDARD-DECIMAL
> and TWO for STANDARD-BINARY, in pairs for different byte orders. Luckily
> there are (I think) only two byte orderings to worry about, unlike older
> floating-point formats (remember the VAX?) that were mixed-Endian.

I think COBOL needs separate arithmetic MODES for the two encodings because, in COBOL terms, arithmetic includes "getting the data ready" for the arithmetic operation, along with the arithmetic operation itself.  For a given COBOL standard mode of arithmetic associated with the IEEE floating-point formats, it is the compiler's responsibility to ensure that the information supplied to the arithmetic instruction is in a given format, and COBOL currently has two such:  the operands can be in binary128 format, or they can be in decimal128 format using the decimal encoding. 
I find it hard to envision that implementations conformant to IEEE 754 would allow different encodings for operands to a single arithmetic operation -- on a theoretical fixed-word stack machine, Valuecall (a-binary32), Valuecall (a-decimal128), ADD, for example.  If they're all of the same basic type -- Valuecall (a-binary32), valuecall (a-binary128), I'd expect the arithmetic instruction to handle that.  We in COBOL need to know the form in which arithmetic operands are expected so we can put them in that form before handing them off to the operations.  For a given mode of arithmetic, all operands are converted to the same form, program-wide.    

> The only issue the language has to worry about is interchange formats,

Yes.  All we talk about is interchange formats. 
> and those have to address Endianness, character encoding, and other
> details

I don't think the standard needs to address these; that's the implementor's job. 
> of the same nature as BID vs DPD for STANDARD-DECIMAL.
Well, they're similar -- but in a given implementation, I would think the arithmetic ops would expect the values presented to it to be encoded the same way. 
> Given
> the time constraints it may be reasonable to stick with DPD, at least
> for now. At some point whatever mechanisms are used to deal with these
> other encoding issues could be updated to reflect BID vs DPD also -- or
> not, if the COBOL community is happy with a fixed choice, and the cost
> of in/out conversions (NOT conversions for every arithmetic operation)
> on native-BID platforms is acceptable.

I've brought the subject of providing support for the binary encoding alongside the decimal encoding of IEEE decimal floating-point formats to the attention of the rest of the COBOL working group. 
Under the assumption that such a project could be approved (or not), for the current revision, for a possible addendum, or for the next revision, I also noted that if the current names assume decimal encoding, and if they are left the way they are, the new ones added for binary-encoding support could be viewed as "junior" to the decimal encoding. 
I fully recognize that each encoding has its strengths and its weaknesses, and do not feel it appropriate for the ultimate result to imply prejudice of one over the other. 
Accordingly, I have submitted a paper proposing a simple, blanket editorial change to the current draft to change the names of the syntactic elements such that it's clear that what we have now deals with the decimal, and only the decimal encoding, allowing a set of similar names in similar forms for the binary encodings of those formats. 
Side note:  we already do allow binary128 usages, as well as the specification that the form numeric operands are converted to is binary128.  These have been there since we started this project, although we do suggest that the decimal mode is preferred for COBOL.  The reason for this is that COBOL is basically a decimal-oriented language to begin with, and non-integer numeric values expressable exactly in decimal are likely to be inexact when converted to binary128 as operands to arithmetic or as arguments to functions.  
I do not know how soon I will be able to begin a draft proposal to add the binary encoding features, much less when such a proposal would be complete or approved.  If all goes well, we may have syntactic support for both encodings, for conversion from one to the other, and support for either as the mode into which arithmetic operands and arguments are converted, in the actual standard. 
I can make no guarantee that (any or all of) this will be resolved in the soon-to-be-published standard.  I am doing everything I can to make that happen, including the plan to write a technical proposal, but I am not in a position to dictate that it MUST be approved, or WHEN it must be approved.  I am only in a position to express the strong opinion that it should be SERIOUSLY considered for the current draft, if we can make it happen according to ISO procedures.  If we have to do it through an addendum, it would be a really good idea to make sure there's no implicit prejudice against the binary encodings and favoring the decimal encodings in the syntactic elements relative to them, and preparations for that DO need to happen before the standard is published.  That's why that paper came first.       
  -Chuck Stevens 

754 | revision | FAQ | references | list archive