Edward Jaffe wrote: <begin extract> Recent System z machines have put much more emphasis on unsigned (aka 'logical') arithmetic. There is now logical load, logical add (with or without carry), logical subtract (with or without borrow), logical multiply, logical divide, etc. This technology advance makes sense. In analyzing our assembler product code, it appears that _at least_ 90% of our binary integers are eligible for treatment as unsigned values (counts, offsets, masks, loop control, etc.). Legitimate needs for signed binary quantities are actually difficult to find! < extract>
I have two comments. The first is that this new emphasis on unsigned binary integers is chiefly, I believe, an outgrowth of increasing use of C and its dialects,. which support this data type for historical reasons. The second is a miscellanea. Values like usage counts are certainly non-negative connceptually, but arithmetic operations on them may nevertheless yield intermediate negative results even when the the final outcome is non-negative. Offsets, on the other hand, are not conceptually non-negative,. Negative ones are frequently useful, and their use is of course supported by a number of z/Architecture machine instructions. Loop control of a very simple kind is certainly implementable using only unsigned arithmetic. One writes |&i seta 0 |&h seta <whatever> |.loop1 anop |&i seta &i+1 |&eol setb (&i gt &h) | aif (&eol).lend | . . . | ago .loop |.lend anop . A little complication makes this impossible. Suppose, say, that one wishes to loop using an increment n > 1. To do this one instead writes |&i seta -&n |&h seta <whatever> |.loop2 anop |&i seta &i+&n |&eol setb (&i gt &h) | aif (&eol).lend2 | . . . | ago .loop2 |.lend2 anop . . If, say &n has the value 7, &i has the successive values -7, 0, 7, 14, 21, . . . These examples could be added to, but I have said enough. EJ's point that most of the values he works with are STORED as non-negative ones is certainly correct, but intermediate negative values often arise during their use. Circumventions of many such problems are possible, but they are ugly, look unmotivated and are hard to maintain. The continued use of signed binary integers is thus often, but not of course always, the better part of valor. Any use EJ and his colleagues make of unsigned binary integers will be carefully considered.; but I do want to tell a war story, inapplicable to them, that has contributed to making me skeptical of unsigned binary and decimal arithmetic. COBOL supports unsigned integers. In a certain large bank they were used during some Y2k remediation to increase the capacities of some counters without altering the lengths of certain records. Unsigned arithmetic somehow became chic; its use spread rapidly; and then all hell broke loose in the form of ABENDs galore: I found myself explaining that unsigned values are not closed under subtraction to COBOL prograsmmers who had never thought much about closure. Take care! John Gilmore, Ashland, MA 01721 - USA
