John writes:

> I find it amazing that an explanation like "D means debit and C means
>  credit" which you "heard somewhere" is something to which you would
>  cling so tenaciously.  Keep in mind that this is IBM we are talking
>  about - Occam's Razor does not apply.  Jeff's explanation is the one I
>  have always believed, and I believe it makes much more sense.  In fact,
>  it answers your question "Where does the F come from" far better than
>  your explanation does.  I believe the debit/credit stuff is probably
>  just a mnemonic device someone came up with to help them remember which
>  is which.

The "C" means "credit" is not the part that I'm tenaciously clinging to. I 
don't give a hoot about that. That could quite easily be just some post hoc 
explanation that someone attached to the process long after it was born. I just 
thought that it was clever enough to repeat.

The part that I'm tenaciously clinging to is that C,D,F symbols chosen for 
the three-state sign value are about all that could have been done, and that it 
has nothing to do with IBM or their punch cards.

Indeed, BCD encodings are a lot older than IBM's Hollerith encoding (which, 
btw, Hollerith himself had nothing to do with. It's just an honorific name 
given to a punched paper process not unlike Hollerith's original punch cards). 

I'm an engineer old enough to remember exceptionally well those heady days 
when real men built their own UART modems and BCD displays out of flip-flops and 
nixie tubes.

Think about it for a minute (or as in IBM's original motto: just "Think"): 
how are you going to represent sign information in four bits? The values "0" 
(0000) through "9" (1001) are already taken up. There is no room to "overpunch," 
so that's out. Nor is there room to explicitly represent all of the positive 
and negative numbers directly in 16 characters. The best you could do is 
represent up to -5. There just isn't enough room to represent the remaining negative 
numbers, -6 to -9. Nor would you even want to.

You only have two design choices if you want BCD to be signed: either add 
another bit to every digit, essentially a sign bit, in the manner that integers 
are signed, or use one BCD character at the beginning or end as the sign 
information. The second choice is enormously more efficient. Individual digits 
aren't signed in a number; the number as a whole is, so only one sign carrying 
digit needs to be defined.

BCD arithmetic and encodings are an engineering idea that were derived from a 
hardware view of the world right at the beginning of the digital era and had 
absolutely nothing to do with IBM punch cards.

Wirt Atmar

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