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