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

RE: Two technical questions on IEEE Std 754-2008

Chuck Stevens replied to my question of how COBOL exchanges data between
platforms with regard to Endianness:
I don't have to do ANYTHING about endianness in anything close
to that time frame.  Drop it.

Chuck, apparently you completely misunderstand my point!

I'm NOT trying to get you (or anybody else) to do ANYTHING about Endianness!

I was trying to get you to do LESS WORK with regard to DFP, because I
was arguing that if nothing needs to be done about Endianness at the
language level (as is the case for most languages other than assembler),
then the same applies to the DPD/BID distinctions, because both issues
are simply matters of representation of the exact same data in memory
(in all arithmetic respects, including exceptions).

But I'm getting nowhere, and I still don't know how COBOL implementations
deal with Endianness.  My question about whether COBOL might really be
incapable of cross-platform data exchange (which I find hard to believe)
was prompted by your claim that even implementers of COBOL environments
could ignore Endianness issues.  And in another post I pointed out that
if Endianness really doesn't matter, e.g. because import/export records
are always in decimal character form for numerics, then DPD vs BID would
not matter either, and each platform could quietly use its own format
(or even a third one, such as Mike Cowlishaw's decNumber objects), all
completely invisible to the COBOL programmer or user, and with no need
to be addressed by the standard.

In another post you said that you regretted that the 754R working group
had not defined DFP_DPD and DFP_BID to be separate formats.  Well, we are
actually proud of the fact that we were able completely to separate the
issue of value sets and arithmetic rules from the issue of representation.
Take a look at table 3.1 in clause 3.2 -- Specification Levels.  We needed
to get down to the bit level in order to permit data exchange, and glossed
over Endianness because that issue is common to all numeric types beyond
single bytes.  (Perhaps we should have mentioned it, to make sure everybody
understood that BID vs DPD is almost at the same level as Endianness.  It
is in practice not quite at the same level because all sorts of mechanisms
are already in place to deal generically with Endianness, whereas the DFP
encoding issue is new and rides on top of the Endianness distinction.)


P.S. Thanks for clarifying what "portable without source code changes"
     means in COBOL.  It's simply different from what I'm used to, and
     the issue I raised in that regard is moot.
---Sent: 2011-02-27 06:50:42 UTC

754 | revision | FAQ | references | list archive