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

RE: Two technical questions on IEEE Std 754-2008

There's another advantage to this approach, Michel.  Let's suppose an application runs just fine on a BID-native machine, and let's also suppose that the end user has a bunch of data on disk in BID encoding.  Let's further suppose that, for whatever reason, the user decides to migrate to a DPD machine (exact same thing applies in reverse(. 
Assuming that each implementation supports BOTH sets of decimal USAGE clauses, assuming that that support includes the ability to convert from one encoding to another (as specified in IEEE):  EVEN IF the new platform supports ONLY the ARITHMETIC phrase most suitable to that machine (STANDARD-DECIMAL-B or STANDARD-DECIMAL-D), THEORETICALLY, the ONLY change the end user would have to make to the program would be to change the ARITHMETIC clause.   
Assuming the "old" preference was decimal encoding and the "new" is binary, and the ARITHMETIC clause WAS changed to reflect the "new", anytime an IEEE BID float was encountered as an operand, standard COBOL would require that the implementation must run it through the appropriate conversion functions to get it into the proper form for computation. 
That means there's no REQUIREMENT for the user to convert his archive DATA unless the user finds the performance hit of the (required) conversions from BID to DPD, each time a BID item is encountered, onerous.  Processor time is expensive, but preservation of the current form of data might be far more valuable to the user.  The standard can't make that determination,  In my view, neither should the implementor (by NOT providing data descriptions for the "opposite" encoding). 
So, for my record example below, let's assume that all the FLOAT-whatever operands are FLOAT-DECIMAL-B items of one size or another.  The record is legible and the operands are handled correctly, on a machine that has is running standard-decimal-d arithmetic, just as they did with standard-decimal-b arithmetic.  Slower, probably, but correctly. 
    -Chuck Stevens
> Date: Sun, 27 Feb 2011 11:11:43 -0500
> To: stds-754@xxxxxxxxxxxxxxxxx
> From: hack@xxxxxxxxxxxxxx
> Subject: RE: Two technical questions on IEEE Std 754-2008
> (And also: RE: A general comment on COBOL "modes of arithmetic")
> I'd like to thank Chuck for his generous time in reminding me how COBOL
> works. COBOL grew up in an area where machines and data representations
> varied much more widely than they do today, and I have to agree that in
> this context Endianness is just a minor glitch. It just happens to be
> the major remaining representation issue today, when nearly all machines
> are byte-oriented with power-of-two-sized formats.
> What really sums it up is the following:
> > Endianness as I see it is generic to the platforms across data types.
> > and unless somebody shows that endianness affects the IEEE floats in
> > some way that's different from how it affects everything else in data,
> > it's not a COBOL standardization issue at this time.
> I've essentially said the same thing when I wrote, regarding 745-2008 3.2:
> >> ... (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.)
> What Chuck's approach permits, and my suggestion doesn't, is the following:
> > 03 NAME.
> > 05 FIRST-NAME PIC X(20).
> > 05 LAST-NAME PIC X(20).
> > 03 SSN PIC 9(9).
> > ... etc., still 50 bytes.
> In other words, mixed encodings in the same record.
> I suppose it's conceivable that the programmer did this knowing that the
> two fields were going to be forwarded to different processing programs,
> one running on BID-friendly hardware and the other on DPD-friendly
> hardware. This is something languages like C would not be able to do.
> I still consider it as the equivalent of having some fields explictly
> declared Big-Endian and others Little-Endian in the same record -- but
> as we all agree this is NOT what COBOL is intended to deal with.
> Another advantage of Chuck's way is that he (in his standardization work)
> took on the job of dealing with this new distinction, taking the burden
> away from implementers. My way would require implementers to modify the
> way they handle record conversions generically by dealing with BID/DPD as
> well. My point was simply that if there is a way to transmit records such
> as the above across Endianness differences, that could have been augmented
> to deal with BID/DPD as well. I would have been extra work for somebody
> other than Chuck.
> Michel.
> P.S. I hope we reached a satisfactory conclusion to this long excursion
> prompted by a simple question!
> ---Sent: 2011-02-27 16:58:34 UTC

754 | revision | FAQ | references | list archive