As part of doing bits and bytes and fairly low-level stuff, we have mentioned
the possibility of a thing called 'binary coded decimal' and that, effectively, IBM
in their mainframe days, led the charge on this. Now I've done a video on this and how
it led, eventually, to extended binary coded decimal (EBCDIC). I would like to talk about
what is BCD, why is it necessary and in particular that's to answer a question
that I did, vaguely, think about in my early days of doing heavyweight, macho
calculations [on a computer] overnight. It's effectively: "How does this stuff ever get printed out?"
I thought, well, what's the biggest ratio between actual computation and fairly
quick printout that I can think of. Not my quantum calculations, they're
minor-league. Those of you who are familiar with Douglas Adams and "Hitchhiker's
Guide to the Galaxy", which was made into a BBC series here and also became a
movie, I think, will know that Douglas, who was a very far-seeing guy, had this
idea of the ultimate computer called Deep Thought. It was [an idea] years ahead of its
time, because I'm pretty sure that Deep Blue - IBM's chess machine; Deep Mind - the AI
machine that's doing GO, is it, and so on. And you know Deep Learning,Deep
everything. I'm not at all sure it isn't all down to Douglas Adams! >> Sean: I just have to
point out here that the ultimate computer was the Earth! >> DFB: Oh in the very end ... ?
>> Sean: And there will be some fans pointing out...I >> DFB: Oh! I see. Nevertheless, Deep Thought
was asked: "Deep Thought: what is the answer to Life the Universe and
Everything?: And several million years later, presumably even with quantum assistance.
[Music] >> Deep Thought: "You're really not going to like it!" >> High Priests: "Tell us!"
The answer to Life the Universe and Everything is: [voices on film] 42 42 42 >> DFB: 42 ! And my first thought
when I was laughing out loud at that was, I thought: "What's 42 in binary ?!" Is there
something special about it? And, yeah, how would you convert the binary string for 42
into being literally 4 and 2 on a piece of line-printer output? 42 in
binary is 101010. How do we know that that's 42?
Well, starting at the right its powers of two. So, 2^0 is units ,then 2s
then 4s then 8s then 16s and 32s. Armed with that knowledge we say OK
it's a 2 plus an 8 which is 10 plus a 32 is 42. Pretty good look! A six-bit
representation for a 2-digit decimal number. But if you feed that into a
printer you're not going to get 42 printed out, because by and large they do
not interpret binary. So, where does the printable form of '42' come from? And the
answer is it goes way back to the fact that IBM and their computing machines -
way back at the start of the 20th century they were the Hollerith company. You
know, doing census details; controlling elections from punch cards and some IBM
early electronic computers I think - the IBM 650 was it? - actually did work
internally on decimal. Just like Tommy Flowers [and Colossus]. I think they both used bi-quin.
But the pressure was on, from binary-based hardware to say: "This [binary] is more
efficient by far. You'd be mad not to use it". OK?,says IBM, but although it's got
to be a binary representation we want to directly link it to the decimal that
will ultimately be printed out. Now think about it, that's easy to do but
what would this binary-coded decimal be for 42? Every decimal position can range
from 0 to 9. So, how many bits do we need to represent 9? Well, we know that 3
bits isn't enough. 3 bits goes up to 111, which is 7, but you need a 8 and 9. So
you've got to go to that 4th bit. And you end up, of course, with 8 being 1000
and 9 being 1001. Ah! - I hear several of you saying - but you don't stop there, you
can go on to hexadecimal?! And this is precisely the thing with BCD. You must
*not* let it go over into the hexadecimal range from 10 - 16 [correction: 10 - 15] because the average
person wants their answers out in decimal - not in hexadecimal. So, here we go then. Look 0100
taken as a grouping of bits, on its own, that's nothing in the units column;
0 in the 2's column; 1 in the 4s column; 0 in the 8s column. That
represents decimal 4. Right next door to it, is a separate 4-bit entity. If I write
down 0010 that represents a 2. In its simplest form that is what binary
coded decimal is. And you just use them in four-bit nibbles. Now we all know a
nibble is half a bite. A byte equals 8 bits - well it does in the modern world.
So half a bite? Well, the name 'nibble' caught on for
obvious reasons. A nibble being a small bite and I'll use an 'i', but some people
like to extend the joke as much as possible and actually spell nybble with
a 'y'. I don't mind! And then a nibble can hold a hex digit. You might say: Oh! well -
that's it then - if I fed 0100 down a serial line, into
a printer, it would cough into life and print 4 ?" No. Not quite. But we're getting
close. Because what we've got to ask ourselves is ...
this whole print-out thing is treating decimal digits as characters. They're not
being thought of in their numeric sense at all. It's just any other character. It's
like an 'A', a 'B', a'Z', a '!' or whatever. The ASCII committee in the
1960s didn't just work in a vacuum. They knew what IBM - who they loved
and hated - had been doing for years. And it basically said: "It is so much easier
if you base what's printed ultimately on a BCD representation, but put a special
marker at the front of the BCD to pad it out to an 8-bit byte. But do it in such
a way that, in a sense, the codes that are going to do 0 - 9 are in a 'sensible' place.
Now, what does that mean. Well, let's do ASCII first, even though historically
it was second. In ASCII the digits occupy from 30 (hexadecimal) to 39 (hexadecimal)
What it means is, if you have
got, shall we say this 4 (0100). That is your hex nibble for 4. All you have
to do, to make it printable, as an ASCII 4, is to glue on the left hand end
hexadecimal three (which is the same as decimal three) which is 0011. So 0011
prepended to 0100 gives you an 8-bit entity which, if you fire that down at a
line printer it'll cough into action and print a 4.
Notice that when I say "glue on at the front", in order for it to be efficient
you don't want to be adding on something that will cause carries, if you see
what I mean. You need to park it [the ASCII boundary where digits start] on a multiple of 16,
and then what will happen is that whatever way you convert your 4 into
being 34 (hex) it will not cause ripple carries, which are inefficient. OK, say the
IBM mainframe types. Why not (historically) tell the youth of today what IBM did originally?
Same idea! ASCII learned a lot from what
IBM did. In IBM EBCDIC you don't prepend a 3 (0011 hex), you prepend an F (1111 hex)
But the principle is the same. Yeah? it's cleanly on that boundary.
So, that's an absolute crucial fact in making BCD-to-printed-out-results be fast and
efficient. You need to be able to put something in there that's low cost
because you're going to be doing millions of these BCD to ASCII/EBCDIC
conversions. So that is a very sort of crucial fact to get hold of to try and
reduce the conversion burden before print out. So, in many ways then that's
much of the story. If you once got it into BCD then both
ASCII or (if you're still on IBM mainframes) EBCDIC, do make it easy for
you to get into a printable form very quickly. And of course the I/O routines
hidden underneath Fortran and C will be well aware of this. Converting from pure
binary 101010 to 42 BCD (0100 0010), they look very different! When you get
onto telling us how to do it, it's not going to be a cheap operation is it?
Because that's the hard bit. It's all very well saying [that] getting from BCD to ASCIIk
is a piece of cake, but what about getting from binary to BCD? And the answer is
there's bound to be overheads there and it's bound to be something that you
probably want to eliminate? And to that effect, some people in the
commercial computing set-up said: "Look, binary to BCD will turn out to be
expensive. Tell you what - If what we do is totally trivial [arithmetically] and really isn't rocket
science, wouldn't we be better off to try and devise software, or
even hardware assistance circuits, to do all the arithmetic on a BCD notation?
Never convert it into pure binary! Because if all you're doing is adding up how
many voters in, y'know, Norwalk County or something, have voted for such-and-such,
you don't need all these huge great binary things that numerical analysts use
You're just counting numbers. And even if you're looking at somebody's balance,
in dollars and cents, surely that's simple enough arithmetic. It's better to
perhaps pay a little penalty for doing BCD arithmetic because you can overcome
that penalty, a bit, by having specialized hardware. Why not do it all in BCD and
then you don't have the binary to BCD overhead? All you have to do after you've
done your BCD arithmetic is slip a FFFF [correction: 1111] on the front end if it's EBCDIC
a 3 (hexadecimal) if its ASCII, and that's it. [It] prints out. There is one
classic one where you really can pick up that it's very advantageous to do it in
BCD. If you think about the number 0.10, which might represent ten
cents shall we say. You know, your bank account's been drained down. It's
down to its last 10 cents. So here you've got 0.10.
That's .1 (in decimal). What is it in binary? Oh dear!
You look at what it is in binary: [looks at notes] 0.000110011001100 ....
And it goes on for ever! There is no exact representation of .1 (decimal)
as a binary expansion. It just doesn't stop. And accountants and actuaries get
paranoid about that: "Oh! I know it'll never happen but I hate the idea that
the rounding might go wrong and imy client's balance might drop to
9 cents instead of 10 cents (!) How about some other examples of things that use
BCD, just to finish off with? I don't know if I've got it here ...
to dig it out of there, Sean. eventually [reaches for desk drawer] It's a little [electronic] hand calculator. What better
place to use BCD? It's utterly display- dominated. Apart from things like square
root - that's probably about the most complex thing that you can ask a simple
four-function calculator to do. But mostly it's additions, subtractions
simple divides and so on. They use BCD! Another example of simple
devices [that] you see in a shopping mall, or whatever, that could use BCD. Digital
clocks. It makes eminent sense to use BCD
because it's the display, and the change in the display, is happening all the
time - every second = but the actual incrementing is trivial. You don't need
to convert into binary to add one second to a digital display,
you really don't. Live with the BCD. Focus on the display, because that's what
matters above all else. i