Wirt Atmar wrote:
> Glenn writes:
>> I feel certain that the choice of x'C' and x'D' as sign characters has its
>> roots in the way signed zoned numbers are stored.  And the method we use 
>> for storing signed zoned numbers has its roots in Hollerith card codes (punch
>> cards).  Numbers punched on Hollerith cards were signed by overpunching the
>> last digit with either a '+' (zone 12) or a '-' (zone 11) punch giving us
>> the possibly familiar ( {, A, B, ..., I and }, J, K, ..., S ) sign
>> characters.  The EBCDIC values for those character ranges start with x'C'
>> and x'D' respectively.

> In my nightly communing with William of Occam, this explanation seems much 
> less likely than mine. Where does the "F" come from then? And who really cares 
> about EBCDIC? Or even ASCII? The governing idea is hex encoding.

I agree with Glenn.  Hollerith is Hollerith, regardless of the underlying ASCII/EBCDIC translations.  Back in the dinosaur days, as we replaced our aging IBM 360 with an HP2000 (and later 3000), we had card readers on both systems.  You didn't have to translate your cards <grin>, they were an "open standard" that could be taken from one reader to another and read equally well, with the exception that the IBM had a "not" symbol (sort of like an "L" rotated clockwise 90 degrees) that became the HPs caret (^).

The "F" comes with some correlation to EBCDIC, zoned and packed decimal, and the early IBM instructions and storage formats that dealt with them.  The digits 0-9 are indeed represented on a card by a punch in the respective row.  They are represented in EBCDIC in zoned form as 0xF0 - 0xF9.  And a "pure" zoned decimal number does indeed have an additional '-' (12-punch) over the last digit for positive (0xC0 - 0xC9) or '-' (11-punch) over the last digit for negative (0xD0-0xD9).  

EBCDIC character hex codes are not contiguous like ASCII, and follow more closely to the Hollerith codes as above.  Thus we have the EBCDIC characters C1-C9 being "A"-"I" and D1-D9 being "J"-"S" as in Glenn's example.  

The IBM didn't operate on zoned decimal natively, you had to convert to and from packed decimal.  But this didn't quite yet dictate the sign nibble.

PACK instruction packed the low-order nibbles of the zoned bytes into consecutive nibbles of the packed field, and stuck the high-order nibble of the last byte into the last nibble of the packed field.

UNPK instruction converted packed-to-zoned in a similar manner.

Now, if you wanted binary numbers, there were CVB and CVD instructions (convert to binary/decimal) that would translate packed numbers to binary and vice versa.  When converting binary to decimal, it ALWAYS generated a 'C0-C9' for positive numbers and 'D0-D9' for negative numbers.  Thus the 'pure' C/D origin.  

And lastly, the 'F0-F9' being the EBCDIC forms of the digits, a zoned field without a sign bit over the last digit simply kept it's 'F' and was considered to be positive.  Keypunchers didn't have to explicitly overpunch positive numbers.  But [assembly] programmers who converted binary to packed and packed to zoned prior to printing had to be careful to OR the last byte with 0x"F0" if you wanted a pure numeric output (and tack on a sign marker if it was needed).

How that translates to ASCII is left as an excercise for the reader.  I never explicitly learned zoned/packed manipulation on the classic, let alone PA-RISC systems.  Left that with IBM :-)

Jeff

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *