Re: cobol data format!!! urgent!!!

From: Robert Wagner (robert_at_wagner.net.yourmammaharvests)
Date: 08/26/04

  • Next message: Frank Swarbrick: "Re: Revisiting an Old Prejudice: READ INTO/WRITE FROM" 
    Date: Thu, 26 Aug 2004 18:31:07 GMT

    On Wed, 25 Aug 2004 12:15:22 -0700, "Chuck Stevens"
    <charles.stevens@unisys.com> wrote:

    >"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
    >news:m0vmi0p1e99g7sje29tmnt48rie677dlg3@4ax.com...
    >

    >> IEC 559 is identical. IEC 10967:1994 added integers. Its
    >> floating-point is close but not identical. Differences are in flags
    >> and handling extreme values such as zero and infinity. The 2001 update
    >> added numerical functions.
    >
    >> Floating-point numbers contain a flag specifying whether they follow
    >> 10967 or 'other', which usually means 754/559.
    >
    >Aye, there's the rub. "Usually means ..." doesn't work really well in a
    >standard, be it ISO 10967 or ISO/IEC 1989!

    Like most standard committees, the 10967 folk take the attitude 'if
    you don't do it our way, you're on your own.' Why should they support
    the competition in IEC 559?

    >> In the 20 years since IEEE 754 was adopted, the computer industry
    >> boomed. Because Cobol offered no floating-point, we used the best
    >> standard available.
    >
    >What *one* format of high-precision floating-point do you believe is
    >appropriate for *every* existing machine, producing identical results across
    >all platforms?

    IEEE 754. That's not only my belief, that's reality. It's in most
    Intel, Motorola, Power PC, Sun and HP CPUs. It's even in S/390. See
    below.

    >"The encoding of extended formats is implementation-defined, and thus their
    >size in storage." Quadruple precision formats are *basic*, one binary and
    >one decimal, and data items in each format occupy 128 bits. That there are
    >exactly two instantiations of extended formats that match the quadruple
    >precision format (*still described as proposed* in the DRAFT dated last
    >Friday for the next revision of ISO 754!) is a red herring. *Which*
    >extended format in the *existing* ISO 754 should the COBOL standard have
    >insisted was appropriate for all implementations?

    I'd say decimal. Cobol people 'know' binary floating-point is
    inappropriate for bidness use because it cannot represent .01 exactly.

    >> IEC 10967 inherited Extended (below) from the earlier standards. Look
    >> at ISO/IEC 14882, the C++ standard approved in 1998. It includes a
    >> 'long double' type and it explicitly cites compliance with IEC 10967.
    >> http://www.kuzbass.ru/docs/isocpp/lib-support.html#lib.support.types
    >
    >>From what I see, this is a panoply of formats, not a single one appropriate
    >to all implementations.

    As far as I know, every C++ implementation has float and double. The
    addition of long double is logical.

    >> "When comparing the format parameters of "extended double-precision"
    >> in IEEE-754's Table 1 and those of the so-called
    >> "quadruple-precision", one finds that the "quadruple-precision" format
    >> is simply a specific instance of the "extended double-precision"
    >> format. Similarly, one will note that "double-precision" is a specific
    >> instance of "extended single-precision"."
    >
    >> http://babbage.cs.qc.edu/courses/cs341/IEEE-754references.html
    >
    >And ... Are you prepared to demand that all COBOL vendors support
    >bit-addressability and arbitrary word lengths in order to provide for
    >"extended double precision" in all formats? Of all vendors around, I'd
    >argue that Unisys has more experience with that than anyone else around,
    >based on my eighteen years of intimate exposure to the Burroughs Small
    >System -- which had bit-addressable memory and for which the microcode
    >provided different word lengths (if any word orientation at all) for each
    >language! I don't think other vendors would appreciate a demand by the
    >COBOL standard for such flexibility!

    PACKED DECIMAL requires bit addressability on platforms that don't
    support it in hardware i.e. all except IBM and Unisys.

    Accessing bits doesn't require bit-addressable memory; it requires an
    AND instruction. You already knew that.

    >Ditto. This isn't a *basic* format, it's an *extended* format. It is still
    >*proposed* as a *basic* format as of the draft of the next revision for IEEE
    >754 *from last Friday*.

    Perhaps the standards process is too slow for real-world use. DEC,
    Sun, et al. couldn't afford to sit on their hands for 20 years. They
    reasonably went with the closest standard, or approximation thereof,
    available at the time. If there had been a standard, they would have
    used it.

    >> This response from Ann Bennett, only two years ago, rejects the idea
    >> of using EITHER standard in Cobol 2002.
    >>
    >> "1.h. Reference, and use later on, IEC 60559 (a.k.a. IEEE 754, IEEE
    >> floating point).
    >>
    >> Response: A floating point data type was added in FCD 1989 to
    >> provide access to hardware floating point, which is not universally
    >> IEEE 754. A primary requirement addressed by FCD 1989 is interaction
    >> with other programming languages. A mandated IEEE 754 implementation
    >> would not meet that requirement. "
    >>
    >> http://www.cobolportal.com/j4/files/02-0060.doc
    >
    >Yes, this was in response to a comment from the national standards body of
    >Sweden about the Final Committee Draft, and I agree with the response, which
    >represented J4's consensus.
    >
    >Your DEC example above amply illustrates my big concern for the 32-bit and
    >64-bit encodings: even if the format matches, the *operating environment*
    >(regardless of system, hardware, platform, whatever you want to call it) has
    >to *operate the same* regardless. This looks like IEEE floating-point
    >formats, but the documentation expressly states that it doesn't behave like
    >them.

    It was legacy design. The VAX 'G' format looked like IEEE but did not
    behave the same. More recent DEC designs, such as Alpha, are
    compliant.

    >And as to her concern: floating-point formats are *typically* defined for
    >the individual platform, and the 2002 standard COBOL definition allows them
    >to be what the platform defines them to be.

    I dispute that. It WAS typical in the mainframe world and elsewhere
    prior to 1985. It wasn't the case in 2002.

    This document shows how Intel achieved 100% compatibility with the
    IEEE standard, in behavior as well as format.

    "Two subsections are dedicated to the floating-point divide,
    remainder, and square root operations, which are implemented in
    software. It is shown how IEEE compliance was achieved using new IA-64
    features such as fused multiply-add operations, predication, and
    multiple status fields for IEEE status flags. Derived integer
    operations (the integer divide and remainder) are also illustrated.

    IA-64 floating-point exceptions and traps are described, including the
    Software Assistance faults and traps that can lead to further
    IEEE-defined exceptions. The software extensions to the hardware
    needed to comply with the IEEE Standard's recommendations in handling
    floating-point exceptions are specified. "

    http://developer.intel.com/technology/itj/q41999/articles/art_6.htm

    Here we see AMD doing rigorous compliance testing:

    We describe a mechanically verified proof of correctness of the
    floating-point multiplication, division, and square root instructions
    of The AMD K7 microprocessor. The instructions, which are based on
    Goldschmidt's Algorithm, are implemented in hardware and represented
    here by register-transfer level specifications, the primitives of
    which are logical operations on bit vectors. On the other hand, the
    statements of correctness, derived from IEEE Standard 754, are
    arithmetic in nature and considerable more abstract. Therefore, we
    begin by developing a theory of bit vectors and their role in
    floating-point representations and rounding, extending our previous
    work in conection with the K5 FPU. We then present the hardware model
    and a rigorous and detailed proof of its correctness. All of our
    definitions, lemmas, and theorems have been formally encoded in the
    ACL2 logic, and every step in the proof has been mechanically checked
    with the ACL2 prover

    http://nitro.xyzdns.net/~russ/david/papers/k7-div-sqrt.html
     
    Here we see Motorola describing one of its early (1988) chips:

    "The DSP96002 is notable for its full hardware support of IEEE-754
    single-precision and single-extended-precision floating-point
    arithmetic, its two complete sets of external 32-bit address and
    32-bit data buses, and its lack of common on-chip peripherals. "

    http://www.bdti.com/procsum/mot96002.htm

    Here is an account of floating-point history by William Kahan. I urge
    you to read the whole report. It's a brilliant description of how a
    good standard was developed.

    "Anarchy, among floating-point arithmetics implemented in software on
    microprocessors, impelled Dr. Robert Stewart to convene meetings in an
    attempt to reach a consensus under the aegis of the IEEE. Thus was
    IEEE p754 born. The second meeting was held one evening in November
    1977 at a San Francisco peninsula hotel under the chairmanship of
    Richard Delp. It attracted over a dozen attendees and Prof. Kahan.

    "These guys were serious. Some had been sent by microprocessor makers
    who had floating-point implementations in mind. National Semiconductor
    sent two. Zilog sent someone thinking about a Z8070 for its Z8000.
    Motorola was represented by Joel Boney who then led their project in
    Austin, Texas, to build what later ( 1984 ) became the MC68881/2
    coprocessors. These were beautiful jobs. Of course, Motorola and Zilog
    had a lot more transistors to play with by then."

    "Most mainframe makers, like CDC and Cray, sent nobody to these
    meetings, construing them to matter only to microprocessor makers. IBM
    was there only to observe; they knew their microprocessors were coming
    but couldn't say much."

    Prof. Kahan presented the K-C-S draft to the IEEE p754 working group.
    It had several proposals to consider. DEC was advocating that their
    formats be adopted. Other proposals came from microprocessor
    producers. The initial reaction to the K-C-S document was mixed.

    "It looked pretty complicated. On the other hand, we had a rationale
    for everything. What distinguished our proposal from all the others
    was the reasoning behind every decision. I had worked out the details
    initially for Intel."

    "In the usual standards meetings everybody wants to grandfather in his
    own product. I think it is nice to have at least one example -- IEEE
    754 is one -- where sleaze did not triumph. CDC, Cray and IBM could
    have weighed in and destroyed the whole thing had they so wished.
    Perhaps CDC and Cray thought `Microprocessors? Why should we worry?'
    In the end, all computer systems designers must try to make our things
    work well for the innumerable ( innumerate ?) programmers upon whom we
    all depend for the existence of a burgeoning market."

    http://www.cs.berkeley.edu/~wkahan/ieee754status/754story.html

    > If the COBOL compiler required
    >that IEEE-format floating-point be used, and the Pascal compiler on the same
    >platform used native-format floating-point, the two are incompatible. For
    >any degree of more-than-snail-like performance, in order to make good use of
    >IEEE floating point formats, the particular platform vendor has to provide
    >*hardware* support for the format.

    Anyone who designed new non-compliant hardware after 1985 had rocks in
    his head. It didn't happen. Non-compliant hardware is old design. So
    make an exception for 'native floating-point' to appease mainframes.

    Looking at it positively, most machines have IEEE hardware .. whether
    Cobol uses it or not. Denying it's there makes Cobol look .. old.

    >I don't believe an ISO standard has yet "blessed" a *single* extended
    >X-floating format; my best guess is that the 128-bit decimal and binary
    >floating-point formats in the draft will be in the next revision of IEEE
    >754, and promulgated into ISO standards from there. Until ISO (or IEEE)
    >establishes hard-and-fast rules for rounding and precision loss in
    >arithmetic for those *specific* formats, I don't think there's much chance
    >of convincing WG4 that this is a worthwhile addition to the standard.

    The rules will be the same as 64-bit, logically extended to 128. Just
    as 64 is a logical extension of 32.

    >Note that another comment from Sweden was "Reference, and use later on,
    >LIA-1 (ISO/IEC 10967-1:1994; note, however, annex E of LIA-2). LIA-1 is
    >"Language independent arithmetic-integer and floating point arithmetic."
    >The J4 response was "Most of the arithmetic specification in FCD 1989
    >existed in the previous edition of the COBOL standard and cannot be changed
    >incompatibly. WG4 will investigate mapping to LIA-1 in a future standard".

    Good answer. I think LIA-1/2 is 'too little, too late'. There are 100M
    chips with IEEE cast into silicon.

  • Next message: Frank Swarbrick: "Re: Revisiting an Old Prejudice: READ INTO/WRITE FROM"

    Relevant Pages

    • Re: RfD: IEEE-FP
      ... Many Forth floating-point extensions support IEEE arithmetic ... along with some standard number formats. ...
      (comp.lang.forth)
    • Re: cobol data format!!! urgent!!!
      ... misunderstood what "conformance to a standard" means. ... Cobol people 'know' binary floating-point is ... The quotation above is from IEEE 754. ... same as the IBM System/390 format which isn't the same as the Unisys MCP ...
      (comp.lang.cobol)
    • Re: Numerics, NaNs, IEEE 754 and C99
      ... |> standard changed. ... Making Python incompatible with IEEE ... Secondly, it is NOT incompatible with IEEE 754, which is a pure hardware ...
      (comp.lang.python)
    • Flexible Floating-Point Standard Proposal (was: Decimal ... JOSS)
      ... proposing is a standard for the following: ... A software floating-point support package for a computer that will ... Why is the committee dealing with IEEE ...
      (sci.math.num-analysis)
    • Floating point and insularity was Re: cobol data format!!! urgent!!!
      ... the main need from a COBOL programmer's point of view is the ability to ... I look upon the lack of IEEE floating point in the IBM ... implementing the 2002 standard and making the floating point usages IEEE ... >>formats for each platform. ...
      (comp.lang.cobol)