I sent the following two notes out to the LNGC and ASM (formerly DVLG) SHARE project requirement groups on Sunday (and semi-accidentally to the IBM Assembler List-server). It was suggested that I also let all of IBM-MAIN no about this.
Although the two notes are medium long, I *strongly* urge you (and your companies) to try and let you voices be heard on this BEFORE SEPT 28, 2005 -----Original Message----- to: SHARE LNGC and ASM (previously DVLG) project requirement distribution lists (and others) This is *NOT* a "SHARE requirement" note, nor do the opinions in this note (necessarily) reflect the official views of SHARE itself (although see below to see how the SHARE Board-of-Directors have responded). This is a LONG note, but I really, REALLY, hope that as many of you as possible take action upon this issue. ** There is currently a "vote" out for work that is progressing on the IEEE 754r >> DECIMAL FLOATING POINT <<< standard. Yes, I did say "decimal floating point". There is (and has been for several years now) a revision to try and ADD decimal floating point specifications for IEEE (this is in ADDITION TO - not to replace the existing IEEE floating point support - recently added to and extended availability on z/OS). Although there was (apparent) consensus a couple years ago on the format (and requirements for the encoding), recent work of a FEW members of the revision work is placing all the previous work in jeopardy. I *STRONGLY* recommend that "you" (either as individuals - or as a company - if you can get official permission to do so) VOTE NO on both the "BID" and "Compromise" proposals currently out for vote. VOTES MUST BE RECEIVED by Sept 28 !!! To read what the SHARE BoD said about this ballot, see: http://754r.ucbtest.org/ballots/bid.htm and scroll down to the section beginning: "Date: Fri, 02 Sep 2005 16:22:22 -0700 From: Jim Michael To the Chairman and members of the IEEE 754 revision working group, After considering the issue of revisions to IEEE 754 that your group is pursuing, the Board of Directors of SHARE has asked that I extend our previous letter commenting on the proposed revisions so as to register a "No" vote on this issue. Our intent in taking this action is to communicate the opposition of SHARE to the proposed amendment to the standard, especially as regards modifications to the hardware encoding specifications in the current draft." *** Similarly, if you want to read what IBM's rep to the committee has said, scroll to the section starting: "From: Mike Cowlishaw Date: Sat, 16 Jul 2005 22:16:14 +0100 Whereas a 'big integer' binary encoding for the significand offers the potential of high-speed unrounded multiplication, it is inherently mis-matched to the nature of decimal data and applications." *** Similarly, you can look for my PERSONNEL comments by looking for the section beginning: "From: "Bill Klein" Date: Sun, 24 Jul 2005 11:52:38 -0500 I want to record a NO vote on the proposal "Formats: Binary-Integer Decimal Encoding" NOTE: Most/many of these same comments also apply to the proposal: "Formats: Compromise Decimal Encoding" * * * I would suggest that you NOT simply "copy" the words from any of these comments, but that you include your own paraphrasing. To "cast a vote", all you need to do is: 1) Register for the 754r revision distribution list. This can be done by: To join the list, send the message text "subscribe stds-754" to [EMAIL PROTECTED] See: http://grouper.ieee.org/groups/754/ 2) Then send in your vote with: NO BID and/or a separate vote with "NO COMPROMISE" to: 754r AT ucbtest.org I suggest that you include (in your introduction) whether you are representing yourself, your company, or some "group" or "organization". You also need to explain WHY you are voting no. (See below for some reasons). following the rules for voting at: http://754r.ucbtest.org/ballots/web-vote.txt * * * * Although I certainly would understand if some of those reading this note will decide that they actually want to vote YES on these proposals, there are a number of reasons that I think they are a bad (VERY BAD) idea: 1) For those of us who have lived with "IBM" vs "IEEE" binary floating point on MVS, OS/390, z/OS, I think it is OBVIOUS that when/if a "new" decimal floating point specification is created that it be TRULY portable and that the same "encoding" be used on all platforms, all operating systems, and be available for all (appropriate) programming languages. 2) The current draft includes "decimal information encoded in decimal" (basically the parts of the decimal floating point items are stored in what we z/OS-types would call "packed decimal"). However, the proposals that I suggest you vote NO on would allow (or force) systems to store DECIMAL information IN BINARY. For those of us coming from (or familiar with) a COBOL background, you KNOW how painful (and error-prone) this can be. IBM COBOL mainframe sites suffer thru this with TRUNC(STD) (BIN) (OPT) options. If you don't know what can happen with storing decimal data in binary, I suggest you review the information (often HIGHLY user-unfriendly) at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3PG30/2.4.53.1 and http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3PG30/2.4.53.2 Now, I am NOT saying that if this (bad IMHO) proposal passed, that the same problems will occur for floating point, but I would say that the POTENTIAL problems are there. 3) One way that the committee MIGHT go with "decimal floating point" is to make the INTERNAL format different from the "logical" format. Alternatively, they might simply not specify ANYTHING for the "encoding" of decimal floating point data items. This would simply cause TOTAL LACK of portability (across languages, operating systems, and in "data transfer"). 4) The other thing that MIGHT happen if sufficient "users" don't speak up is that the entire revision gets so delayed that it becomes irrelevant or NEVER gets appropriate (and implemented). Therefore, I would suggest that NO VOTES include requests that the revision go with what the current draft includes (decimal information encoded in decimal formats) AND progress the revision to approval AS SOON AS POSSIBLE. 5) For those interested in how "business" programming languages might use this facility (if it gets approved) you might want to look at the tentative work for the next COBOL revision. See: http://www.cobolportal.com/j4/files/05-0152.doc 6) If you read the current votes, you MIGHT be convinced that there would be "serious" performance problems with using decimal encoding for decimal data (in decimal floating point items). However, there have been a number of presentations to 754r that seem (to me) to adequately refute this. For a presentation, see: http://www2.hursley.ibm.com/decimal/754r3.pdf * * * Please feel free to contact me by email if you have any questions about all of this, but PLEASE, please, Cast your vote (either personally or for your company) BEFORE Sept 28, 2005 (Even if you or your company decides to VOTE YES, I would urge you to let you view be known ASAP). *** NOTE 2 (clarification - additional information follows) to: LNGC & ASM requirements distribution lists (and others) It has been pointed out to me that I didn't give quite all the URL's and information that I should have in my note Sunday evening. To see ALL the 754r ballots (currently in draft, out-for-voting, and passed), go to: http://754r.ucbtest.org/ballots/ * * * The three ballots that I (personally) am recommending that "you" vote NO on are: - Formats: No Decimal Encoding Details at: http://754r.ucbtest.org/ballots/nodecimal.htm - Formats: Compromise Decimal Encoding Details at: http://754r.ucbtest.org/ballots/compromise.htm - Formats: Binary-Integer Decimal Encoding Details at: http://754r.ucbtest.org/ballots/bid.htm * * * * Although I recommend "NO" on all of them, I would say it is the LAST one that is most important to let you opinion (vote) been known on. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
