Short-Term Memory Subtypes in Computing and Artificial Intelligence

Short-Term Memory Subtypes in Computing and 

Artificial Intelligence 

Derek J. Smith 

Part 1 - A Brief History of Computing Technology, to 1924 

Copyright Notice: This material was written and published in Wales by Derek J. Smith 

(Chartered Engineer). It forms part of a multifile e-learning resource, and subject only to 

acknowledging Derek J. Smith's rights under international copyright law to be identified as 

author may be freely downloaded and printed off in single complete copies solely for the 

purposes of private study and/or review. Commercial exploitation rights are reserved. The 

remote hyperlinks have been selected for the academic appropriacy of their contents; they 

were free of offensive and litigious content when selected, and will be periodically checked to 

have remained so. Copyright © 2002-2003, Derek J. Smith (Chartered Engineer). 

1 - Computing Before the Nineteenth Century 

The precise motivation for the human race's development of numeracy can only be guessed at on the 

basis of archaeological data, for it predates recorded history. It could have been driven, for example, 

by the needs of such neolithic crafts as boat-building, construction, or navigation, or by the needs of 

commerce (Smith, 1923) or taxation (Adams, 1993). As far as commerce is concerned, Smith (1923) 

notes that the Sumerians had a well-developed system of commerce by 3000BC, including bills, 

receipts, statements of account, weights and measures, etc. However, the supporting technology was 

simple in the extreme. You both planned and executed your sums in your head, assisted by 

temporary storage on fingers or scratch-pads, and by longer-term storage on tally sticks, clay tablets, 

or tokens (Schmandt-Besserat, 1978, 1992). The tally stick, in fact, could be much older still, for 

deliberately notched bones have been found in Upper Palaeolithic excavations dating from the 

Magdalenian. Marshack (1991), for example, interprets the Grotte de Taï bone plaque (ca. 15,000 

years old) as some form of calendrical record. Counting frames, on which small stones could be laid 

out, seem to have been particularly commonplace in ancient commercial centres (indeed, the modern 

word "calculate" comes from the Latin word for the pebbles used, namely calculi), and early bankers 

developed these into grid-marked table tops (which to this day retain the connotation "counter"). The 

abacus is a clever improvement upon stone counting, being portable and having no loose pieces. It 

was developed in India about 3000BC, spread outwards from there, and survives to the present day in 

the Far East. A number of variants have been identified, but all require that any arithmetical "carry" 

operation be executed manually. 

Now the problem with doing things manually is that it invites doing them wrongly - forgetting what to 

do next (errors of omission) or not doing something the right way (errors of commission). Accurate 

calculation is and always has been a constant struggle against error, and calls for just about every 

type of cognitive skill available to the human brain, not least the conceptual and procedural forms of 

long-term memory, and the working memory aspects of short-term memory [for a summary of the full 

range of human memory types, click here]; and it is when those psychological systems become 

overloaded (as they rapidly do), that they need to be further supported by external systems; and the 

problem with external systems is that they are themselves procedurally complex and can potentially 

consume more mental resources than they release. Numeracy, in short, pushes our powers of 

cognition to the very limit, and trades off complexity in long-term memory for less frequent overloads 

in short-term memory. Nevertheless, it is probably safe to suggest that the numerically literate subset 

of these ancient societies possessed a sound grasp of the cardinal number concept, planned their 

numerical problem solving using some form of the number line, understood at least a rudimentary 

system of place values, and had at their disposal a wide range of linguistic furniture to put it all into 

effect ..... 

Revised August 5, 2008 Page 1 of 190




Key Concepts - Cardinal Numbers and the Number Line: What does it mean to think "one", and 

how does this differ from "two", or "ten", or "a million"? Do we think of that number of beads on a table 

top, or of that number of points on an infinitely long mental straight line (the "number-line"), or of that 

number of depressions on a keypad, or what? And what does it actually mean when we ask "how 

many"? If we have ten things in sight do we reply "ten" in absolute terms because we somehow know 

what ten is (conceptual, or "semantic", knowledge), or do we know that if we start counting upwards 

from 1 we will quite quickly get to 10 (procedural knowledge). The problem is that it cannot entirely be 

the latter because there are plenty of numbers we cannot actually count up to, such as 10,000,000, or 

minus 5, or 1.33452, nor can it entirely be the former, because there is insufficient room in our 

semantic memories to have an entry for every possible number, most of which will never ever get 

used. Well following a decade of experimentation (eg. Gelman and Gallistel, 1978), Gelman (1980) 

concluded that successful counting involves the coordination of no less than five separate 

conceptual principles, namely (1) the One-One Principle - the principle that each item in an array 

can be given only one tag, (2) the Stable-Order Principle - the principle that the tags used must come 

from a stably ordered sequence, (3) the Cardinal Principle - the principle that the last tag used during 

the count represents the "cardinal number" of the array as a whole, that is to say, how many items 

are in it, (4) the Abstraction Principle - the principle that any set of items can be collected together for 

counting, and (5) the Order-Irrelevance Principle - the principle that the order in which the items are 

tagged makes no difference to the end result. [For a full list of Gelman's writings, click here.] The age 

of attainment of the cardinal principle in modern society has been further investigated by Wynn (1990). 

She observed that children between 2:7 and 3:0 prefer to answer the "How many?" question by 

repeating the entire count rather than stating the last tag used, and that only at mean age 3:6 do 

children reliably use the last tag on its own. 

Key Concept - Collective Nouns: Ancient languages and ancient minds must also have been able to 

deal with collections of items by giving them a collective name. They would have needed collective 

nouns like "herd", "flock", or "shoal", to indicate an indeterminately large number of cattle, sheep, or 

fish. This allows the mind to substitute one symbol (spoken or written) for a collection of other symbols, 

and once that habit has been acquired it is only a small additional step to introduce place value into 

your tally stick or counting frame system [for examples of aboriginal counting systems (a branch of 

cultural anthropology known as "ethnomathematics"), click here or here]. 

Key Concept - Quantitative Nouns: A quantitative noun is an expression which defines a precise 

number precisely, or a vague number as precisely as operationally necessary. In English this includes 

words like "few", "lots", "many", "pair", "dozen", "score", "gross", which we use to describe different 

sized groupings of entities. We may also use short phrases as nouns, as in the phrase "He wants 

what precious little additional money we have collected", where the five underlined words act as a 

quantitative noun (Despain, 2002). Language is actually remarkably good at devising ad hoc 

constructions such as this to convey number concepts, and although quantitative nouns are not in 

themselves numeracy, you need a degree of numeric literacy to use them properly. You also need to 

know how numerically literate your audience is, because they are the ones who are going to have to 

decode your chosen expression, and it is vital that all parties end up with the same common 

understanding. 

Key Concept - Place Value and "Carrying": A place value is the use of spatial position to change 

the value indicated by a given digit in a written system of numerical notation, and it is easy to 

demonstrate their usefulness by considering a counting frame, where a growing pile of identical unit 

counters would eventually become so large as to be unmanageable. At that juncture, every so many 

of the units could either (a) be replaced with one of the same type of counter placed somewhere else, 





or (b) be replaced in situ by a different type of counter by size, colour, shape, or material of 

construction, just as five green Monopoly® houses equals one red hotel. For some as-yet-unknown 

reason, option (a) is what happens in the abacus and place value systems of arithmetic notation, and 

option (b) has been reserved for physical token systems such as coinage. Our own "HTU" system of 

written numbers allows the digit "1" to indicate one in the units column, ten in the tens column, one 

hundred in the hundreds column, one thousand in the thousands column, and so on. You then have to 

"carry one" from one column to its left hand neighbour whenever you exceed nine in a column. We 

mention this (a) because the problem of mechanising the carry process was not solved until the 17th 

century, and (b) because the impact of the resulting system on a nation's collective numeracy can be 

remarkably subtle. Bierhoff (1996) studied the numerical concept systems of different European 

nationals, and found that continentals do not "dissect" two-digit numbers, preferring not to 

overemphasise the place value of each digit. This perhaps assists their being dealt with as single 

concepts. Thus 52 is explained to a Continental child as being "a fifty and a two", but to a British child 

it is explained as being "five tens and two units"(Bierhoff, 1996). 

Of course, once a society has acquired basic numeracy "skills", some of its members - we call them 

"mathematicians" - ascend far beyond the marketplace and do some remarkably clever things with 

them. By 300BC, Greek mathematical knowledge was sufficiently advanced for Euclid's "Elements" to 

become the standard geometry textbook for the next two thousand years, and, by 200BC, for 

Eratosthenes to calculate the circumference of the Earth [to see how he did this, click here]. Greek 

mathematics was kept alive during the European Dark and Middle Ages by the Islamic world, and 

then claimed back during the Renaissance by pure mathematicians such as Stifel, Fibonacci, and 

Fermat, generalists such as Descartes and Galileo, and applied mathematicians (usually 

astronomers) such as Copernicus, Brahe, and Kepler. Nevertheless, the abacus, the counting table, 

and the tally stick remained the principal aids to calculation for some four and a half thousand years, 

with little substantive change, while the non-mathematicians - the ones whose efforts actually drove 

the economy - were still struggling with the basics. Practical help finally came in the shape of 

"Napier's bones". These were devised by the Scottish mathematician John Napier (1550-1617), and 

consisted of bars of wood or ivory, six or eight inches long, on which were engraved the multiplication 

tables of the numbers 1 to 9. Each bone was divided into ten vertical divisions. The top space on any 

one facet was used to identify the digit in question, and spaces #2 to #10 were index positions for the 

multipliers 1 to 9. Each index space contained the two-digit product of the digit in question and the 

corresponding multiplier. The lowest was therefore (for bone #1, index position #1), and the 

highest was (for bone #9, index position #9). However, the two digits of each product were 

always separated by a diagonal line. Thus the bone for was marked "3" at the top to identify it, 

and then "0/3", "0/6", "0/9", "1/2" all the way down to "2/7", giving you your three times table at a 

glance. If you wished to multiply any two numbers together, you laid the first (and the longest, if there 

was one) number out as a sequence of bones, placed a straight edge across the bones to underline 

the "units" multiplier line, read off the products for each of the digit-by-digit multiplications, and then 

added up all the subtotals [to see photographs and worked examples, click here, or here]. You then 

repeated the process for the "tens" multiplier, then the "hundreds", and so on, and summed the 

individual results together. 

Napier's bones allowed large long multiplications to be done reasonably accurately by otherwise 

uneducated users, and any criticism that they were rather simplistic is offset by the fact that Napier 

was also responsible for one of the major theoretical advances of that era, namely logarithms, an 

even better method of multiplying by adding. Logarithms are power, or "exponential", relationships. 

They reflect how many times a number - known as the "base" of the logarithm - has to be multiplied 

by itself to give another number. Thus the act of computing base 3 to the power 2 means taking one 3 





and multiplying it by a second 3, and it gives you the answer 9 (commonly known as "three squared"). 

Similarly, base 3 to the power 3 means taking the 9 you already have, and multiplying it by a third 3, 

giving 27 (commonly known as "three cubed"). As a specific formula, this latter would be written ..... 

3 3 = 27 

..... and as a general formula, the process would be summarised as ..... 

b power = x 

In Napier's system, the power term is called the "logarithm" of the number x, and is properly written 

logbx (although this may be abbreviated to log x if the base of the logarithm is known beyond doubt), 

and x is called the "antilogarithm" of the logarithm. Calculating the logarithms of numbers in between 

the whole number powers takes time, but, once done, can be entered into books of "log tables", so 

that subsequent users can look them up rather than having to calculate them for themselves. 

The ability to multiply by adding derives from the mathematical principle that when two powers of the 

same base are multiplied together, the answer is the base to the sum of those two powers. Thus if 

you multiply 100 (which is 10 squared, or 10 to the power 2) by 1000 (which is 10 cubed, or 10 to the 

power 3) then you get 100,000 (which is 10 to the power (2+3)). As a specific formula, this would be 

written ..... 

10 2 + 10 3 = 10 5 

..... and as a general formula, it would be written ..... 

Or, to put it another way ..... 

b x + b y = b (x+y) 

logbx + logby = logb(x.y) 

..... which is the same thing as the following look-up-able format ..... 

x.y = antilog[logbx + logby] 

The reason logarithms immediately caught on, is that once the log and antilog look-up tables had 

been calculated and printed, the process of using them involved less steps than did Napier's bones, 

and was less prone to error because it totally avoided any long multiplications. No matter how big your 

numbers were, or how many of them you had to multiply together, their multiplication involved looking 

up the antilogarithm of the sum of their logarithms. And the more complicated the multiplication, 

the bigger the saving. Napier published his method in 1614, and the system soon received critical 

acclaim from the likes of Henry Briggs (1561-1631) and the astronomer Kepler. Napier died in 1617 

and Briggs carried on the calculations and published log tables to 14 significant figures in 1624, much 

to the delight of the astronomers and navigators of the day.] 

Logarithms also produced a valuable piece of technological spin-off, when the "additive" nature of 

logarithmic multiplication was noted by the astronomer Edmund Gunter and the clergyman William 





Oughtred and used to create the slide rule. In its simplest form, this is simply two straight laths of 

wood placed together long side to long side, with a logarithmic power scale (Gunter's contribution) 

etched into the two facing edges (Oughtred's contribution) [picture]. If the point on the second 

scale is placed against the multiplicand on the first scale, then the multiplier on the second scale is 

level with the product of the multiplication on the first, that is to say, the logarithm of the multiplicand 

has been added to the logarithm of the multiplier, which, given Naperian theory, is equivalent to 

multiplying the original natural numbers together [study the picture again, if confused]. The system 

was only accurate to a couple of significant figures, but that was sufficient for most practical 

applications. It was also portable, cheap, and you did not need to keep books of look-up tables at 

hand to make it work. It therefore caught on in a big way with everyday sum-doers such as craftsmen, 

bankers, and merchants. The system also had the power to fascinate, as in 1913, when a nine-year 

old Florida schoolboy named John Vincent Atanassof chanced upon his father's new slide rule, and it 

awoke in him such a love of numbers that - as we shall see in Part 2 - he went on to change the world 

(AIT Newsletter, Iowa State University, October 1999). 

But still - indeed more than ever - the individual arithmetician remained both thinker and doer. None of 

the available aids had any internal workings, and, no matter whether you used an abacus or Napier's 

bones or Briggs' log tables or Oughtred's slide rule, the necessary operating skill resided totally in the 

mind of the end user. If you omitted, or mis-sequenced, or mis-executed any one step of the 

calculation, then your final answer would immediately be compromised. The idea of removing error 

and increasing speed by mechanically assisting the process seems (along with the helicopter and the 

submarine) to have been yet another of those uncannily successful visions of the future by Leonardo 

da Vinci (1452-1519). Some time around 1500, he sketched a design for an adding machine built of 

interlinked, rotating, numbered wheels. It is, however, not known whether he actually built a machine 

to go with it, although 20th century facsimiles have been built to his design . Similarly, in 1623 Wilhelm 

Schickard (1592-1635) is reported to have built a "calculating clock" capable of adding and 

subtracting six-digit numbers. Again no specimen of the machine exists, but again there has been a 

20th century facsimile. 

More complete details have survived from 1642, when the 19-year French mathematician Blaise 

Pascal (1623-1662) developed the Pascaline. In modern technoparlance, this was a "da Vinci clone", 

a set of geared counter wheels with a "tens carry" system, which could record an eight-digit running 

total. A number was inserted by rotating the appropriate "column" wheel (units, tens, hundreds, etc.) 

with a stylus, and then added to by onward rotation by cognate column from right to left. Unlike the 

abacus, however, the built-in carry system (see below) would take care of turning as many as 

necessary of the dials to the left of the one being moved manually [for pictures and a more detailed 

description, click here]. Half a century later, Gottfried Leibnitz (1646-1716) demonstrated a larger 

handle-driven version of Pascal's machine. This was capable of multiplication by repeated addition, 

and went under the name machina arithmetica. This was to remain the principle of the desk-top 

calculator for more than 200 years, until the likes of NCR and Burroughs (see below) added electric 

drives to their machines in the early 1900s. 

Key Invention - The "Tens Carry" Cogwheel: This is the device which provided a solution to the 

place value problem. All the machines described above allowed a 10-position right hand cog to 

engage with the cog immediately to its left on every tenth advance. Thus as 9 advances towards 0 in 

the units column, say, a single digit is being added to the tens column, which will itself cast into the 

hundreds column if necessary, and so on until you fall off the left hand end of the available register. 

The technology is on the dashboard instrumentation of most 20th century automobiles, patiently 





adding up the kilometers/miles driven, and "going round the clock" back to zero when the number of 

digits finally gets exceeded. 

We mention all this, because the first fundamental issue in the history of computing has to do with the 

difference between the "analog" and the "digital" representation of a variable ..... 

Fundamental Issue - Analog vs Digital Representation: The point about any calculation aid is that 

sooner or later it has to represent the real world internally in some way. The simplest representation 

might be one finger (or stone, etc.) to represent one thing: one sheep, perhaps, or one soldier. This is 

known as a digital representation, because the number represents a finger-countable cardinal 

number (see above). Digital representations are ideal for counting indivisible things like sheep and 

soldiers, where there are only whole numbers on the number line, however they can also be used to 

deal with continuous variables such as length, weight, time, or angle of rotation. This is what is 

happening when we talk of horses being "15 hands" tall, or of Noah's ark being "300 arm's lengths" 

long. We are taking a particular dimension - height or length - and selecting a cardinal number of 

arbitrary units of it. When necessary, we can also cater for fractions of a unit, and if we convert these 

fractions to decimals it gives us a digital approximation to a point on a truly continuous variable (eg. 

7.693 kilometers). 

But in fact it is possible to select one continuous variable and treat it AS IF it were another. A good 

example of this is the clock candle, where the amount of burn down (ie. a distance) is taken as a 

measure of the passage of time . This is known as an analog representation, because the first 

measure is used analogously - in the place of - the second. Other examples of the digital-analog 

distinction are commonplace in everyday life .... 

The Watch: A digital watch shows you discrete numbers on a display panel, whilst an analog watch 

shows you nothing but a constant angular sweep. Neither shows you the time as such, of course, but 

with experience we instantly grasp what they are trying to tell us. 

The Slide Rule: This analogs distance against the logarithm of a number to be multiplied or divided. 

The Analog Speedometer: This analogs angular sweep against speed. 

The Analog Mercury Thermometer: This analogs distance (of expanding liquid) against 

temperature ..... 

The Analog Dial Thermometer: .....but the same job can also be done by angular sweep ..... 

The Digital Thermometer: ..... and digital displays are nowadays cheaper and more reliable, making 

them the display of choice in modern central heating, healthcare, and dashboard applications. 

NB: The study of what makes for the most effective combination of instruments in dashboards and on 

flightdecks is known as "display engineering". It is part of the larger sciences of human factors, 

human-computer interaction, human-machine interaction, and cognitive ergonomics, and is a critical 

aspect of modern aerospace, automobile, and computer design [to see some current research, and to 

be convinced of its everyday importance to those who fly in, or live beneath, airliners - which is most 

of us. 





2 - The Method of Differences 

Before proceeding with the main argument we need to say a few quick words about yet another 

mathematical procedure, "the method of differences", a technique which helps analyse the rules 

behind numerical series. This procedure was developed over a number of years by a succession of 

workers, including Isaac Newton, the aforementioned Henry Briggs, and James Stirling (1692-1770). 

The method involves writing down the first half dozen values in the given series, and then recording 

the differences between successive values, thus ..... 

Original Series: 1, 3, 5, 7, 9, 11 ..... 

Differences: 2, 2, 2, 2, 2 ..... 

If the differences are the same (and in this case they are) then you have discovered the underlying 

secret of the series. You know how it works, and can accordingly work out for yourself the value of 

any n th term in it. If, on the other hand, the differences are NOT the same, then you have to take the 

differences of the differences. This is known as taking the "second order" differences of the "first 

order" differences. Thus ..... 


1st Order Differences: 3, 5, 7, 9, 11 ..... 

2nd Order Differences: 2, 2, 2, 2 ..... 

Again, if the differences are the same (and again they are) then you have discovered the underlying 

secret of the series. If, on the other hand, the differences are NOT the same, then you have to take 

the differences of the differences again. This is known as taking the "third order" differences of the 

"second order" differences. Thus ..... 

And so on. 


1st Order Differences: 7, 19, 37, 61, 91 ..... 

2nd Order Differences: 12, 18, 24, 30 ..... 

3rd Order Differences: 6, 6, 6 ..... 

Now this is the pay-off. Equations of the form y = ax + b will have generated any series where the first 

order differences are the same, equations of the form y = ax 2 + bx + c will have generated series 

where the second order differences are the same, equations of the form y = ax 3 + bx 2 + cx + d will 

have generated series where the third order differences are the same, equations of the form y = ax 4 + 

bx 3 + cx 2 + dx + e will have generated series where the fourth order differences are the same, and so 

on. In other words, the "degree" of the polynomial - that is to say, the highest power term - is the same 

as the number of passes required to make the differences equal. The method of differences is thus a 

quick way for a pure mathematician to turn a few initial observations into a general purpose 





polynomial equation, from which any later n th value can be predicted with total reliability. Unfortunately, 

the technique was beyond most navigators and engineers, for they were applied mathematicians (and 

were, in any event, already converts to using look-up tables), so the method of differences became 

the shortcut of preference to the mathematicians who built the look-up tables in the first place, and it 

did the job very well. 

However, now that it was possible to do sums that much more quickly, another problem emerged, for 

the printers could not keep up with the mathematicians. The typesetting process was simply too slow 

and error-prone. The solution was to automate not just the calculation, but the print production 

process as well, and this idea seems to have come from a German engineer named Johann Helfrich 

Müller, who wrote 

"I would in the future make a machine, which would simultaneously print in printer's ink on paper any 

arbitrary arithmetical progression ... and which would halt of its own accord, when the side of the 

paper was full up. After setting the first figure, all one has to do is to turn a handle." (Müller, 1784, 

cited in Swade, 2000, p30.) 

Yet Müller never got round to making that machine, and when the French civil engineer Gaspard de 

Prony (1755-1839) worked with the method of differences from 1792 to 1801 as part of a team of 

around 80 mathematicians and assistants (that is to say, some 800 man years' effort) to produce "Les 

Grandes Tables Logarithmiques, etc.", a 19-volume book of logarithmic and trigonometric tables, the 

cost of typesetting and proof-reading prevented the manuscript ever being published in full. And it was 

these difficulties which prompted one Charles Babbage (see below) to try simultaneously producing 

the numbers AND the print out with the largest da Vinci clone ever produced ..... 

3 - Computing 1805-1866 - The Difference Engine 

We move on now to 1805, the year in which a French weaver named Joseph Jacquard (1752-1834) 

perfected a method of controlling his looms using precisely sequenced packs of precoded slats to 

codify the pattern of the weave in advance. Prior to this, it had been standard practice for around five 

thousand years to introduce the pattern into woven cloth using what would today be termed "pixel 

technology" - by manually varying which warp (ie. longitudinal) threads were raised, and which 

lowered, at the moment the weft (ie. transverse) thread was passed. Using warps and wefts of 

different colours gave you hundreds of coloured pixels per minute, from which you built up your 

desired pattern, but it was slow and monotonous work, and subject, again, to operator error. The key 

to Jacquard's advance lay in mechanising the process ..... 

Key Invention - Jacquard's Needle System: A number of wooden or lacquered card slats were 

strung together into a continuous loop, and mounted above the loom. At each activation by the 

weaver, the following sequence of operations took place: (1) a new slat was rolled forward to be 

"read", and the "used" slat was returned to the back of the pack, (2) sensor needles were advanced 

up against the slat, and were able to move further where there was a hole in the slat than where there 

was none (that is to say, some needles were restrained by non-holes), (3) the warp threads coinciding 

with the restrained needles were lifted (this being possible because the forward movement of the 

unrestrained needles disengaged the link to the lifting mechanism), and (4) the shuttle was passed, 

drawing the weft thread between the lifted and the unlifted warp threads. Looms with 400-600 needle 

systems rapidly became common, and 1000 needle systems were not unknown. The profit came 

when the slats could be recycled in an endless loop, because the loom simply repeated the pattern 

every time it got back to the start. The mass production of any repeating woven pattern thus became 





simple once the appropriate slats had been produced, and loops of up to 24,000 cards were not 

unknown. In truth, Jacquard incorporated several earlier inventions into his machine: the idea of the 

punched card program seems to have come from Jean Philippe Falcon in 1728, and the use of lifting 

hooks to effect the automation from Jacques Vaucanson in 1745 (Wilkes, 1956). Falcon's machine is 

on display in the Museum of Arts and Crafts in Paris. 

The Falcon-Jacquard system is cited very frequently in histories of computing, because it involved 

automation. It reduced a repetitive craft to an essentially numerical process, it brought numerical 

control to a manufacturing industry, and it involved programming as we nowadays understand it. 

Indeed, it only remained to point the technology at mathematical problems for it to become computing, 

and the story of how this happened begins shortly afterwards, when the British engineer Charles 

Babbage (1791-1871) took Pascal's and Leibnitz's cogwheeled calculators to new levels of complexity. 

In his late twenties, Babbage conceived the idea of a large calculating machine capable of automating 

the method of differences and printing off the resulting look-up tables. Like de Prony a few years 

before, Babbage had, as a young man, spent time producing mathematical tables for a living, and had 

been struck by the highly repetitive nature of the work, and by the underlying simplicity of the 

individual steps. Basically, even the most complicated tasks boiled down time after time to additions 

and subtractions done in a very precise order. He called his proposed machine a Difference Engine, 

had a small prototype (now lost) ready in 1822, and submitted the plans to the British government for 

funding to build a full-sized version. He was awarded enough money to start work, but progress was 

so slow that in 1833 funding was withdrawn with the machine still far from complete. The Difference 

Engine as it stood in December 1832 was as far as it got, and H.M. Treasury had invested nearly 

£17,500 in it (Swade, 2000). 

The root of Babbage's difficulties lay partly in the fact that the design for the Difference Engine was far 

ahead of its time. Although it was basically a da Vinci clone, full of toothed interlocking wheels and 

spindles, it was very large (Swade, 2000, estimates 25,000 components). This meant it had to be 

extraordinarily well-engineered, so as not to lock solid when applying the tens-carry operation to 

numbers containing lots of nines. More significantly, it was put together in an ingenious fashion to 

provide four main modules. Firstly there were stores for numbers, secondly there was a "mill" for 

doing calculations based on those numbers, thirdly there was a controller to ensure that everything 

was done in the right order, and fourthly (independently reaching the same conclusion as Müller, and 

conscious of de Prony's difficulties) there was also an automatic link to a typesetting module, so that 

the tables would be produced ready for printing. Babbage was also guilty of persistently upgrading the 

specification as new ideas occurred to him, and in 1834 he did so again, in order to incorporate 

Jacquard's proven ability to "pre-program" a sequence of instructions. Jacquard's cards would allow 

the sequence of the computation to be preset, thus acting as the first storable and reusable computer 

program. Babbage called this new machine the Analytical Engine. Sadly the Government was far 

less enthusiastic now, and adequate funding was not forthcoming. 

What happened next is an object lesson in how not to manage the process of innovation. Swade 

explains how the Swedish engineer Georg Scheutz, having read of Babbage's undertaking in 1834, 

and understanding the basic principles, was inspired to produce his own design for a difference 

engine. Scheutz, however, kept it simple, so that when the plans and prototypes were ready in 1837, 

he was able to set his 15-year old son Edvard to work at putting it together. It took father and son only 

six years to complete it (whereupon the British government promptly placed their own order for one). 

As Swade puts it, "a Swedish teenager had succeeded where the best of British had failed" (p197). 

Babbage's second machine was still incomplete at the time of his death in 1871, a quarter of a century 





later, although a working facsimile was built in 1991 to celebrate Babbage's bicentenary and is in the 

Science Museum in London. 

Between 1833 and 1852, Babbage was assisted in his work by Augusta Ada Lovelace (1815-1852), 

daughter of the poet, Lord Byron, and a woman of great influence in British society. A keen student of 

mathematics herself, Lovelace soon grasped Babbage's programming concepts, lobbied on behalf of 

the project in high places, and published a number of historically valuable technical memoranda. This 

enthusiastic contribution to the newly born software industry was honoured in 1979 when the US 

Department of Defence named their ADA programming language after her. 

4 - Computing 1805-1866 - The Electric Telegraph 

The story of the electric telegraph is usually dated to the 1830s, but to get the best flavour out of the 

later material it helps to go back some way before that. So we shall start in 1731, when the British 

polymath, Stephen Gray (1666-1736), who for several decades had been carrying out some of the 

very first empirical investigations of electrical phenomena, demonstrated that an electrical charge 

would readily conduct itself away from the place where it had been generated. Gray experimented 

with the transfer of charge along glass and metal rods, fishing poles, pokers, chains of people, thin 

brass wire, and silken thread, and made the arrival of the charge at the distant end visible by having it 

electrostatically attract slips of foil or paper. His longest successful transmission seems to have been 

886 feet along a length of cord suspended by silk threads. This series of experiments was followed in 

1751 by Benjamin Franklin's demonstration that if you flew a kite into an electric storm the lightning 

would discharge down a suspended wire in much the same way as "the virtue" would travel along 

Gray's rods and filaments, albeit with a considerably louder bang. 

It was against this background that in February 1753 a certain Charles Marshall published a 

theoretical proposition of no little foresight. This is what he wrote: 

"It is well known to all who are conversant in electrical experiments that the electric power may be 

propagated along a small wire, from one place to another, without being sensibly abated by the length 

of its progress; let, then, a set of wires equal in number to the letters of the alphabet be extended 

horizontally between two given places parallel to each other and each of them about an inch distant 

from that next to it. At every twenty yards' end let them be fixed in glass or Jewelers' cement to some 

firm body, both to prevent them from touching the earth or any other non-electric, and from breaking 

from their own gravity." (Marshall, 1753, cited in Naughton, 2002.) 

Naughton then goes on to explain Marshall's proposed method of operating the telegraph. Slips of 

paper bearing the letters of the alphabet were to be placed an eighth of an inch below suspended 

metallic balls at the receiving station and would be attracted to these balls as each wire was 

electrostatically charged from the sending station. It then only remained for a human operator at the 

receiving end to observe and record which letters moved, and in which order, for the message to have 

been successfully "telegraphed". 

It is not recorded that Marshall did more than short range experimentation with such an electrostatic 

telegraph, but he had awakened the interest of one of the principal users of signalling technology 

(such as it then was), namely the military. The next major development was by Citizen Claude 

Chappe (1763-1805) during the French Revolutionary War. Chappe's ocular telegraph consisted of 

large pointers mounted on gantries, whose angular position sequentially coded each letter of the 

message to be sent. Repeater stations were situated in direct line of sight every few miles, and at 





night lanterns were tied to the arms to maintain the service. There was an operational 15-station link 

between Paris and Lille (144 miles) by July 1794. A longer link from Paris to Toulon (475 miles) 

consisted of 120 towers and boasted a transmission time of about 12 minutes. A longer one still, from 

Paris to Milan, was under construction at the time of Chappe's early death, and before the method 

was rendered obsolete in the mid-nineteenth century by the various electromagnetic telegraphs (see 

below), the Chappe network had expanded to 556 stations (Kingsford, 1969) covering 3000 miles 

(Derry and Williams, 1960). 

Not wishing to be outdone by their enemy, Lord George Murray of the British Royal Navy invented the 

shutter telegraph in 1796. This consisted of a large shielded lantern revealed by six spatially 

separated slots. Light could be "sent" by opening the slots in appropriately coded combinations. The 

number of different signals depends upon the number of slots, and with a six-slot system this amounts 

to 63 combinations. The lights were "read" by observers down the line equipped with telescopes, and 

then retransmitted to "repeater stations" further down the line until the final destination was received. 

Fifteen hilltop signal stations were set up between London and Deal (70 miles), and the first message 

was passed on 27th January 1796, taking two minutes to send and acknowledge. A 10-station link 

was then established between London and Portsmouth (65 miles), and a 22-station extension from 

Portsmouth to Plymouth was operational in 1806 (which, incidentally, is why there are still so many 

Telegraph Hills in the south of England). The send-and-acknowledge time to Plymouth was three 

minutes. In the end, however, the Royal Navy remained unimpressed with the trials of Murray's 

shutter telegraph, and simply copied the French system. Admiral Sir Home Popham gave the gantry 

system the name "semaphore" (Greek sema - "sign", plus pherein - "to carry"), and an eight-station 

link (the two termini, plus six intermediates) opened between London and Chatham Dockyard on 3rd 

July 1816. (See Holzmann and Pehrson, 1994, for further details, if interested.) 

Of course it is the nineteenth century electrical telegraphy systems which sit most neatly on the route 

to modern computing, and the key invention here was the electromagnetic relay ..... 

Key Inventions - The Electromagnet (1825), the Electromagnetic Telegraph (1830), and the 

Electromagnetic Relay (1835): In 1825, the British amateur physicist William Sturgeon (1783-1850) 

noted that if an iron slug was placed inside a coil of wire its magnetic properties could be controlled by 

passing a current through the coil. It became an "electro-magnet" when a current was passed, and 

could be used to suspend large blocks of ferrous material, and it reverted to a useless piece of iron 

when the current was switched off, releasing whatever had been attracted to it. This discovery was 

then extended and applied by the American Joseph Henry (1795-1878) as an electromagnetic 

telegraph. Around 1830, Henry found he could significantly increase the output power of an 

electromagnet by using a number of separate sub-coils wired up in parallel, rather than a single coil. 

Using such equipment, he could deflect a suitably mounted piece of iron with enough force to sound a 

bell, and he could do this at a distance of one mile (Hochfelder, 1998). This form of remote reaction 

was used in the Wheatstone-Cooke telegraph (see next). By 1835, however, Henry had gone an 

important step further, using the deflected piece of iron to complete an electrical circuit of its own, so 

that a remote power source could be brought in or out of play on demand. Moreoever, that remote 

switch might itself power up a second electromagnet at an even more remote, third, station, which 

might switch in a third electromagnet at a fourth station, and so on, thus "relaying" the original signal 

as far as you wanted it to go. The electromagnetic switch was therefore commonly referred to as a 

"relay", because a string of them could pass signals the way athletes pass the baton in a relay race. If 

you now made the wiring of each constituent leg of the system long enough, then you had the basis of 

a very long distance telegraph. You could make information travel down a wire at the speed of 

electricity, and you could do it between cities, countries, and even continents. 





Three rival teams set out to make use of this new technology, and they ended up with two very 

different systems. In Britain, Charles Wheatstone (1802-1875) and William Cooke (1806-1879) 

patented the Five Needle Telegraph in 1837. This system consisted of six parallel wires connecting 

five local switches to five remote electromagnets. Each electromagnet acted upon a carefully mounted 

compass needle, and could flick this needle left or right from a vertical resting position. When this 

happened, the needle pointed to a matrix of letters set out on a backing panel, and, when two arrows 

were simultaneously keyed, the operator simply read off the single letter at the point of their 

intersection, and wrote it down (as it happened, the early systems would only cope with 20 letters, so 

operators had to guess at the missing ones, C, J, Q, U, X, and Z). The system was operational 

between Paddington and Slough railway stations by 1839, and members of the public were paying a 

shilling a time just to see it sending other people's messages. A public system was opened between 

London and Portsmouth in 1844. A Wheatstone "clone" system was developed in India by William 

(later Sir William) O'Shaughnessy, of the East India Company, who successfully demonstrated an 

experimental 13-mile of telegraph near Calcutta in 1839 (John H. Lienhard, "The Engines of our 

Ingenuity" website, University of Houston). 

In the US, meanwhile, Joseph Henry and Samuel Morse (1791-1872) had independently been 

concentrating their efforts on developing one-wire telegraphs. Henry's approach has already been 

described, and required that a receiving operator faithfully, but manually, record all arriving signals, be 

they delivered by bell or whatever. Morse, on the other hand, an art lecturer turned engineer, had 

resolved that the receiving apparatus should be a "recording telegraph" - it should automatically 

create its own permanent record of what had been sent to it. Morse had his original ideas in 1832, and, 

between 1835 and 1838, perfected an electromagnetic "register", capable of remotely producing 

momentary deflections in an otherwise straight pencil trace on a slowly moving spool of paper. This 

was soon replaced by an embossed trace on a paper tape which was advanced every time it was 

activated by the sending signal key (Pope, 1881), and eventually by a fountain pen tracer. 

The effective range of the trial system was not impressive, however, due to degradation of the signal 

over distances in excess of about one mile, and so Morse consulted a New York University colleague 

of his, a chemistry professor named Leonard Gale, who pointed him to Henry's previously published 

work on high-power electromagnets. Further development took place at the Speedwell Iron Works in 

Morristown, NJ, was funded by its proprietor's heir, Alfred Vail (1807-1859), and assisted by one of his 

technicians, William Baxter. By 1837, under Gale's guidance and thanks in no little part to Vail's and 

Baxter's enthusiastic development work, Morse had pushed the effective transmission range up to ten 

miles, and could cope with theoretically infinite distances by using repeater relays to refresh the signal 

every ten miles. Vail and Baxter were also instrumental in improving the sending key and the 

receiving register, and in perfecting the dot-dash code which still bears Morse's name (it is a matter of 

historical dispute whether Morse or Vail had the original idea). The system was demonstrated to the 

then President, Martin Van Buren, in 1838, and the code which went with it was patented in 1840. It 

took longer to train a good operator for the Morse system than the Wheatstone-Cooke system, but 

transmission speeds were higher (a skilled operator could transmit 40-50 words per minute). 

In 1843, Congressman Francis O.J. Smith, Chairman of the Commerce Committee, was taken into 

the partnership in return for speaking on its behalf in high places. His efforts bore fruit, and the US 

government granted $30,000 to build an experimental line from Washington, DC, to Baltimore, 40 

miles away. This was officially opened on 24th May 1844, just after the next critical invention had 

been made ..... 





Key Invention - Electromagnetic Synchronisation: Alexander Bain (1811-1877) was a selfeducated 

Scottish clockmaker and inventor, and in 1841 had the idea of using electromagnets to 

swing the pendulum in a clock. The power came on momentarily on one of the swings, and then went 

off automatically to allow a backswing. Properly adjusted, this system would deliver just enough 

impetus at just the right time to maintain the natural oscillation of the pendulum for as long as the 

battery held out. From 1843, Bain began to extend these techniques into a "chemical telegraph", a 

method of transmitting entire pages of text or pictures by progressive scanning (the same principle as 

the modern fax machine). At the heart of this system were two electromagnetic pendulums connected 

along the telegraph wire, so that the timing pulses from one of them could be applied to both. This 

clever arrangement allowed the two pendulums to be kept exactly in step at their respective stations. 

Bain then fitted the home pendulum with a bared electrical brush contact, and positioned the distant 

pendulum over a sheet of paper impregnated with potassium iodide solution (or similar), such that a 

visible decomposition took place whenever an electrical current passed through it. He then arranged 

for the home pendulum to swing back and forth across the face of a page of text typeset with metal 

type (or, if a picture, a copper etching thereof), so that the circuit was completed only where the brush 

contact touched the metal, and the carriage was automatically advanced fractionally after every 

oscillation. The receiving pendulum traced the corresponding contact points in blue on the 

impregnated paper, and also advanced the drawing carriage by the same distance after each 

oscillation, thus creating a two-dimensional facsimile copy. 

By 1846, the Morse telegraph service was operational between Washington, DC, and New York, and 

new horses were beginning to join what looked to become a very lucrative race. One of these was the 

Vermont inventor Royal Earl House, who patented a printing telegraph that same year. What House 

did was link two 28-key piano-style keyboards by wire. Each piano key represented a letter of the 

alphabet, and, when depressed, caused the corresponding letter to print at the receiving end. A "shift" 

key gave each main key two optional values. The working principle of the machine was that the 

rotation of a 56-character typewheel at the sending end was synchronised (no longer an impossibility, 

given Bain's work with the linked pendulums) to coincide with a similar wheel at the receiving end. If 

the key corresponding to a particular character was depressed at the home station, it actuated the 

typewheel at the distant station just as the same character moved into the printing position [readers 

familiar with the "daisywheel" word processors of the 1970s will recognise this layout immediately]. It 

was thus an example of a "synchronous" data transmission system. House's equipment could transmit 

around 40 instantly readable words per minute, but was difficult to manufacture in bulk. 

The House system was closely followed in 1847 by the Siemens automatic dial telegraph, and in 1848 

by the operational version of Bain's chemical telegraph (see above) and by a similar system 

developed by Frederick Bakewell. Bakewell's approach to full page scanning involved electrically 

insulating areas on a piece of flexible metal foil using shellac as ink. The prepared foil was then 

wrapped around a rotating cylinder, and a metal stylus tracked slowly around and along it, transmitting 

when it crossed a bared metal area and not transmitting when it crossed the shellac. A similar drum at 

the receiving end carried a sheet of impregnated paper, to receive the image. Bakewell demonstrated 

this system at the 1851 World's Fair in London, but for one reason or another it was another fifty years 

before there was much of a market for facsimile technology of this sort. 

In 1851, the New York and Mississippi Valley Printing Telegraph Company (renamed the Western 

Union Telegraph Company in 1856) was incorporated to exploit both Morse and House licences, and 

by the following year an intense rivalry had developed between it and the many other companies 

springing up. Indeed, there were now so many companies involved, that there followed a period of 

legal squabbling over patent rights between Morse, Henry, and Bain. The Morse patent at this time 





was owned by Morse, Gale, Vail, and Smith in equal shares, but the rival patents by House and Bain 

were beginning to make inroads into their business. Fortunately for the future Western Union, the US 

Supreme Court declared in 1852 that the Bain system had infringed Morse's patent. As a result, the 

Bain licences were suddenly worthless, and Western Union simply started to buy out or assimilate all 

its rivals. 

However, the House and Bain systems were followed in 1855 by yet another alternative system 

devised by David E. Hughes (1831-1900). Hughes used a system of vibrating springs to effect his 

synchronisation, and achieved considerable commercial success because his machine was quicker 

and more robust than House's, and its performance in the hands of experienced operators was 

relatively error-free. Hughes sold the rights to his system to a group of New York businessmen, who 

founded the American Telegraph Company in 1857. 

Progress was also being made in coping with increased customer demand without constantly laying 

new lines. Needless to say, this meant pushing increased traffic down the existing wires. Attention 

was therefore directed at the slow points in the existing system, and it turned out that the keying 

speed of the transmitting operator and the deciphering speed of the receiving operator were not the 

only limiting factors. For example, considerable time was also spent confirming the integrity of the 

connection before a transmission, and checking for its safe receipt afterwards. One solution was 

Morse's permanent record register, because this allowed receiving operators to be away from their 

equipment when messages arrived. They could, for example, be at their counter, selling a 

transmission in the opposite direction, or they could be decoding, and arranging for the onward 

delivery of, previous incoming messages. Other advances speeded up the sending process. One 

technique was to wipe a stylus across a set of long and short metal studs, so that the dots and the 

dashes for a particular letter would be generated automatically and without error. Another was to preenter 

the characters as perforations on paper tape and pass it over a brush contact reader which 

completed the sending circuit every time it encountered a perforation. The advantages here were (a) 

that each message could be prepared well before transmission (what we would today describe as "offline"), 

and (b) that several operators could afford to be coding simultaneously because tape 

transmission was much faster than manual keying. 

Nevertheless, the Holy Grail of telegraphy was not to send the messages faster, but to put more than 

one of them down the same wire at the same time. This was where the biggest money was to be 

made, and the first advance was made in 1852 by Moses Gerrish Farmer (1820-1893). He 

experimented with methods of "duplexing" each telegraph line, that is to say, methods of enabling two 

messages to travel along it simultaneously, in either the same or opposite directions, but without 

mutual interference. Much the same research was being carried out in Europe by the Viennese 

physicist, Julius Wilhelm Gintl (1804-1883), but the early systems remained impractical until further 

improved by Joseph B. Stearns in 1868, by Thomas A. Edison in 1872 (duplex), by Edison again in 

1874 (quadruplex), and by Jean-Maurice-Emile Baudot in 1874 (quadruplex). Indeed, the system is 

still being improved today (albeit the "wires" are now microwave satellite links), as modern networking 

technology spreads its tentacles ever wider, and offers ever greater bandwidth per unit investment [to 

feel this technology at work, and for a glimpse of some modern telecommunications technology. 

By the end of 1861, funded in accordance with the Pacific Telegraph Act, 1860, the Western Union 

telegraph linked the Pacific and Atlantic seaboards, and in 1866 Cyrus W. Field of the Atlantic 

Telegraph Company successfully laid the first transatlantic telegraph cable (with advice from an 

ageing Wheatstone), and the Western Union took over the American Telegraph Company, thus 





putting all the main telegraphic systems under the same owner. And just as Western Union thought 

they had it made, along came the telephone ..... 

5 - Computing 1867-1883 - Things Start to Speed Up 

The closing third of the nineteenth century saw a veritable explosion of human ingenuity. In the two 

years after the first transatlantic telegraph cable had been laid, the world invented not just the Nestlé 

baby formula and dynamite (so please check the labels carefully), but ticker tape and the QWERTY 

keyboard. Here is a timeline on the developments most closely related to computing, or the demand 

for it ..... 

1867 - Edward Calahan of the American Telegraph Company used a paper ribbon telegraph 

system to relay stock exchange prices from office to office in New York. The large loops of printout 

soon became popularly known as "ticker tape", and were then thrown out of skyscraper windows 

as confetti during "ticker tape welcomes". 

1867 - Elisha Gray (1835-1901) patented an improved telegraph relay, the first of his 70 or so 

inventions in the field of telecommunications. He went on in 1872 to found the Western Electric 

Manufacturing Company, and on 14th February 1876 to file application for his own version of a 

telephone (on the same day as, but slightly later than, Alexander Graham Bell - see below). 

1867 - Christopher Latham Sholes, a Milwaukee printer, invented the modern form keyboard 

typewriter. Unfortunately, its first users got so good at it that the keys kept jamming together, so ..... 

1868 - ..... Sholes invented the QWERTY layout keyboard to allow the commonest keys to strike 

from different angles, thus reducing the likelihood of their jamming when struck at speed. The first 

carbon paper followed in 1869. 

1868 - Joseph B. Stearns patented enough improvements to Farmer's duplexing techniques to 

make it commercially viable, thus effectively doubling the capacity of the existing telegraph 

network at a stroke. 

1870 - The bulk of the British telegraph system was transferred to the Post Office, putting it under 

government control (where it remained until British Telecom was privatised in 1984). 

1872 - Aaron Montague Ward founded the first mail order business in Chicago. 

1872 - Ex-telegraph operator Thomas A. Edison started to improve Stearn's duplexing equipment, 

and by 1874 had developed a workable "quadruplex" system supporting four operators at each 

end of the wire. 

1872 - Charles W. Seaton, chief clerk to the US Census Bureau, produced the Seaton Tabulating 

Machine, a method of entering high volume data onto a continuous paper roll through an access 

window. 

1873/4 - Remington and Sons, gunmakers of New York, on lean times now that the Civil War had 

ended, bought the rights to produce the Sholes typewriter, and marketed it as the Remington 

Model 1. Remington dominated the typewriter market for half a century, merging with the Rand 

Kardex Company (see below) and the Powers Accounting Machine Company (see below) in 1927, 

buying out the Eckert-Mauchley Computer Company in 1950, merging with Sperry Gyroscopes 

(see below) in 1955 (to form the Sperry-Rand Corporation), and with the Burroughs Corporation 

(see below) in 1986 (to form today's Unisys Corporation) [for a fuller history. 

1873/5 - Gray perfected his "electroharmonic" telegraph. This system used what would today be 

termed frequency-division multiplexing, a method whereby different frequency carrier waves are 

sent simultaneously down a single wire. 

1874 - Jean-Maurice-Emile Baudot (1845-1903) developed the Baudot printing telegraph, a 

system capable of sending the full alphabet, plus the numbers and the most common punctuation 

marks, using only a five-key keyboard. The system was adopted in 1877 by the French telegraph 





service, and improved versions were in use in the British Post Office around the turn of the century. 

The historical point about Baudot's code (also known as the International Telegraph Code No. 1) 

is that it was the first to use on-off binary electrical switching. A five-key keyboard actually allows 

only a 32-item codebook, so Baudot prefixed his transmissions with a reserved code indicating 

whether what followed was from the alphabetic list, or a second list comprising the digits and the 

punctuation marks. The code was particularly efficient in practice because it could be punched 

across a paper tape, rather than along it (as with Morse code), allowing all five bit settings to be 

read simultaneously [Baudot punched tape]. This tape format is important to the history of 

computing, because during World War Two it was used (a) in two of the Nazi's main cipher 

machines (the Lorenz SZ40/42 and the Siemens and Halske Geheimschreiber), and (b) in 

many of the Allies' experimental code-breaking computers [see Part 3]. The 32-bit coding 

system is also important to the history of cognitive science, because it was used in the first 

attempts at machine translation [see Part 4, Section 4.1]. Baudot also invented what would 

today be termed "time-division multiplexing" technology, that is to say, a method by which a 

number of operators could send their messages in microscopic "time slots", to be separated out at 

the receiving end. [For the British version of the Baudot codebook, see Hobbs (1999/2002 online, 

Figure 1), and for more on binary alphabets in general, click here.] 

1874 - The Scottish-American Alexander Graham Bell, inventor and teacher of the deaf, carried 

out his famous dead man's ear experiments [details], as a result of which he conceived the 

membrane-to-membrane concept of a talking telegraph, or "telephone". 

1875 - Frank S. Baldwin patented the pinwheel [technical detail], as an alternative to the da Vinci 

cogwheel for carrying out the tens-carry operation in mechanical calculators. This became the 

core component of the commercially highly successful Odhner and Monroe type of calculator, and 

subsequently of both the Lorenz and the Siemens and Halske cipher machines [see Part 3]. In 

1912, Baldwin teamed up with Jay Randolph Monroe to found the Monroe Calculator Company. 

The modern term "number crunching" comes from the often ominous grinding noise the pinwheel 

calculators made when doing large sums. 

1875/6 - Encouraged by an ageing Joseph Henry and assisted by the engineer Thomas Watson, 

Bell successfully transmitted his first natural sounds along a wire. The patent application was filed 

14th February 1876, and the equipment was demonstrated at the Philadelphia Centennial 

Exhibition later that year. Commercial development of the product began in partnership with the 

lawyer Gardiner G. Hubbard (father of one of his pupils, later to become his wife) and the 

businessman Thomas Sanders (father of another of his pupils). Not surprisingly, Bell's invention 

was poorly received by the already immensely powerful Western Union Telegraph Company, who 

immediately secured the services of Edison and Gray to try to devise a rival system 

(unsuccessfully, as it happened, for their attempts were eventually adjudged in breach of Bell's 

patents). 

1877 - Bell's company sold its first two telephones for $20. 

1878 - Thomas A. Edison invented the phonograph for recording speech and music, David E. 

Hughes followed up his success with the printing telegraph by inventing the carbon-granule 

microphone, and Bell Telephones opened its first telephone exchange at New Haven, CT. For its 

first 20 years, users had to gain the exchange operator's attention by hand-cranking a signal 

generator, and then name the party they wished to be put through to. The latest Remington 

typewriters, meanwhile, were now providing both upper and lower case letters. 

1878 - James Ritty, an Ohio restaurateur, suspicious that his staff were syphoning off the takings, 

got his brother John, a mechanic, to build him a sales accounting till, and the cash register was 

born. A machine, complete with pop-up cash display allowing the customer to see how much had 

been rung in, was patented 4th November 1879, and marketed as "Ritty's Uncorruptable Cashier". 

1879 - Frank W. Woolworth opened his first store. 





1881 - Dr. John Shaw Billings, a senior US Census Bureau statistician, looked at the clerks 

patiently entering data from 1880 census returns and reputedly remarked: "There ought to be 

some mechanical way of doing this job, something on the principle of the Jacquard loom" (Cortada, 

1993, p47). 

1882 - American Bell acquired the controlling interest in Gray's Western Electric, thus starting to 

"converge" telegraphy and telephony, and in New York the demand for office typewriting skills had 

become so great that the YWCA began offering training courses to that city's young women. 

6 - Computing 1884-1924 - Data, Data, Everywhere 

In the end, the vigour of the late nineteenth century industrial economies did so much to build the 

modern Western way of life, and prompted so many inventions, that a corresponding demand for 

computation in the financial world grew up. More and more inventions meant more sales - more cash 

across more counters, more cashings up and close of business reconciliations, more invoices and 

delivery notes, more tax returns, more stockchecks, and more internal and external financial controls 

behind the scenes. The sheer logistics of running all the new businesses was frightening, so that 

other new businesses were established to cater for the data processing needs of the existing ones. 

Here is a timeline on the developments most closely related to computing, or the demand for it ..... 

1884 - John H. Patterson (1844-1922) bought one of Ritty's uncorruptables (see above), liked it so 

much that he then purchased the manufacturing and marketing rights, and launched the National 

Cash Register Company (colloquially just "NCR", or "the cash") to market cash handling variants 

of adding machine technology to shopkeepers. In the late 1930s, Harry Williams and Joseph R. 

Desch added an Electrical Research Laboratory at Dayton, OH, to pursue military engineering 

contracts (Anderson, 2000/2002 online), and during World War Two this facility was involved 

in producing the US cryptanalytic computers known as "bombes". 

1884 - Herman Hollerith obtained his first patent in punched card technology. In 1890, he went on 

to start processing the data from the 1890 US National Census [full detail below]. 

1885 - William S. Burroughs (1855-1898) patented an adding machine which produced a printed 

slip as a permanent record of what had been put into it , and founded the American Arithmometer 

Company to exploit the product commercially. The company was renamed the Burroughs Adding 

Machine Company in 1905, had sold a million machines by 1928, and merged with the Sperry 

Corporation in 1986 to become the modern Unisys Corporation. 

1885 - American Bell was reorganised to form the American Telephone and Telegraph Company 

(colloquially, just "AT&T", or "Ma Bell"). 

1885 - Nathan B. Stubblefield (1860-1928), a Kentucky melon farmer turned inventor, tried his 

hand at telecommunications, and developed a workable voice and tone wireless transmitter. 

1885 - Albert Butz patented a negative feedback device for automatically controlling the 

temperature of central heating furnaces. The rights to Butz's invention eventually made their way 

to the Minneapolis-Honeywell Regulator Company in 1927, who then branched out into military 

command and control systems during the 1930s and 1940s, and into computer manufacturing in 

the mid-1950s (eventually becoming the Honeywell Corporation). 

1886 - John S. Pemberton invented Coca Cola, Gottfried Daimler invented the internal combustion 

engine, and modern life was upon us. 

1886 - In competition with Burroughs, Dorr E. Felt (1862-1930) invented the comptometer, a pushbutton 

calculator with a new form of carry mechanism capable of high speed addition of long 

columns of figures [picture]. This was well suited to, and therefore highly popular with, accounts 

clerks and cashiers, and was subsequently marketed by the Felt and Tarrant Manufacturing 





Company, who traded under that name until 1957 [further details]. Felt later commented that the 

ever-increasing demand for statistics was "turning men into veritable machines" (Cortada, 1993). 

1889 - Lyman Cornelius Smith (1850?-1910) turned his gun factory over to making the Smith 

Premier I full keyboard typewriter [picture]. This machine had been developed by one of his 

engineers, Alexander T. Brown (1854-1929), a remarkable man who eventually had around 300 

patents to his name, amongst them safety catches, breech mechanisms, and the pneumatic tyre 

(the rights to develop which he sold to the Dunlop Company). Brown presumably exerted some 

formative influence over a young engineer named Hannibal Ford, who was with the company from 

1905 to 1909, before leaving to join the Sperry Gyroscope Company (see below). 

1889 - Almon B. Strowger (1839-1902), a Kansas undertaker, reputedly concerned that a Bell 

telephone operator was secretly re-routing prospective clients (not the cadavers themselves, of 

course) to a business rival, devised the principles of the first successful automatic telephone 

exchange (others had been attempting to do the same for ten years beforehand, but performance 

was never satisfactory), in which subscribers were identified by number rather than name, and 

which would route from any one to any other by a number dialling mechanism. Strowger's ideas 

took a couple of years to prove their worth, but then remained the basis of telephone exchanges 

across the world for around 70 years. 

1895 - Reverend Thomas Oliver (having reputedly grown tired of writing his sermons by hand) 

improved the typewriter with the Oliver Model 1. 

1895 - Guglielmo Marconi (1874-1937) successfully sent a wireless transmission over a distance 

of two kilometers. He filed for a British patent in his system in 1896, and over the closing years of 

the century refined the technology to transmit over ever greater distances. In 1897, Marconi 

established the Wireless Telegraph and Signal Company in Chelmsford, and in 1899 maritime 

wireless started to save lives when the crew of a sinking lightship managed to use their set to call 

for a lifeboat. On 12th December 1901, the equipment successfully transmitted across the North 

Atlantic between Poldhu in Cornwall, and St. Johns, Newfoundland. For the impact of wireless 

telegraphy on military intelligence, see the historical subfiles to Part 3. 

1898 - James Henry Rand Snr. began to carve out a market for record card and loose-leaf 

business filing systems. His Rand Company flourished, and in 1908 he took on his newly 

graduated son James H. Rand Jnr. Following a disagreement, the son formed his own company, 

the American Kardex Company, in 1915, and for a while the two companies traded as rivals. By 

1925, however, tempers had cooled, and the two companies merged as the Rand Kardex 

Company, which in 1927 went on to merge with the Remington Company. Following the corporate 

restructurings already noted, the Rands' legacy should therefore be regarded as represented in 

the modern Unisys Corporation. 

1901 - Donald Murray, a New Zealand sheep farmer, devised a variant of Baudot's 1874 telegraph. 

It also used a five-key 32-item codebook, but the character-to-code assignment was different to 

Baudot's. With further amendments, the system was eventually standardised at the International 

Telegraph Alphabet, No. 2. [To see the ITA2 and related codebooks, click here.] 

1902 - Frederick George Creed (1871-1957) developed a "perforator" capable of punching Morse 

dots and dashes onto paper tape directly from a typewriter keyboard, a "reperforator" capable of 

receiving dots and dashes directly into paper tape format, and a printer which accepted said tapes 

and printed out the corresponding plain language. This enabled incoming messages to be printed 

"off line", that is to say, away from the receiving apparatus itself. This was a very cost-effective 

development, since it was quicker to print from tape than receive, so one printer could now service 

several reperforators. Creed and Company teleprinters grew in popularity and the product range 

continued to be developed until the 1960s. 





1903 - The Union Schreibmaschinen GmbH is formed as a subsidiary of AEG, one of the main 

players in the German electrical industry. The company will later rebrand its typewriter and office 

machinery ranges as Olympia, and become well known in both the US and Britain. 

1903 - Charles L. Krum, of the Western Cold Storage Company and Joy Morton of the Morton Salt 

Company were approached by a young electrical engineer named Frank Pearne for research 

assistance to develop a printing telegraph system. Krum made workshop space available for this 

work, and when Pearne subsequently lost interest in the project took it over himself. In 1906, he 

was joined by his son Howard Krum, and they were awarded various critical patents in 1907 and 

1908. By 1915, the Krum equipment was capable of linking a modified Oliver typewriter to an 

alphabetic printer at the other end of a telegraph line. The result was the 1924 Morkrum (= 

Morton-Krum) teletypewriter system. 

1904 - John (eventually Sir John) Ambrose Fleming (1849-1945), of University College London 

and the Marconi Wireless Telegraph Company, invented the thermionic valve. Subsequent 

developments by the Americans Lee de Forest (1873-1961) and George Washington Pierce 

(1872-1956) made valves vital components in wireless, television, and computing hardware for the 

next half century. 

1907 - James Powers, encouraged by the US Census Bureau to compete with Hollerith's 

tabulating system (see below), developed rival (and often better) equipment. As a result, the 1910 

census ended up being split between the two contractors. The Powers Accounting Machine 

Company became part of Remington-Rand Corporation in 1927, and is thus part of the modern 

Unisys Corporation. 

1908 - Elmer Ambrose Sperry (1860-1930) perfected the gyroscopic (ie. non-magnetic) marine 

compass, thus improving navigational accuracy in ships built of iron and steel. His chief engineer 

was Hannibal Choate Ford [previously with the Smith Typewriter Company (see above), but 

destined to found the Ford Instrument Company in 1915 (see below)]. Sperry marketed these 

systems as the Sperry Gyroscope Company, until merged with Remington-Rand in 1955 [more 

company history]. 

1908-1910 - In an attempt to improve the accuracy of near-polar navigation (for which magnetic 

compasses are notoriously unreliable), the Anschütz Company of Kiel, Germany, produced a 

gyro-compass of their own in competition to Sperry. However, trials revealed that the system 

suffered inaccuracies due to "rolling error", and so could only be reliably used in ships in port. A 

1912 upgrade cured this fault, and greatly improved sales performance. Anschütz are now part of 

the Raytheon Corporation. 

1910 - Edison applied for his 1328th, and final, patent. 

1913 - Arthus Hungerford Pollen perfected a system of "director-controlled" naval gunnery for 

capital ships. 

1915 - Hannibal Ford resigned from Sperry Gyroscopes and set up his own company, the Ford 

Instrument Company, specialising in naval fire control systems. Its first success was the Range 

Keeper Mark 1, an analog computing system capable of tracking, predicting, and compensating 

for the natural movements of the ship it was fitted in [picture and specification]. This equipment 

was installed in 1917 on USS Texas, and heralded an era of greatly improved naval gunnery 

(Clymer, 1993/2002 online). In the early 1940s, Ford's company worked with Bell Laboratories to 

develop the altitude computation unit on the Bell No. 9 Flak predictor (see Part 2). 

1916 - Edward E. Kleinschmidt (1875-1977) applied for a patent for a Baudot code teleprinter for 

use on multiplexed circuits. This proved to be reliable heavy duty piece of kit, but much of what 

Kleinschmidt wanted to do next was controlled by patents already held by the Morton and Krum 

team (see above) [patent history]. It therefore made commercial sense for the two organisations to 

merge, which they did in 1925 as the Morkrum-Kleinschmidt Corporation, adopting the brand 

name "teletype" for its products. The company renamed itself the Teletype Corporation in 1929, 





and was taken over by Bell Systems in 1930. Baudot telegraphy of this sort is important to the 

history of computing, because teletypes became so widespread during the 1930s that 

many of the experimental computers built during World War Two relied extensively upon 

scavenged teletype components for their input and output peripherals [see Part 3]. 

The greatest single story from this period, however, is that of the development of punched card 

technology. This begins in 1884, when Herman Hollerith (1860-1929), a US Census Bureau civil 

servant and mechanical engineer, obtained his first patent for a punched card data recording 

system ..... 

Key Invention - The Hollerith Punched Card: This was a thin rectangle of card, with characters and 

numbers printed on it. To service these, Hollerith supplied a keyed punch, capable of punching holes 

through selected character positions on the card. If you moved the punch carriage across to column 1 

and keyed "1", a hole would be punched through character position , and so on. 

Many prospective layouts were tried out, beginning with 24 columns of 12 vertical positions, but one of 

the most successful layouts was the 1928 IBM variant, which used 80 columns of 12 vertical punching 

positions per column. The 12 vertical positions were defined as the digits 0-9, plus two additional 

positions known as X and Y. The clever arrangement was than 0-9 on their own meant 0-9, but 1-9 in 

combination with 0, X, or Y, meant one of the letters A-Z. This meant that a total of 36 characters 

could be squeezed out of only 12 punch positions. To see a completed Hollerith card, click here. 

Completed cards thus "stored" the keys which had been pressed, and if you keyed business data then 

the resulting patterns of holes acted as a business data store (the Falcon-Jacquard loom cards, by 

contrast, while they might have looked similar, were instruction stores rather than data stores). Three 

other important factors also contributed to the system's success ..... 

1. The system allowed/encouraged single-character "coding" of otherwise complex data attributes. 

Thus to respond to questions about ethnicity, for example, you could enter "1" in a predesignated 

data column, instead of typing out "WHITE EUROPEAN", say, in full. The more there was to type 

in conventional format, the greater the saving when coded in this fashion. The codes themselves 

were, of course, totally arbitrary, and would be arrived at partly through design and partly by 

experience. 

2. The cards were selectable on the basis of one or several specific column values. This allowed 

data cards, once coded, to be selected to a precise parameter mask (such as all unemployed 

white males in Kansas). The machines which carried out this process were known as "sorters", 

and the "selected record" approach is now the basis of "structured query language" interrogations 

of modern computer databases. 

3. The cards were machine readable. This allowed them to be input into large reader-calculator 

machines, where cumulative totals could be computed (such as the total number of children in the 

care of our unemployed white males in Kansas). The machines which carried out this process 

were known as "tabulators". 

As noted in the timeline above, it was actually a colleague of Hollerith's, Dr. John Shaw Billings, who 

had the basic punched card idea around 1881, but he declined the opportunity to develop a product to 

go with the idea. Hollerith accordingly went ahead on his own, and by 1889 had enough experience 

for his Tabulating Machine Company to win the contract to process the data from the 1890 US census. 

The Census Bureau, for their part, was quick to buy, because it had only just finished manually 

processing the 1880 figures! All went perfectly, and within a year the machines had tabulated over 62 

million US citizens (Cortada, 1993). Hollerith went on to win the census contracts for Austria, Canada, 





and Norway in 1891, and Russia (a massive 129 million citizens) in 1897. He was also quick to open 

the technology up to the larger private corporations for their operational and business intelligence 

needs. The New York Central Railroad began processing their freight-handling paperwork in 1895. 

The 1900 US census earned a gross revenue of $428,000, and in 1911 Hollerith's company merged 

with several others to become the Computing - Tabulating - Recording Company (CTR). This was the 

first of many commercial successes, and the punched card system dominated commercial data 

processing until well into the 1950s. [In fact, British Telecom were still arranging for programming 

trainees to use a manual card punch into the 1980s - if only for experience's sake. The present author 

used one in August 1980, and it worked perfectly (but painfully slowly).] In 1914, Thomas J. Watson 

joined CTR from NCR as general manager, and in 1924 Watson had CTR renamed as part of a 

corporate makeover, choosing the name International Business Machines (IBM), and we shall be 

hearing much more about them in Part 2 ..... 

Part 2 - A Brief History of Computing Technology, 1925 to 1942 

1 - The Data Processing Industry in 1925 

In Part 1 we saw how the data processing industry developed out of the calculating aids of the 

seventeenth century into the Scheutz Difference Engine of the mid-nineteenth century, and thence 

into the cash registers, comptometers, and punched card sorters and tabulators of the late nineteenth 

century. We have also seen how the late nineteenth century was a period of exponential economic 

growth, in which it was not uncommon for companies formed merely to service this or that new 

invention to find themselves major international corporations a couple of decades later. Indeed, the 

sheer pace of progress regularly took even the experts by surprise - Burroughs, for example, sold 

15,763 machines in 1909 alone, twice what their founder had originally estimated the total worldwide 

market would ever be (Cortada, 1993). 

Let us therefore pause for a moment to summarise the situation as it stood in 1925, the year after 

Herman Hollerith's Computing, Tabulating, and Recording Company renamed itself IBM. At the 

household end of the economic spectrum, we find that AT&T and the various European Post Offices 

had made integrated telephony and telegraphy services an everyday purchase, that the likes of 

Remington, Oliver, Smith, and Underwood had done the same for typewriters, and that Marconi, RCA, 

and Westinghouse were well on their way to doing the same for radio. Outside the household, 

calculators made by the likes of Odhner, Monroe, and Marchant were helping small retailers do their 

accounts and research academics analyse their data, and at the heavy end of the economy, 

corporations like IBM, NCR, and Burroughs were helping to mechanise commercial and governmental 

structures worldwide. It was a world where the man in the street could now communicate by pressing 

a few keys and turning a few knobs here and there, and where new data was allowing managers "to 

make better decisions earlier based on more facts" (Cortada, 1993, p35). 

Yet the pinnacle of corporate data processing remained nothing more sophisticated than the punched 

card suite, and if we look at all this activity with a more critical eye, we can see a clear pattern to 

where data processing technology was flourishing and where it was not. Specifically, we can identify 

two heavily selling market sectors in the 1920s, as follows: 

(1) High Street/Office Batch Processing: In this sector we have small-to-medium sized enterprises 

(SMEs) whose investment in new technology might run to a bottom-of-the-range NCR (or rival) cash 

register, a Burroughs (or rival) office comptometer, and a few typewriters. Company accounts were 





probably drafted manually, computed by comptometer, checked over by the company chief clerk, and 

then produced in neat copy on a typewriter. 

(2) Corporate, Military, and Governmental Batch Processing: Under this heading, we have such 

applications as the actuarial tables used in insurance, financial analysis, large billing runs, large 

inventory replenishment runs, etc., military gunnery tables, tide and navigation tables, census data, 

and so on. 

Key Concept - Batch Processing: These, note, were both "batch" applications. This means that 

data was time-buffered - it was not processed as it became available, but was allowed instead to 

accumulate until enough similar inputs could all be processed at once. The justification for this was 

(and, with the right sort of data, still is) that significant economies of scale will often result, thus 

reducing unit processing costs (metaphorically speaking, there is only a fractional additional cost in 

running your dishwasher with a batch of 100 items in it, compared to running it with only one item in it). 

With an SME, the batch in question might be a day's sales, or a week's overtime claims, or a month's 

stock replenishment requests, and with a government department, it might be anything from a 

trayload of Hollerith cards to a lorry load (or potentially several lorry loads) of census returns. 

The predominance of batch processing systems was, of course, technology-driven: it was all that the 

available systems - the sorters and tabulators of your average corporate punched card department - 

could cope with, and it failed to take any account whatsoever of three as-yet-vaguely conceived 

additional areas, namely real-time computing, on-line computing, and personal computing, as now 

profiled ..... 

Key Concept - Real Time Processing: Processing is deemed to occur in "real time" if and when the 

decision making element of the machine (what Babbage called "the mill") is free to respond to a 

demand (a) instantaneously, and (b) without interruption. It is the sort of computing needed to 

control any sort of system in motion. The principal method of real time control in 1900 was to have 

a dedicated human operator at the system's (real or figurative) helm. By 1945, however, many 

functions were being carried out automatically by analog computers linked to servomechanisms, and 

modern real time systems (albeit they are now heavily digitalised) have become the mainstays of the 

aerospace [to see a typical "fly-by-wire" system, click here], healthcare [to see a typical "treat-by-wire" 

application, click here], and military cybernetics industries. 

Key Concept - On-Line Processing: Processing is deemed to be "on-line" if and when the decision 

making elements of the machine are free to respond with only a few seconds delay to a particular 

enquiry or update. The textbook examples here are bank or stock balance enquiry, funds transfer, 

hotel, theatre, and travel ticket booking systems, and Internet shopping. In this sort of application, 

customers (a) have a particularly subjective definition of "now" (they will wait anything from one or two 

seconds for a bank balance enquiry, to a minute or so for a theatre or airline booking), (b) need to 

know present availability of the target resource with 100% confidence, and (c) need to have 

unchallenged access to that target resource during the chosen timeframe. On-line processing is not 

available with any form of record card system, however, because it is totally impractical to go directly 

to a particular card in a particular card set. Indeed, this problem was not solved until 1961 [see Part 5 

(Section 3.1)]. On-line processing is sometime referred to as "on-line transaction processing" (OLTP) 

because of the time-encapsulated nature of the exchange between the user and the machine. 

Key Concept - Personal Computing: Processing is deemed to be "personal" if and when users have 

access to their own hardware (and do something with it other than play computer games). This sort of 





computing therefore had to wait until mass production techniques brought equipment prices down. 

The first desktop personal computers started to appear on the market in the early 1980s, the first 

laptops about a decade later, and the Internet/multimedia machines in the mid-1990s. 

As far as the 1920s were concerned, therefore, it is probably fair to conclude that the data was there 

to be processed, but the computing machinery available was too slow and too inflexible to service the 

full richness of the demand. To understand what happened next, we need to consider a detailed case 

study, and one of the most generally informative of these has to do with the problems of artillery 

gunlaying in general, and anti-aircraft gunlaying in particular. 

2 - Computation in Ballistics 

Now the basic problem for artillery gunlaying is gravity. Put simply, your cannon ball wants to fall to 

earth as quickly as it can, and it is your job as gunlayer to combine the effects of gravity with some 

forward motion so that the point of impact of the projectile is also the point of maximum destruction to 

your enemy. To further complicate matters, the effect of gravity is to give any projectile a downward 

acceleration, whilst its forward motion remains approximately the same throughout the flight. This is 

what gives the resulting trajectory its characteristic "dipping curve" shape, the correct name for which 

is a "parabola". The science of gunlaying is therefore to tilt the gun barrel upwards or downwards from 

the line of direct sight, until it rests at a tangent to the parabolic trajectory which passes through both 

gun and target. Corrections then need to be made for wind resistance (up a touch), sidewinds (left or 

right a touch), headwinds (up a touch), tailwinds (down a touch), targets uphill relative to you (up a 

touch), and so on. The dimensions of the parabola will also vary according to projectile weight, the 

weight and chemical condition of the propellant charge, the goodness of fit of the projectile into the 

barrel (up a touch if the gun is starting to wear, or has been firing for some time, and has got hot). 

Given all this mathematics, it will come as no surprise to learn that these calculations were beyond 

individual artillerymen, especially in the heat of battle. As a result, the earliest cannons were simply 

pointed by eye and adjusted as necessary if they missed (the British took three "bombards" with them 

to Crécy in 1346 just to frighten the enemy's horses). The situation did not improve much until an 

Italian mathematician named Niccolo Tartaglia (1506-1559) wrote a monograph on the subject, and 

devised some quick and easy field procedures ..... 

Key Invention - Tartaglia's Quadrant (ca. 1545): In an attempt to introduce some discipline into the 

setting of an elevation, Tartaglia invented the gunner's quadrant. This consisted of a short plumbline 

suspended across a graduated 90-degree quadrant. The quadrant itself was fixed to the gun in 

question by a muzzle plug, so that as the barrel was raised and lowered the plumbline crossed the 

quadrant at a different point [for a helpful picture of the quadrant in use, click here or here]. The 

elevation could then be read off as the number of degrees marked at this intersection point, "point 

blank" being the true horizontal. In the meantime, the gun commander had estimated the range to the 

target and could set the corresponding required elevation from a look-up table or pre-drawn graph 

supplied with the gun. We shall refer to these graphical and tabular aids henceforth as "ready 

reckoners". 

Quadrants were most effective when helping siege artillery destroy fortifications, because they 

allowed the precise resetting of an elevation after each shot. However, the lighter guns were still 

largely laid by the experienced eye, because the fact that they were intended to engage more mobile 

targets interacted unfavourably with the fact that the decision making required by Tartaglia's system 

itself took time. If you had a moving target, you had to know how long it was likely to take between 





reading your instruments and the projectile arriving at the end of its travel. Just as in clay [skeet] 

shooting, you must aim ahead of your enemy by a carefully calculated amount, a cunning little trick 

which goes by the names "deflection shooting" or "leading the target". This trick does not just take 

a lot of learning, but needs to be done in the forwards-backwards and leftwards-rightwards 

dimensions simultaneously. The forwards-backwards deflection is known as the "elevation lead", 

and the leftwards-rightwards deflection is known as the "azimuth lead". You no longer needed a 

gunsight, in other words, you needed a "fire control system", complete with your own computer. 

By the Napoleonic era, ready reckoner techniques were at work in both (a) the use of field artillery 

against infantry or cavalry formations manoeuvering on land (where the ground speed of the target 

can be anything from 2 to 20 mph, and where relative topographical elevation can change by the 

second), and (b) the use of shipboard artillery (where the ground speed would normally be 5 to 8 mph, 

but where your own gun platform would also be pitching, rolling, and yawing into the bargain). [For an 

example of the effectiveness of shipboard artillery against slow moving infantry formations on the flat, 

see the role played by the USS Louisiana at the Battle of New Orleans, 1815, on our webpage on 

military disasters.] However, as with computing and many other things, the period between the Battle 

of Trafalgar (1805) and the First World War was one of unremitting innovation for the artillery world, 

and the following major changes may be identified: 

(a) Calibre and Range: A typical heavy naval gun at Trafalgar was the carriage-mounted British 32pounder 

black powder muzzle loader. This had a 91/2 foot barrel, a 32-pound solid projectile, a shot 

diameter of 6.4 inches, and an effective range of about one mile. By 1915, its equivalent would have 

been the 1913-designed 15-inch Mark 1 turret-mounted breech loader, with a 55-foot 100-ton barrel, a 

1-ton explosive projectile, a shot diameter of 15 inches, and an effective range of 16 miles. 

(b) Speed of Firing: The rate of fire of our 1805 32-pounder was around one shot every two minutes; 

that of our 1915 15-inch Mark 1 was around one shot every minute. The critical inventions here were 

the integration of shot and cartridge, and the breech mechanism. 

(c) Rangefinding: Although it is possible to range monocularly using a telescope, by relying on the 

amount of focusing required to give a clear image, the critical development under this heading was 

the binocular optical rangefinder. This was a contraption rather like a pair of binoculars, but with the 

front lenses anything from a few centimeters to several meters apart [to see a picture of a German 4metre 

rangefinder of 1940s vintage, click here]. The user stood at an eyepiece halfway along the 

telescope tube and saw two half-images from the lens and prism systems - the "objectives" - either 

side of him. These images would only perfectly superimpose, however, when the two objectives were 

angled slightly inwards, and, just as with biological binocular convergence, the degree of "nasal" 

rotation is an analog of the target's range. The adjustment angle was therefore factory-calibrated for 

reading off in meters distant. Such instruments were manufactured by the Glastechnische 

Laboratorium Schott & Genossen (later Carl Zeiss, Jena) from 1894, and by Barr and Stroud in the 

UK from 1907. 

(d) Naval Fire Control Systems: Knowing your enemy's range is only one factor in successful naval 

gunnery. For each selected target, your own speed and heading need to be computed against target 

speed and heading, and due allowance made (a) for elevation and azimuth lead, and (b) for any 

pitching, rolling, and yawing of the gun platform. The solution was to bring together into a single fire 

control computer a number of "follow the pointer" analog systems, each coping with one of the 

sighting or stabilisation parameters. Such systems were developed during, and fairly effective by the 

end of, the First World War. The US effort in this area was led by the Sperry Gyroscope Company 





(see under Elmer Ambrose Sperry in Part 1) and the Ford Instrument Company (see under Hannibal 

C. Ford in Part 1). Ford's Range Keeper Mark 1 [picture and specification] was installed in 1917 on 

USS Texas, and heralded an era of greatly improved naval gunnery. 

The arrival of the aeroplane as a weapon of war ended any residual reliance upon a gunner's 

experience and good judgement. Not that the principles themselves had changed, for in his 

monograph on the history of anti-aircraft (henceforth "flak") technology, Müller (1998) was still 

explaining that "in order to hit a target moving in a free space, [estimations] have to be fed to the gun 

for the point in space which would be occupied by the target at the end of the artillery shell's flight 

time" (p3). But there are estimations and there are estimations: it is one thing to shoot at a formation 

of cavalry two hundred yards across and only two hundred yards away, and quite another to shoot at 

an aeroplane a few yards across and several thousand yards away. The point is that deflection 

shooting becomes progressively more difficult as the target's range goes up, for the simple and 

mathematically inescapable reason that the projectile's time of travel also goes up. This both 

magnifies any sighting errors already made, and affords the target a chance to take evasive action. 

For example, it took around 20 seconds for a Second World War 88mm shell to reach its practical 

operational ceiling of 20,000 feet (roughly four miles), within which time an aircraft moving at 250 mph 

would itself have travelled well over a mile. 

The experience of two world wars brought two popular solutions to the deflection shooting problem in 

air defence: one was to shoot off lots of small cheap bullets and rely on sheer weight of numbers to 

give you the occasional direct hit, and the other was to shoot fewer, but bigger and more expensive, 

explosive shells, engineered to go off near the target and inflict blast or fragmentation damage. In 

other words, if a direct hit was going to be a practical impossibility, you needed to capitalise on your 

near misses as well. The first option was the method of choice against low-flying aircraft, the latter the 

method of choice against high-flying, BUT it relied upon an accurate time fusing system, as now 

described ..... 

Key Invention - Time Delay Fusing: A time fuse is a mechanism for the timed detonation of an 

explosive projectile while still in the air, and in the absence of direct contact with the target. 

Because the resulting blast comes vertically downwards, this has always been the weapon of choice 

against defensive trench systems. Time fuses were in common use for large calibre mortars as far 

back as the late 16th century, and were then introduced into the lighter field artillery when an 

artilleryman named Henry Shrapnel invented his eponymous case shot in 1784. The early time fuses 

were simply lengths of paper or cloth rolled around a trickle of black powder (much like an Old 

Holborn roll-up, or spliff). You knew from past experience how fast this sort of fuse burned, so you cut 

off just enough of it to provide the intended delay, inserted one end into the main charge, lit the other, 

and kept your fingers tightly crossed it did not detonate prematurely. The delay was known as the 

"fuse burn time". World War One time fuses used much the same basic technology, save that the fuse 

was now a piece of clockwork, factory-machined into the shell, and its "burn time" was externally 

adjustable by the guncrew immediately prior to loading. The mechanism had to be extremely robust to 

withstand both the momentary linear acceleration when fired (typically well in excess of 10,000 "g") 

and the centrifugal forces of spinning at (typically) well in excess of 20,000 rpm while in flight. The 

systems invented to cope with determining the required fuse burn time from sighting data were known 

as "predictors". Time fusing was largely replaced in flak systems by the introduction of the radio 

proximity fuse towards the end of the Second World War - see next Key Invention panel but two. 





Now we can actually learn a lot about computing by considering the prediction problem in some detail. 

If you were ever put in charge of an anti-aircraft gun, for example, then ideally you would need to 

know the following things about an enemy aircraft travelling in a straight line ..... 

its bearing (ie. the direction to the target relative to true north on the standard 360-degree 

compass dial) 

its current height, plus its rate of climb or descent to give a predicted height 

its horizontal range, plus the two horizontal velocity components to give a predicted horizontal 

range and current heading (ie. the direction the target is moving in, after allowing for wind drift, 

again measured on the standard 360-degree compass dial). 

its azimuth (ie. the direction to the target relative to the axis of your gun, which need not itself be 

facing north, also on the standard 360 degree scale) 

Example: If your gun is facing east, and the target is in front of it, then that target's bearing is +90 o 

(because it is to the east of you), but its azimuth is zero (because your gun is already pointing at it); its 

heading could, momentarily, be any value between 1 o and 360 o . 

Unfortunately, some of the most important values cannot accurately be observed, so either you have 

to guess at them, or you have to compute them from what you can observe, according to the rules 

and equations of three-dimensional geometry, algebra, and trigonometry. Moreover, velocity and 

heading can only be computed if the rate of change of other variables is known, so you will have to 

repeat some sighting values after a fixed time delay, using a stopwatch. So basically you are dealing 

with the following four points in three-dimensional Cartesian space: 

Coordinates #1: Where you are, and what direction the axis of your gun is aligned to. 

Coordinates #2: The location of the target at T1, the first click of the stopwatch. To ascertain this, you 

have to focus a combined theodolite-rangefinder on the target, and read off the scale values for the 

bearing (horizontal scale), angle of elevation (vertical scale), and, assuming you have a binocular 

rangefinder, range (binocular convergence scale). 

Coordinates #3: The location of the target at T2, the second click of the stopwatch. To ascertain this, 

you need to repeat your readings after a standard stopwatch delay. The difference between the two 

sets of values then allows the target's three velocity components to be calculated, and from that a 

reasonably accurate heading and ground speed. 

Coordinates #4: The (future) location of the target at T3 (because this is where you are going to aim 

your gun). Setting T3 needs to take into account both fuse setting and fuse burn time. It might take 

three or four seconds to load the shell into the gun, and then of the order of 20 seconds in flight. 

To make matters worse, the two-click system is only theoretically useful while the target aircraft 

remains travelling in a straight line. A "three click" system, in which three timings are taken, offers the 

additional ability to deal with curved flight, but requires quadratic curve fitting in all three key 

dimensions, and for a long time that was beyond the available technology and all but professional 

mathematicians. The calculations also rely heavily on a process known as "integration", one of the 

major subskills of differential calculus. Müller (1998) describes how German air defence technologists 

started to deal with these problems during the First World War. The early systems, not surprisingly, 

were quite basic ..... 





Key Invention - The Peres Predictor (1915): This was basically a Zeiss telescope-theodolite on a 

tripod. By taking a direct sighting on the target, it could give angles of elevation and azimuth, and by 

doing the same after a set number of seconds measured on a stopwatch the operators could 

extrapolate a suitable burn time and angles of elevation and azimuth. The apparatus was 

complemented in 1916 by a set of command charts (ie. ready reckoners) from which burn time and 

elevation could be read directly. 

Key Invention - The JAKOB Command Table (1917): The JAKOB command table was introduced 

in 1917, and was again basically a Zeiss telescope-theodolite. Here, however, the ready reckoner 

element was integrated into the main carcase of the instrument as an output display panel, rather than 

as a separate set of ready reckoners. This therefore involved internal gearing according to the 

principles of analog computation already described in Part 1. 

Further attempts at mechanising flak gunlaying took place during the 1920s, and the solution in all 

cases was to rely on an analog computer - "a system to represent the problem whose solution is 

required [and whose behaviour] then yields the solution in terms of the measured values of various 

output quantities" (Williams, 1961, p9). Known generically as "follow-the-pointer" systems, analog 

computers consisted typically of a large box of interconnecting shafts, cranks and cams, differential 

gears, torque amplifiers, clutches, pulleys and cords, potentiometers, and/or spring-loaded 

mechanisms, which were used to estimate the solutions to complex equations. 

Key Concept - Follow-the-Pointer Servocontrol: The idea of mechanisms capable of following the 

movements of a pointer at a distance emerged in the mid-nineteenth century. For example, in the 

1847 Siemens automatic dial telegraph [picture], the remote-station telegraph pointer automatically 

rotates to the same angle as that to which the home-station pointer has been set, thus allowing the 

home operator to "spell out" a message letter by letter. The principle is also seen at work in the 

"steam steering engines" of the 1860s. Such a system was developed by McFarlane Gray in 1866 for 

the SS Great Britain. Firstly, a rudder deviation was chosen by the helmsman and set as a pointer 

deflection on the control apparatus. This then released steam to a rudder servomechanism to do the 

heavy work, and, as the rudder itself moved, a second pointer was gradually rotated until it matched 

the first, whereupon the steam supply to the servomechanism was shut off (Bennett, 1979). [For more 

on the history of analog systems, see Mindell (1995), and for more on the basics of cybernetics, see 

Smith (1997).] 

The US effort in this area was again led by Sperry Gyroscope and the Ford Instrument Company. 

Drawing on their experience with World War One naval fire control systems, Sperry and Ford 

developed equivalents of the German equipment mentioned above, and in the period between 1927 

and 1935 successfully developed a workable integrated flak control system. The culmination of this 

eight years of experimentation was the T-6 AA Director System. The 1935 German system was 

generally similar to the US system. Each flak battery consisted of a ranging station equipped with a 

four-metre binocular rangefinder, a command unit equipped with an analog predictor, and the guns 

themselves. The following is from Müller (1998), and describes how the four-man crew of the 

rangefinder (numbered E, for Entfernungsmesser, 1 to 4) interacted with another nine men on the 

command post analog computer (numbered B, for Befehlstelle, 5 to 13) to come up with the required 

gun and fuse setting parameters: 

"After the E2 [lateral tracker] and E3 [elevation tracker] sight operators determined a target's height 

and bearing, the E1 [sergeant] could plot its range [] B4 passed data via voice radio to the B7, B5 

controlled the computer laterally [by turning an adjusting handwheel], B6 controlled it vertically [by 





turning a second adjusting handwheel]. Speed of revolution [of the internal mechanism], controlled by 

the adjusting gears, corresponded to the azimuth and elevation lead [read from output dials at the rear 

and right of the apparatus respectively]. The azimuth lead was passed by the B8, who kept the pointer 

on the azimuth tachometer aligned with the null marker; the B9 did the same for the elevation 

tachometer. The B10 passed the range lead using the range fluctuation speed tachometer. The B11 

gave the firing azimuth, the B12 the barrel elevation, and the B13 the fuse setting by voice radio to the 

guns." (Müller, 1998, p13.) 

Each gun in the typically four (later eight) gun battery was manned by a further nine gunners 

(numbered K, for Kanonier, 1 upwards). K1 (the height man) hand-cranked the gun up to the angle of 

elevation specified by B12, K2 (the azimuth man) hand-cranked it round to the azimuth setting 

specified by B11, and K6 set the fuse to the value given by B13. Finally, the guns were loaded and 

fired in as short order as possible. The other K-roles were manual handling. Warning bells from the 

command post synchronised the gunners from one end of the battery to the other, and, typically, all 

the guns in the battery fired to the same coordinates at the same command (as, indeed, could the 

guns of neighbouring batteries, if linked by telephone). It thus took a cooperative processing network 

of at least 25 highly trained and totally focused human minds, aided by the best optics and mechanics 

money could buy, to aim what was effectively a single gun, and it still took an average 4000 shells to 

down each Allied plane! 

ASIDE: It was a military secret at the time, of course, but the allied bombing fleets had been 

instructed to fly straight and level on their final approach to their target. This had been judged the 

lesser of two evils, because rapid manoeuvering of large formations of aircraft invited collisions. The 

relatively poor flak performance was therefore not influenced by any significant changes in altitude or 

heading: it was all down to inaccuracies in the basic rangefinding and prediction equipment, and poor 

operating procedures. 

Similarly, by 1939, the British Royal Artillery's Air Defence Command was also relying on optical 

tracking and altitude finding, supported by analog computation of azimuth, elevation, and fuse delay, 

followed by manual gunlaying to those parameters (Williams, 1961). Again about a dozen highly 

skilled technician-operators (frequently women) were needed per battery. 

The Second World War brought a further wave of improvements. An advanced US system, the "M9 

Electrical Gun Director" was proposed in June 1940 by David B. Parkinson and Clarence A. Lovell of 

Bell Labs' Murray Hill facility [for the story of Parkinson's dream, click here]. The proposal was 

accepted in December 1940, and the resulting development project occupied some 400 Bell 

engineers, with assistance from the Ford Instrument Company and the Teletype Corporation on the 

altitude converter. Colonel H.B. Ely liaised. A prototype was delivered for evaluation in November 

1941, and production approval given in the autumn of 1942. Full production was contracted to the 

Western Electric Company. Here is Bell's own description of the hardware configuration: 

"The apparatus is a combination of devices for obtaining the necessary information and making 

predictions for controlling the gun. The electrical director is associated with a battery of four guns and 

an optical height finder. It consists of four separate units which are transported in a trailer, namely the 

tracker, the computor [sic], the range converter, and the power equipment. The two men on the seats 

of the tracker look through the telescopes and by means of controls, keep the cross hairs in the eye 

pieces constantly on the airplane. For example, one man is now rotating the tracker about a vertical 

axis and this rotation determines an angle called the azimuth. The other man raises or lowers his 

telescope about a horizontal axis and thus determines an angle called the elevation angle. [These] 





two actions are simultaneous [and] determine the direction of the airplane from the tracker. The two 

telescopes are driven by electrical motors, so that the rates of these motors can be set when the 

telescopes are following the plane smoothly, and they will continue to follow it for short periods without 

any aid from the men, as when the plane is flying through a cloud. However, even when the plane is 

flying in a straight line at constant speed the angular rates at the tracker are not constant, so the two 

men at the tracker must slowly shift the rates so as to keep the target on the cross hairs. If they are 

skilful in doing this, then, by electrical transmission systems, data, which give the direction of the 

airplane from the tracker at each instant of time, are continuously being fed from the tracker to the 

computor [sic] of the director. [New paragraph.] To determine the position of the plane in space we 

must add to these two direction angles another quantity called the range, that is, the air-line distance 

from the tracker to the target. This is furnished by either electrical or optical means. These quantities 

are known as present polar coodinates and all of them vary from instant to instant as the plane 

moves. [New paragraph] The first operation which the computor performs is to transform these polar 

coordinates into rectangular coordinates, that is values are produced in the computor which tell how 

far the plane is north or south, how far it is east or west, and how far it is above the ground. [The] 

computor then calculates by means of electrical and mechanical mechanisms the magnitudes of 

these rates, which are [then] indicated on meters. New paragraph] Before the computor can use 

these data to make predictions as to where the gun must be pointed the information concerning the 

power of the gun and the kind of shell that it is firing must be taken into account. These [and many 

other corrections] may be set in the computor by means of hand-controlled dials In addition, the 

electrical computor also takes into consideration the fact that the guns are located some distance from 

the tracker. [In fact, the] computor may be put into a place of safety underground, hundreds of yards 

from the guns, and still make accurate predictions. The adjustment necessary when the gun and 

tracker are separated is called the parallax correction." (Dr. Harvey Fletcher, Director of Physical 

Research, Bell Telephone Laboratories; quoted in an anonymous editorial in Bell Laboratories Record, 

1943, 22(4):157-167, pp163-165; all emphases added.) 

Few pre-war gunners would have recognised the situation a mere six years later, for by 1945 the 

tracking was by locking-on radar, the guns themselves were self-laying by servomechanism, and 

progress was being made at automating the manual tasks of loading and fuse-setting. Indeed, the Bell 

system, impressive enough in 1942, became even more potent when the projectiles were fitted with 

radio proximity fuses a few months later ...... 

Key Invention - The Radio Proximity Fuse: Live burning or clockwork time delay fuses were 

rendered largely obsolete when the "VT" type radio proximity fuse (described by some as second only 

to the atom bomb in World War Two military significance) was combat tested in January 1943. These 

shells relied on a miniaturised (and exceptionally robust) onboard radio transmitter, coupled to a 

Doppler shift amplifier. After a short initial delay to allow the shell to clear the gun, the radio echoes 

from any solid objects in the vicinity could be detected, amplified, and used to detonate the main 

charge. [For a cut-away diagram of one of these fuses, click here, and for fuller technical background, 

click here, or here, or here.] 

ASIDE: Kenneth D. Smith (1905-1990) was one of many unsung heroes at Bell Labs during World 

War Two. He contributed significantly to proximity fuse and radar development before 1945, and then 

moved on to the team responsible for transistor development (see Part 3). Readers interested in 

this aspect of the history of computing are strongly recommended to visit the website of the 

Southwest Museum of Engineering, Communications, and Computation, Glendale, AZ, and 

consult their "K.D. Smith Collection". There are also two helpful sites devoted to wartime 

experiences with the British 3.7" Anti-Aircraft gun, one belonging to the British 36th Heavy AA 





Regiment, and the other to the New Zealand Permanent Force Old Comrades' Association, 

both of which carry some informative pictures. 

Of course, it was not just the ballistics industry which had computation needs. Other applications of 

analog computing technology were focusing on solving the sort of large differential equations 

generated by nuclear physicists, electronics engineers, and astronomers. One of the most 

sophisticated of the early analog devices was an electromechanical differential analyser built at MIT in 

the late 1920s by an electrical engineer named Vannevar Bush (1890-1974). This was completed in 

1931 [picture], but the experience was dogged by difficulties with all the moving parts. Bush therefore 

started to draw on the radio industry's 30 years' experience with the thermionic valve ..... 

Key Invention - The Thermionic Valve: In 1904, John (eventually Sir John) Ambrose Fleming (1849- 

1945), of University College London and the Marconi Wireless Telegraph Company, invented the 

thermionic valve (alternatively "valve", or "vacuum diode", or "rectifying vacuum tube", or just "tube"). 

In its simplest form, a valve consists of an evacuated glass globe similar in appearance to a small 

electric light bulb, containing two electrodes, one connected to a positive supply (the anode) and the 

other acting as a hot filament cathode. Given the fundamental nature of electricity, this arrangement 

can only allow a current to pass in one direction - from cathode to anode, in the form of a beam of 

electrons usually referred to as a "cathode ray". Properly incorporated into an electrical circuit, 

therefore, a vacuum diode could rectify alternating current. Subsequent development by the American 

Lee de Forest (1873-1961) introduced a third electrode in between the cathode and the anode (thus 

turning the diode into a "triode"). This additional electrode could block the cathode ray, and thus 

determine whether any current made it across to the anode. This allowed one part of a complex circuit 

to act as an electronic switch in another part. [To see some of the circuit diagrams involved, click 

here; see also the separate entry for the Thyratron Valve immediately below.] 

Key Invention - Thyratron Valve: In 1913-1914, the Harvard physicist George Washington Pierce 

(1872-1956) filed for patents in thermionic valves filled with mercury vapour rather than being 

evacuated. This significantly changes the unit's performance when incorporated into an electrical 

circuit. For one thing, a thyratron circuit can deliver higher output current, and for another the 

switching profile is different. In vacuum diode switching, for example, electrons will flow from the 

cathode to the anode whenever the electrode-electrode voltage exceeds a certain critical value, and 

this flow will then cease as soon as that voltage falls back below it. In a gas-filled diode, however, the 

gas provides an ionisable medium. This means that electrons from the hot cathode can, if the anode 

voltage is high enough, collide with ionised molecules on their way from cathode to anode. This then 

dislodges further electrons, which collide with other molecules, and so on, in increasing intensity 

[further technicalities]. Again this only happens at a critical voltage, known as the "ionisation potential", 

but this time the ion flow is self-sustaining until the potential drops below a second, markedly lower, 

value known as the "de-ionisation potential". Properly incorporated into a circuit, this allows a 

thyratron to "stay on" until "switched off". Thyratrons are thus good candidates for "remembering" 

pulses, and it was this memory-like property which led the Welsh physicist Charles E. Wynn-Williams 

to use them in his prototype logic circuit in 1931 (see below). In 1913, AT&T purchased De Forest's 

valve patents, and set up a research laboratory - the beginnings of "Bell Telephone Laboratories" - 

to develop radio technology alongside its existing telephony and telegraphy interests. 

Bush progressively replaced electromechanical units of his machine with valve-based electronic 

equivalents with no loss of performance until the basic design prevented him going any further. He 

then carried out a major redesign exercise, and spent the period 1935-1942 preparing a smaller, 

faster, but ultimately more powerful Differential Analyser Mark 2. Nevertheless, despite all the 





improvements, the fundamental representation in these differential analysers remained analog, whilst 

the computers we are familiar with today act digitally, even when dealing with continuous variables 

(see Part 1). Digital calculation was known to be possible, of course, but if you had a lot of numbers to 

crunch and wanted the answer in a hurry they were just too slow. If digital techniques were to 

compete with the follow-the-pointer analog systems they needed to get a whole lot faster. Another 

invention was sorely needed ..... 

3 - Computing, 1935-1942 - The Digital Breakthrough 

The eventual challenge to the analog computing industry began to take shape in the late 1930s with 

three independent discoveries. The first of these took place in Britain, when the Welsh physicist 

Charles E. Wynn-Williams (1903-1979) used thyratron valves to make both binary (1931, published 

1932) and decimal (1935) automatic event counters. This was followed between 1934 and 1938, in 

Germany, by Konrad Zuse (1910-1995), a Henschel and Company aircraft engineer, who wired up 

some home-made relays to make a binary "logic circuit", and in America by George Stibitz (1904- 

1995), a Bell Labs engineer ..... 

Key Invention - Electronic Logic Circuits: These are circuits capable of using the switching ability 

of valves to reflect simple mathematical processes. In 1931, at the Cavendish Laboratory in 

Cambridge, Wynn-Williams devised valve-based circuitry as a data capture device for researching 

nuclear particles. This circuit was capable of electronically simulating the process whereby plus 

gives (the binary version of "one plus one equals two"), complete with an electronic twoscarry 

mechanism, and was known as a "scale of two counter" (Wynn-Williams, 1932). By 1935, he 

had converted the final result back into decimal for greater user-friendliness. Wynn-Williams' original 

apparatus is preserved in Cambridge University's Whipple Museum. 

Wynn-Williams was a humble theoretical physicist, and was merely trying to count atomic particles. 

Accordingly, only Zuse and Stibitz proceeded with computer development, and Zuse was already 

ahead by several years. In 1934, as a newly qualified engineer, he began to spend his spare time 

designing computing circuits, chancing eventually upon much the same technique as Stibitz in the US, 

albeit with older underlying technology. Where Stibitz used valves to add columns of binary numbers, 

Zuse used hand-built relays. Zuse patented his design on 9th April 1936, began construction of a 

working prototype on his parents' living room floor, and had his first operational machine, the Z1, 

ready in 1938 [more detailed account]. A facsimile of the Z1 is on show in the Berlin Technology 

Museum. 

The Z1 was not a particularly reliable piece of hardware, but it was binary computation nonetheless, 

and it was programmable in the sense that problems could be presented to it by punched tape 

instructions. Zuse was very clear on how his machine should be used, writing that "the prerequisite for 

every kind of calculation is the construction of a program". He was thereby resurrecting Babbage's 

strategic dream of a century beforehand of a basically quite simple machine, able to do complicated 

things by varying the command sequence, which, note, is the diametric opposite of the analog 

machines, where the complexity was built into the hardware itself and the command sequence was 

minimal. 

In fact, Zuse's only mistake was to have avoided valves. A friend of his, Helmut Schreyer (1912?- 

1985), suggested using them in 1936 because they, too, worked to yes/no logic and could flip from 

state to state much more quickly than relays, but Zuse chose not to take the risk because their burnout 

rate was too high. Instead, he decided to replace the scratch-built relays in the Z1's arithmetic 





module with proprietary ones. He tested this redesign in the Z2 (1938-1939), and then with the Z3 

(1939-1941). The Z3 consisted of a large cabinet housing 1400 memory relays (giving 64 22-bit words 

of storage), another full of 600 arithmetic relays, a 22-bit parallel bus, and an array of 

microsequencers in a control unit. It was demonstrated to the German military on 12th May 1941, but 

was actually too small and too slow to impress them. It was then destroyed in an air raid in 1944, but 

a facsimile is on show in the Deutsches Museum in Munich, and many commentators believe that 

because it came in a year ahead of the ABC it rates as the world's first computer. Here is an analysis 

of the Z3's strengths and weakness, measured against the criteria of modernity discussed so far ..... 

Electronic rather 

than 

Electromechanical 

No - 

electromechanical 

Digital rather than 

Analog 

Binary rather than 

Decimal 

Yes Yes - as with modern 

computers, input and 

output was in decimal, 

but this was converted 

to pass through a 

central binary logic unit 

Revised August 5, 2008 Page 32 of 190 

General Purpose 

rather than 

Specialised 

Yes, within the 

limitations of its 

rudimentary instruction 

set 

Stibitz, too, was short of resources, because although Bell Labs immediately set him to work on a fully 

sized machine (see the entry for the Bell Complex Number Computer in the data table at the end of 

this paper), they had a lot of other defence contracts on the go, and could not give the project their 

undivided attention [see the Southeast Museum of Engineering, Communications, and Computation's 

e-exhibition on Bell Labs at war]. As a result, the honour for being the first to put such an electronic 

digital computer together has since been adjudged under US patent law to go to John Vincent 

Atanasoff (1903-1995) and Clifford Berry (1918-1963) of Iowa State University (ISU). After his 

childhood adventures with his father's slide rule (see Part 1), Atanasoff graduated from the University 

of Florida at Gainesville in 1925, and joined ISU as a masters student. His studies completed, he then 

moved to Madison, WI, to complete his PhD, and his ISU biographers explain how while completing 

his doctoral thesis he spent many hours crunching numbers on a Marchant calculator, a thoroughly 

tiresome experience which resolved him to develop a better and faster way of doing things. Atanasoff 

received his PhD in theoretical physics in 1930, and returned to ISU as a lecturer. This exposed him 

to the work of Bush and Stibitz, and through 1938-1939 he researched some novel design ideas of his 

own. When he asked for an assistant, he was assigned Berry, a well-recommended young graduate 

who had hand-built his own radio at the age of 11 years, and in 1939 they began work on a machine 

to put Stibitz's circuit designs into operation. The resulting Atanasoff-Berry Computer (ABC) used 

binary arithmetic logic circuits, and was completed in 1942 [for further details visit the Ames Lab, Iowa 

State University website]. Here is an analysis of the ABC's strengths and weakness, measured 

against the main criteria of modernity discussed so far ..... 


than 



Analog 


Decimal 


rather than 

Specialised




Yes (valve-based) Yes Yes No 

4 - Timeline, 1925-1942 

And finally, here is a timeline for the period from 1925 to 1942. The material contained is from many 

sources, including Berkeley (1949/1961), Wilkes (1956), Hollingdale and Tootill (1965), and Evans 

(1983): 

Name/ 

Claim to Fame 

JAKOB 

First generation analog 

flak predictor 

IBM600 series Tabulating 

Machines 

Differential Analyser Mark 

1 

Largest analog computer 

to date. 

Flakkommandohilfsgerät 

35 

Second generation 

analog flak predictor 

Model K 

First US prototype 

electronic binary logic 

circuit calculating 

machine 

Z1 

First German prototype 

Project Leader(s)/ 

Purpose 

German military 

Ballistics calculations 

Commercial and 

scientific data handling 

Date/ 

Sponsor 

Operational 1917 

Carl Zeiss-Jena 

1930s 

Remarks 


IBM 

Vannevar Bush Started mid-1920s 

German military 

Ballistics calculations 


In development until 

1935 when replaced by 

Mark 2 

MIT 

1935 

George Stibitz 1937 

Konrad Zuse and 

Helmut Schreyer 

Carl Zeiss-Jena 

Bell Telephone 

Laboratories 

1936-1938 

No major sponsor. 

The latest "sort and 

tabulate" punched 

card systems. 

Initially 

electromechanical, but 

later modified to 

include some 

electronic subassemblies. 

Prototype only - the 

"K" stands for "kitchen 

table", which is where 

Stibitz did his basic 

experimentation. 

The memory and 

arithmetic unit 

components were




electromechanical binary 

logic circuit calculating 

machine/ computer 

Z2 Konrad Zuse and 

Helmut Schreyer 

Complex Number 

Computer 

First binary computer to 

be operated over a 

telephone line 

Atanasoff-Berry 

Computer (ABC) 

First valve-based binary 

digital computer 

Z3 

First German 

electromechanical digital 

computer 

Differential Analyser Mark 

2 

George Stibitz and 

Samuel Williams 

John Atanasoff and 

Clifford Berry 

Scientific computing 

1938-1939 

No major sponsor. 

Started 1939 

Operational January 

1940 


Laboratories 

Started 1939 


Iowa State University 

Konrad Zuse Started 1939 

Demonstrated 12th 

May 1941, Berlin, 

Germany 

Vannevar Bush 1935-1942 


1 - Computerised Cryptanalysis 

entirely hand made. 

An improved version 

of the Z1, in which the 

hand made units of 

the arithmetic unit 

were replaced with 

relays. 

Also known as Bell 

Labs "Model 1 Relay 

Computer". Not 

surprisingly, given its 

pedigree, the machine 

ended up being built 

largely out of 

scavenged telephone 

exchange 

components. 

The full potential of 

this machine was not 

developed, since it did 

not get development 

sponsorship from the 

German military. 

Clever though the ABC and Z3 (see Part 2) may have been, the fates chose to ignore them. They 

were not lucky systems. They lacked political, financial, and/or academic clout, and as a result simply 

got sidelined by history. Atanasoff's Iowa State biographers assure us that he left filing the patent to 


MIT




his University, who then lost the paperwork, and when Zuse's prototype was demonstrated to the 

Wehrmacht they decided that the system's benefits were unlikely to justify the development costs. But 

there were lucky systems as well, and while Zuse had been funding the Z3 largely out of his own 

salary, the big boys were about to sink fortunes into computer development projects which could not 

be allowed to fail. Three main wartime driving forces may be identified, namely (a) computation for 

code breaking, (b) computation for ballistics, and (c) computation for the nuclear physicists developing 

the atomic bomb. The first six sections of the paper specifically address the first of these histories, so, 

before proceeding, readers unfamiliar with the use of codes and ciphers in political and 

military history in general, should read the first two parts of our three-part subordinate paper 

"Codes and Ciphers in History", as follows ..... 

..... and readers unfamiliar with the principles of the German World War Two cipher machines 

in particular, should additionally read the third part of said paper, as follows: 

1.1 Computerised Cryptanalysis (1930-1939 - The Polish Bomby) 

As explained towards the end of "Codes and Ciphers in History", the story of mechanically assisted 

cryptography began with simple contrivances like Alberti's cipher disk, and moved on during the 

1920s to multiple disk keyboard scramblers such as the German Enigma system. The technology was 

then blooded in Poland during the run-up to the Second World War, when, as likely enemies of a 

resurgent Germany, the Poles resolved to decipher their neighbour's Enigma traffic. This exercise 

began as soon as the German army adopted the Enigma system in 1928 (Bury, 2002 online), and 

involved three mathematics graduates from Poznan University - Marian Rejewski, Jerzy Rozycki, and 

Henryk Zygalski. These three young men were recruited straight out of university into a special Biuro 

Szyfrów (= Cipher Bureau) project in early 1930, and by painstaking work, plus experience of the 

simpler commercially available machines, managed by 1932 to work out the Enigma's internal wiring 

logic, that is to say, the top secret randomising connections pressed into the inner ring of each Hebern 

wheel (see Part 3 of the supporting historical review). They immediately built a number of replica 

Enigmas of their own, and by January 1933 were deciphering live German transmissions. 

Now the reason the Enigma story is central to the history of computing, is that the Poles also made 

significant progress automating the cryptanalytical process. By November 1938, they had developed a 

"bomba kryptologiczna", in which six of their replica Enigmas were mechanically linked together, 

and motor-driven through permutation after permutation until the output of one of them matched a preset 

target value, whereupon the whole contraption stopped automatically, with the probable Enigma 

Grundstellung clearly displayed. 

ASIDE: The point of using six replica machines, is that each had its rotors set in a different left-to-right 

order, one for each of the Walzenlage permutations possible with a three-from-three Enigma. The 

process could have been executed on a single replica machine, but this would have been able to deal 

with only one Walzenlage at a time, so on an unlucky day would take up to six times as long to finish. 

This is a very early demonstration of the advantage of parallel over serial processing. The 

bomby allowed the Polish cryptanalysts to do all the necessary trial and error work at machine speed, 

and the system was so successful that Bury estimates that the Biuro Szyfrów decoded around 

100,000 transmissions in the six years before Poland was eventually occupied. Kahn (1996, p975) 

describes the bomby as "the roots of protocomputers". 





Unfortunately, the Poles lost the naval traffic on 1st May 1937, as a consequence of the Kriegsmarine 

tightening its operating procedures [see next section but two], and to rub salt into their wounds they 

then lost the army traffic on 15th December 1938, when the three-from-five Enigma was introduced. 

ASIDE: As soon as the Germans increased the available rotor stock, the number of possible 

Walzenlage permutations started to shoot up. For example, there are 10 different ways of selecting 

three out of five rotors, and then - as before - six different ways of sequencing the three you have 

selected into the available slots, making 60 permutations in all. So in going from three to five rotors, it 

takes you from six to 60 permutations: one small step for the cryptographers, but ten times as much 

work for your enemies. 

But what the Poles were really short of, of course, was time, and by late June 1939 it was apparent 

that the German invasion was not far off. The Polish Chiefs-of-Staff therefore resolved to share their 

accumulated Enigma secrets with their French and British allies. An approach accordingly went out 

through diplomatic channels, and ended up on the desk of Commander Alexander G.A. ("Alastair") 

Denniston (1881-1961). 

BACKGROUND: Denniston had been a code breaking expert during World War One, and had kept 

"Blinker" Hall's Room 40 skill base alive by forming the Government Code and Cypher [sic] School 

(GCCS) in 1920. He had then run GCCS (known cryptically as "Station X") as a small peacetime unit 

attached to the Foreign Office, where it could serve the diplomatic and peacetime military intelligence 

worlds. The organisation was then progressively expanded during the 1930s, as it became more and 

more apparent that another war was on its way, and was moved out of London in 1938 to the newly 

acquired house and estate of Bletchley Park [picture and virtual tour]. It was from this base that it 

formed a key element in a high level British military intelligence project codenamed "Ultra". 

Realising the potential importance of the Polish work, Denniston personally led a top-secret mission in 

late July 1939 to the Biuro Szyfrów station hidden in the Lasy Kabackie, the woods outside Pyry, a 

small town south of Warsaw. He was accompanied by Alfred Dillwyn ("Dilly") Knox (1884-1943), one 

of his long-term Room 40 colleagues, and Commander Humphrey Sandwith, of the naval intelligence 

service. Together, they toured the Polish decoding school, observed their methods, studied their thusfar-unsuccessful 

attempts to defeat the three-from-five Enigmas, and brought back specimens of the 

sort of paperwork which needed to be done before a bomba could be set to work. The Poles also 

offered them one of the replica Enigmas, and this seems to have been brought out of the country in a 

diplomatic bag a few days later, and collected personally by Colonel (later Sir) Stewart Graham 

Menzies, head of MI6, in a furtive suitcase-swap at London's Victoria Station during that August (Kahn, 

1991). 

ASIDE: As head of Britain's Secret Intelligence Service (MI6), Menzies would have been referred to 

within the profession as "C". The role (and possibly the person himself) was subsequently fictionalised 

as "M", by a certain Ian Fleming. 

The German blitzkrieg against Poland finally began on 1st September 1939, and was followed two 

weeks later by a carefully synchronised Russian invasion from the east. Caught between two giants, 

the immediate military outcome was a foregone conclusion, and as their defences collapsed around 

them the Biuro Szyfrów destroyed its heavy equipment and evacuated its key personnel to France, 

where during October they became part of a joint French-Polish decryption unit known as "Bruno". 

This unit was housed in the Chateau de Vignolles [picture] (a sort of French Bletchley Park), at Gretz- 

Armainvilliers, just outside Paris, and there they remained until the fall of France in June 1940, 





whereupon they had to be evacuated again, this time to Algiers [for these adventures in greater detail, 

plus the story of what happened to them next, click here]. 

1.2 Computerised Cryptanalysis (1939 - The Jeffries Sheets) 

Upon Denniston's return from Warsaw, he immediately reorganised his Bletchley Park resources. Not 

unreasonably, given the Polish successes, his strategy was (a) to recruit as many university geniuses 

as he could get his hands on, (b) to break back into the improved three-from-five and naval systems, 

(c) to pass the resulting intercepts to Churchill and his Chiefs-of-Staff, who would use the intelligence 

gained to help operational planning, and (d) to build some suitably wired bomby of his own. He then 

allocated his available staff to a number of "huts". Huts 6 and 3 would address the Army and Luftwaffe 

Enigma systems (Hut 6 doing the primary cryptanalysis, and Hut 3 handling the resulting translation 

and onward routing), Huts 8 and 4 would carry out cognate duties on the Kriegsmarine codes, and 

Hut 3N would ensure that nothing fell down the cracks between land, air, and sea. Two special 

Intelligence Sections (ISOS and ISK) would conduct primary cryptanalysis of the Abwehr traffic, 

although follow-up processing for this stream was carried out elsewhere by reason of its sensitivity 

(Twinn, 1993). W. Gordon Welchman (1906-1985) was made responsible for expansion of the 

establishment during that autumn as new staff poured in (Welchman, 1982), and additional units were 

set up as numbers grew. Here, by department, are some of the names mentioned in the literature: 

Department Officer 

Commanding 

Hut 3 Malcolm 

Saunders 

Eric (later Sir 

Eric) Jones (from 

mid-1942) 

Hut 3N (= Hut 

3/4 Liaison) 

Hut 4 

(aka "Naval 

Section") 

Team Duties 

Frederick Norman; Ralph Bennett (from 

February 1941); William Millward (from 

April 1942); Telford Taylor (US liaison; 

from 1943). 


Army and Luftwaffe 

Enigma translation and 

initial follow-up 

(supporting Hut 6). 

N/K Edward Thomas (from February 1942) Covered the grey area 

where army, air force, 

and navy matters 

interact. 

Walter Eytan (Z 

Watch, from 

February 1941) 

Hut 6 Gordon 

Welchman 

(September 

1939); Stuart 

Milner-Barry 

(1940) 

Harry Hinsley (from October 1939); Alec 

Dakin (from May 1940), Patrick 

Wilkinson; Charles Leech, Gordon 

Priest, Eric (later Sir Eric) Turner, Ann 

Toulmin; Leonard Forster; Ernest 

Ettinghausen; Thelma Ziman; Vivienne 

Alford; Peter Twinn 

Naval Enigma 

translation and initial 

follow-up (supporting 

Hut 6). 

Derek Taunt; Dennis Babbage Army and Luftwaffe 

Enigma primary 

cryptanalysis. 

Hut 8 Commander Joan Murray (June 1940); Hugh Naval Enigma primary




Edward (later Sir 

Edward) Travis 

Alan ("Prof") 

Turing 

The Newmanry Max Newman 

(from September 

1942) 

The Testery 

(Part of Block F) 

Major Ralph 

Tester 

Hut 7 John Tiltman 

The Cottage - 

Intelligence 

Sections OS 

and K 

Oliver Strachey 

(= OS) and 

Dillwyn Knox (= 

K) 

Alexander; 

Alex Kendrick; Jack Good (May 1941 to 

April 1943); Hugh Foss; Leslie Yoxall; 

Shaun Wylie; Michael Ashcroft; Richard 

Pendered 

Jack Good (from May 1943); David 

Rees; Bill Tutte 

Roy Jenkins; Alan Turing; Peter 

Benenson; Peter Hilton; Donald Michie 

John Jeffries; Keith Batey; Mavis Lever; 

Margaret Rock 

cryptanalysis. 

Abwehr non-Enigma 

and Enigma traffic 

respectively - 

cryptanalysis and 

onward despatch. 

Denniston's strategy immediately led him to a young mathematician named Alan Turing ..... 

ASIDE: In wartime, the military draw heavily on the services of civilian academics and engineers, 

especially in the areas of physics, mathematics, and telecommunications. These were routinely 

referred to as "boffins", and in this section we meet one of the boffinest, Alan Mathison Turing 

(1912-1954). Turing had achieved early academic fame with a 1937 paper entitled "On computable 

numbers, with an application to the Entscheidungsproblem" (Turing, 1937). In this paper, he proposed 

a hypothetical decision-making machine, fed with a series of simple yes-no questions from a paper 

tape input. The philosophical issue was whether there was any mathematical problem which could not 

be programmed in this way (Turing used the phrase "calculable by finite means"). Turing concluded 

that in fact there were such problems, albeit not many, and his hypothetical machine is now commonly 

seen as the idealised binary digital computer, or "Universal Turing Machine". The Turing Archive for 

the History of Computing and the King's College Cambridge Turing Digital Archive contain digital 

facsimiles of many of Turing's wartime papers, now declassified. 

Turing reported for duty on 4th September 1939 (Hodges, 1992), and was joined shortly afterwards by 

another Cambridge mathematician, John Jeffries, already an expert on ciphers. The most logical way 

to fulfil Denniston's masterplan was therefore to give Jeffries the job of attacking the logic of the cipher, 

while Turing drew up plans for the computing machine to deal with it on a day-to-day basis once it had 

been broken. Jeffries' work exposed him immediately to the Lasy Kabackie papers, amongst which 

were some pen-and-paper cryptanalytic techniques devised by Zygalski, and known therefore as 

"Zygalski Sheets". These were rotor analysis matrices which when appropriately punched and 

stacked (for details, see Savard, 2002 online) would reveal likely Walzenläge. One large matrix was 

needed for every letter of the alphabet for every Walzenlage permutation. For the old three-from-three 

Enigmas, this meant 26 sheets for each of the six possible Walzenläge, and for the new three-fromfive 

Enigmas, it meant ten times as many [see previous inset]. Welchman (1982) gives fuller details of 

the "perforated sheet" approach to cryptanalysis, if interested. 





By December 1939, the new "Jeffries Sheets" were ready (60 sets, one for each possible Walzenlage 

again, and each set containing 26 matrices), and by one account Turing delivered them in person to 

Rozecki, Zygalski and Rejewski, now codenamed "Equipe Z" (= "Team Z"), at Vignolles, where - after 

just over a year in the dark - they enabled the first successful decryption of a three-from-five Enigma 

on 17th January 1940. 

The Allies were now free to resurrect the principles of the Polish bomby, namely to work through the 

Walzenläge from the first to the 60th, searching for a fragment of pre-set "cribtext" ..... 

Key Concept - The "Crib": Cryptologically speaking, a "crib" is a short fragment of known or strongly 

suspected ciphertext content. Many cribs derived from the repetitive nature of military communication. 

For example, many units reported NICHTSZUMELDEN (= "nothing to report") on a daily basis, or their 

radio operators would send a pro forma tuning message before anything else (Taunt, 1993). The 

other main sources of cribs were (a) weather reports, (b) proper names, (c) plain old-fashioned 

operator bad practice, and (d) deliberately creating an operational event and then checking to see 

how it was reported the next day (a process known as "seeding"). 

The Enigma cribs were given added importance by one of the system's basic design features, namely 

that no letter was allowed to encrypt as itself. This meant that if you aligned a slip of cribtext above a 

line of ciphertext, no vertical pair of characters could be the same. If they were, then the crib could 

not exist at that position. Milner-Barry (Hut 6) summarises the argument this way: 

"If, for example, you were looking for the most likely position [for the word] Besonderen [= "special"], 

and you noticed that under the [cribtext] B in Besonderen was another B, you would know for a 

certainty that that could not be the right position." (Milner-Barry, 1993, p94.) 

It followed that if a crib could be logically excluded in all text positions, then either (a) the crib was 

wrong, or (b) the crib was right, and that particular machine setting could be excluded; and on 

most days, on routine intercepts, you had very high levels of confidence in the crib. Taking this 

argument a step further, if you could carry out this process of elimination at speed and exclude all 

machine settings except one, then that would be the one to use to decipher that day's intercepts. 

1.3 Computerised Cryptanalysis (1940-1941 - The Bombes) 

Key Locations - BTM: In this section, we meet "BTM", the British Tabulating Machine Company 

premises at Letchworth, Hertfordshire. BTM was formed in 1908, as a London-based licensee of 

Hollerith punched card technology (see Part 1). The company was renamed International Computers 

and Tabulators in 1959, acquired Ferranti's computing division in 1963, and merged with English 

Electric to form International Computers Ltd (ICL) in 1968. ICL was the British computing industry in 

the 1970s and 1980s, but was taken over by Fujitsu Corporation in 1990. The marque was finally 

withdrawn (for marketing image purposes) in 2001. 

The bombes were put together by BTM at their Letchworth factory, and Welchman (1982) dates the 

experimental systems to September 1940 (the first was nicknamed "Agnes"). However, Welchman 

also estimates that it took another year or so before they started to take the pressure off the pen-andpaper 

techniques. Indeed, Welchman repeatedly stressed that the bombes themselves did not break 

codes, but that people did. The processing logic meant that the more machines you had, the shorter 

could be the Walzenlage tape for each, and the quicker you could get your results. About six bombes 

were operational by mid-1941, and perhaps twelve by late summer (Welchman, 1982). Production 





then proceeded at about one machine per week, the machines being transported from the BTM 

factory without escort to avoid attracting anybody's attention. Different machines serviced different 

huts, and different regional or administrative networks within huts. Worthwhile intelligence started to 

appear in the July 1940 defence of Norway (Thomas, 1993), and there were also successes in the 

evacuation of the Aegean in early 1941, and in the war against the Afrika Korps' supply convoys later 

that same year. 

1.4 Computerised Cryptanalysis (1941-1942 - The Naval Enigmas) 

With the German army and air force codes under some semblance of control, attention turned to the 

Kriegsmarine system. This had been a much tighter system since the introduction of more vigorous 

procedural protection for the message header on 1st May 1937, but it was nevertheless strategically 

vital for it to be defeated, because it was the key to countering the German U-boat offensive. This is 

how Irving John ("Jack") Good (1916-), who joined the team in May 1941, summarised the complex 

Kriegsmarine operating procedure [we recommend sketching out his worked example as you go]: 

"The German operator would haphazardly choose the settings for the three wheels as shown by the 

rings, say ASC, but he would not send ASC in clear. Instead, he would first set the wheels at [the key 

of the day] Grundstellung [and] tap out ASCASC. [This] would give him a hexagraph, say LQRCPY. 

He would write this in the pattern [L over space, Q over C, R over P, and space over Y] and fill in the 

[resulting four-by-two] rectangle with two letters that he chose haphazardly. For example [O bottom 

left and T top right]. Next he would encrypt the vertical digraphs LO, QC, RP, and TY by using a 

secret 'digraph table'. There were ten possible digraph tables (fixed for an appreciable time, perhaps 

of the order of a year), and which of the ten he was to use would be shown by part of the keys of the 

day. For example, LO might become TU, QC might become AH, RP might become LS, and TY might 

become IU. Then his rectangle would become [TALI over UHSU]. Then at last he would transmit TALI 

UHSU. The legitimate receiver would use the same procedure in reverse order to recover the true 

initial wheel-settings for the message, and he would get a check because of the repetition. I noticed 

on one night shift that about twenty messages were enough to identify which digraph table was in 

use." (Good, 1993, pp155-156.) 

Fortunately, May 1941 turned out to be a doubly lucky month for British codebreaking. Firstly, a copy 

of the June 1941 codebook was recovered from a captured German trawler, and secondly one of the 

machines itself was recovered from a captured U-Boat (U-110). This gave sufficient specific 

background information for the naval Enigma to be effectively broken for the remainder of that year. 

Then came more ominous news. Thomas (Hut 3N) tells how in August 1941 he inspected the inside 

of captured U-570 (Thomas, 1993). No code books or machines were recovered on this occasion, for 

the crew had ditched these over the side, but what they had not ditched was the transportation box for 

a machine still under test, which, Thomas noted, was recessed to accommodate a four-slot machine, 

rather than three. It subsequently transpired that the Kriegsmarine was about to upgrade to a fourfrom-eight 

Enigma system, and when this eventually went live in February 1942 it brought blackout for 

the rest of that year, (a) because there were new rotors whose internal wiring needed to be broken, 

and (b) because the cryptanalysts now had many more permutations to wade through at run time. 

ASIDE: The 1942 naval Enigma machines were not just fitted with four rotors rather than three, but 

some of the rotors had more than one turnover notch, so they would "carry" to the adjacent rotor more 

often. As previously explained, there are 60 Walzenlage permutations on a three-from-five Enigma. If 

we do the same calculation with a four-from-eight naval Enigma we find there are 70 ways of selecting 

four rotors, and then another ten ways of sequencing the rotors-of-the-day across the available slots, 





making 700 permutations in all. (In fact, it was not quite as bad as this, because German operating 

procedures insisted that at least one of rotors VI to VIII was included.) 

The four-from-eight naval system therefore demanded either more bombes or a more sophisticated 

computational solution, and, according to the Bletchley Park Museum, eventually around 200 

machines were in operation 24-hours a day at sites across Britain. Bombe 2 was developed in early 

1943 to substitute valve technology for some of the electromechanical. The first two American 

bombes entered acceptance trials in May 1943, and orders were placed for a US production run of 96 

machines in June 1943 (Wenger, Engstrom and Meader, 1944; top secret report, now declassified 

and online). The role of NCR's Electrical Research Laboratory at Dayton, OH, in producing the US 

machines is currently being researched by Anderson (2000/2002 online). The bombes worked well as 

far as they went, but were generally underpowered and slow. To set up and play with your own 

bombe, click here. 

1.5 Computerised Cryptanalysis (1942-1943 - Breaking the Lorenz SZ42) 

Key Location - TRE: The next part of the story of British World War Two code breaking introduces 

another important location - "TRE", the Telecommunications Research Establishment, Malvern, 

Worcestershire. This began life as an Air Ministry project to develop top secret radar equipment. 

Funding was authorised in 1934, and a small team was brought together in 1935 under Robert (Later 

Sir Robert) Watson Watt (1892-1973) at Orfordness, Suffolk. More permanent premises were 

acquired in 1936 at nearby Bawdsey Manor, and the official name Bawdsey Research Station was 

allocated. This name then had to change when the entire establishment relocated to Dundee in 1939, 

and the title Air Ministry Research Establishment (AMRE) was selected. There was then a further 

relocation to Worth Matravers, Dorset, in May 1940. The official TRE name was given in November 

1940, and the move to Malvern took place in May 1942. 

Key Personnel: In this section, we also meet Maxwell Herman Alexander ("Max") Newman (1897- 

1984), a senior Cambridge mathematics professor before the war, who had lectured Turing as a 

student (in fact, it was he who had inspired the latter's Entscheidungsproblem paper and established 

the academic links with Princeton which had brought Turing into contact with von Neumann). We also 

meet again the Welsh physicist Charles E. Wynn-Williams (1903-1979), whose pre-war track record 

building electronic counting circuits was about to prove invaluable (remember that he beat Stibitz to 

the binary accumulator by six years - see Part 2). Wynn-Williams joined AMRE/TRE from Cambridge 

University at the beginning of the war. 

Important though they were, the Enigmas were only tactical systems. Their job was to link Hitler's 

generals to their armies, his air marshals to their airbases, and his admirals to their U-boats and 

surface units. The various networks carried routine low-level orders in bulk, that is to say, the sort of 

traffic required to move and coordinate Hitler's war machine in much the same way that our motor 

nerves move and coordinate the individual muscles of our bodies. Yet another encryption system 

serviced strategic communication between the High Command and the far corners of the German 

military and diplomatic world; and, needless to say, one high level message could easily tell you as 

much as a few thousand day-to-day ones. The Germans therefore protected their strategic 

communications traffic with higher specification cipher machines - the Lorenz Schlüsselzusatz 

SZ40/42 [picture] and the Siemens and Halske T52 Geheimschreiber [picture]. 

The SZ42 was a Vernam-style bit-flipping teletypewriter, as previously described [background]. Using 

the commercially widespread system of five-hole tape [see under Morkrum and Morkrum-Kleinschmidt 





in Part 1], it carried out a key-controlled modulo 2 encryption of every bit in every character in the 

plaintext. It then produced a pre-perforated ciphertext tape for transmission, and the transmission 

itself was done at machine speed in ITA2 [details], rather than at human speed in Morse Code. After 

each character, the encryption key was varied according to an advancing rotor system, not unlike the 

Enigma, only there were now twelve rotors, and they had many more pins. The Germans named this 

system Lorenz, after the Lorenz Teletypewriter Company which manufactured it, whilst the British 

named the equipment "Tunny" and its transmissions "Fish". The first Fish intercepts started to come 

through in the summer 1940. The British codenamed the Geheimschreiber "Sturgeon", after it was 

discovered being used for high level Luftwaffe communications from late 1941 (Hinsley, 1993). A full 

GCCS report, the "General Report on the Tunny" is available in digital facsimile, if interested. Unlike 

the various Enigma systems, the Lorenz systems could encipher letters as themselves. 

The basic principles of the Lorenz code were initially unravelled by Colonel John Tiltman, head of the 

Military Section, and subsequently fleshed out by William T. ("Bill") Tutte (1917-2002), who had joined 

GCCS fresh from university in January 1941. 

ASIDE: It subsequently emerged that the Siemens and Halske system had already been cracked by 

the Swedish cryptographer Arne Beurling in June 1940 (Beckman, 1996). The German diplomatic 

telegraph cable passed through Swedish waters, and had been duly tapped by Swedish Telecom. All 

Geheimschreiber traffic from the day the system was first tested on 18th April 1940 was intercepted, 

and closely studied by Beurling. He broke the code later than summer, using pen and paper 

cryptanalysis and sheer force of logic. It took him a fortnight, although he too was helped by some 

sloppy operator discipline. Professional to the last, Beurling died leaving no published explanation of 

how he broke the Geheimschreiber: "A magician," he insisted, "does not reveal his secrets". For more 

on cryptology in general, and teletype systems in particular, we recommend "Toby's Cryptopage" 

(2002 online). 

Tutte was given a good start by an unsafe transmission on 30th August 1941 from a German operator 

in Athens. This was a long despatch in fish, which failed to decipher cleanly at its destination in 

Vienna. The receiving operator duly requested retransmission, and the Athens operator unwisely used 

the same machine settings for a close, but not exact, copy of the ciphertext. 

ASIDE: It is difficult to get a straight story from the literature here. Retransmission of a pre-perforated 

teleprinter tape would not, of itself, normally require a re-encryption, and would simply produce an 

identical copy. Nevertheless, the online Tunny Report (above) clearly states (p298) that the 

retransmission had been rekeyed to tape, complete with minor mispellings. 

By painstakingly analysing those ciphertexts over a period of several months, Tutte and his 

colleagues eventually correctly deduced that the Lorenz machine had to consist of 12 different sized 

rotors, of size 23, 26, 29, 31, 37, 41, 43, 47, 51, 53, 59, and 61 (Good, 1993). 

ASIDE: The Geheimschreiber, by contrast, had ten such wheels, sized 73, 71, 69, 67, 65, 64, 61, 59, 

53, and 47. Full details in Beckman (2003). 

Aside from the rotor sizes, it was also necessary to learn the logic of their gearing. To start with there 

were five K (or chi) rotors (the 23, 26, 29, 31, and 41 pin ones), then there were five S (or psi) rotors 

(the 43, 47, 51, 53, and 59 pin ones), and finally there were two M (or mu, or motor) rotors (the 37 and 

61 pin ones). This is how they worked together ..... 





"The first set of coding wheels, K1-K5, and the first motor wheel, stepped every time. The second 

motor wheel stepped whenever the first motor wheel pattern enabled it to do so. The second set of 

coding wheels, S1-S5, stepped whenever the second motor wheel enabled it to do so." (Halton, 1993, 

p172.) 

Halton continues ..... 

"Whether or not a coding wheel reversed the sense of the digit passing through it depended on the 

setting of a tooth on its circumference, the tooth being either erect or folded down. The wheels all had 

different numbers of teeth, which were set up to the pattern specified for the day [Ed. in much the 

same way that we nowadays set the timer pins of central heating or pre-programmed lighting 

systems], and all could be rotated individually to any required position for the start of a message. The 

first set of wheels advanced one tooth for every character. Two more wheels of a similar type 

controlled the stepping of the second set of coding wheels and were called (at BP) the motor wheels. 

The first motor wheel advanced by one tooth for every character, but the second did so only when 

permitted to do so by the teeth of the first. The second set of coding wheels stepped only when 

permitted to do so by the teeth of the second motor wheel. Like the character-coding wheels, the 

motor wheels could be set to any specified tooth pattern and could be made to start from any 

position." (Halton, 1993, p169-170.) 

Gil Hayward (1993), one of the Tunny engineers, adds: 

"Each rotor [in the first group of five] was advanced by one tooth for each character transmitted []. The 

enciphering was achieved by [exclusive-OR addition.] We knew this process as 'non-carry binary 

addition' [] The second set of rotors was driven indirectly via the [two M-rotors] and now processed the 

[five code] elements once more, performing an exclusive-OR of the output of the first set with their 

own tooth states. The SZ sent the final element outputs to line in serial form in real time." (Hayward, 

1993, p178.) 

Remembering that the electrical principle was that five bits Baudot-Murray code in should give five 

bits Baudot-Murray code out, here is a diagram showing how the input pulses were routed through the 

K- and S- wheels of the SZ42 ..... 

Tutte's decryption has been described as arguably "the greatest intellectual feat of the whole war" 

(Sale, 1997), because once the technical "go" of the new machine had been established, it again 

became possible to resort to largely automated trial-and-error. The main task was to find the settings 

of the five K-rotors (Good, 1993), and the algorithm which did this was called the "double-delta" 

method. However, the number of permutations to get through was far higher than in the Enigma 

machines, so the first thing Max Newman did when he joined GCCS as head of the Tunny team in 

September 1942, was to determine that a quantum leap in computing power was required. He 

therefore drew up the detailed specification for a machine capable of automating Tutte's double-delta 

method, and his team relocated to a larger building, nicknamed "the Newmanry", to do the design 

work. They were joined by Donald Michie (1923-), straight out of school, but later professor of artificial 

intelligence at the University of Edinburgh. 

This time it was Wynn-Williams and his high-tech TRE team who put the hardware together, and the 

resulting computer, codenamed the Heath Robinson, was operational around April 1943. Here is 

Michie's own summary of its working principles: 





"The [Heath Robinson] machine incorporated two synchronised photo-electric paper tape readers, 

capable of reading 2000 char/sec. Two loops of 5-hole tape, typically more than 1000 characters in 

length would be mounted on these readers. Counts were made of any desired Boolean function of the 

two inputs. Fast counting was performed electronically, and slow operations [] by relays. The machine, 

and all its successors, were entirely automatic in operation, once started, and incorporated an on-line 

output teleprinter." (Michie, cited in Randell, 1976/2002 online, p9.) 

Good (1993, p162) adds: 

"The input to Heath Robinson was a pair of teleprinter tapes, one containing cipher and the other one 

some function of the chi wheels. The tapes would be stuck into closed loops and driven partly by 

pulleys and partly by their sprocket holes. Both tapes would be read photoelectrically and the innards 

of the machine would count the number of times that some Boolean function was equal to a dot. The 

cipher tape would have a length prime to that of the key tape, so that in the course of a 'run' all 

possibilities were examined. The machine had perhaps about two dozen vacuum or gas-filled valves 

or tubes. [] The main weakness of the design was the driving of the tapes partly by their sprocket 

holes at about a hundred times the speed of the tapes in normal teletypewriter usage. This would 

cause these holes to stretch and the tape to have a tendency to tear [.....] Also, from time to time, the 

machine would begin to smoke." 

1.6 Computerised Cryptanalysis (1943-1945 - The Colossus) 

Key Locations - "Dollis Hill": The third part of the story of British World War Two code breaking 

involves workers at another important location - "Dollis Hill", the Post Office Research Station, at 

Dollis Hill, North London. These telecommunications workshops were opened in 1921, at a time when 

the Post Office was responsible for Britain's telegraphy and telephony as well as for its postal services, 

and so it attracted some of the country's best electrical engineers. It was Britain's Bell Labs, if you like 

(but on our usual amateurish scale). The location sounds humble enough, but it concealed a very 

special secret, for in 1938 the buildings had been extended downwards to provide an emergency seat 

of government should the Cabinet Room at Whitehall be put out of commission for any reason [for an 

e-tour of what remains, click here]. 

Key Personnel: In this section, we meet Thomas Harold ("Tommy") Flowers (1905-1998), a 

telecommunications engineer at Dollis Hill. Flowers was an experienced electronics designer, and had 

been experimenting with valve technology in telephone switching gear since 1931. 

The Robinsons were transitional machines; faster than the bombes, but still largely relay-based, 

experimental, and with the reliability problems mentioned above. The decision was accordingly taken 

to build a machine which would be faster still and have greater processing power, and in order to 

achieve these higher speeds, valves were going to have to replace relays wherever possible. Britain's 

expert on valves at that time were Dollis Hill's Tommy Flowers and TREs's Charles Wynn-Williams. 

Flowers had already been involved with miscellaneous GCCS projects since February 1941, during 

which time he had met with Wynn-Williams and Turing. He had been given the specifications for 

various pieces of equipment, and had carried out the necessary engineering back at Dollis Hill, 

assisted by a colleague, Sidney W. Broadhurst. His team had also worked in 1942 with H.M. Keen at 

BTM on upgrading the bombes, and with TRE on upgrading the Robinsons. He would now do the 

same again, but working this time on what would become GCCS's - and Britain's - flagship wartime 

computing project, the Colossus. 





The detailed design for Colossus was teased out in the winter of 1942/3 by Newman and Flowers, 

with major contributions from Good and half a dozen others. The Dollis Hill group, now with additional 

assistance from W.W. Chandler, then spent the first eleven months of 1943 putting the machine 

together and testing it, and it began productive work in December 1943. The Colossus consisted of 

1500 valves, weighed about a ton, and could make do with only a single input paper tape, from which 

data could be read at the rate of 5000 characters per second. To reduce tape handling failures, the 

cipher tape was read once, and its contents written to memory (this was the essence of the advance 

over the Heath Robinson, and accounts for the much higher number of valves used). Thyratron valves 

were included as memory units. 

The British now had significant access to German communications at the highest level, and the team's 

early successes included forestalling the German counter-attack against the Anzio bridgehead in 

February 1944, and breaking into the network centred on von Rundstedt's headquarters in France in 

March 1944. As a result, Dollis Hill received an order for a number of more powerful follow-up 

machines, the Colossus 2s, and Michie contributed major improvements to the upgraded design 

(Andresen, 2001) [for more on Michie's contribution, click here]. The Colossus 2s had 2400 valves 

and could process several input streams in parallel, giving them an effective input speed of 25,000 

characters per second. More importantly, at least one of the new machines was needed to be up and 

running by 1st June 1944 to handle the increased volume of traffic expected after the Normandy 

invasion (Randell, 1977). Fortunately, Flowers' team had been strengthened by the arrival of A.W.M. 

Coombs and Wilfred Saville, and they met the deadline with literally just a couple of hours to spare. 

By the end of the war, 63 million keystrokes of German code had been deciphered (Andresen, 2001), 

and in the best traditions of "real programming", not one of the people Randell (1977) interviewed had 

any recollection of anybody ever producing any system maintenance manuals [although given the 

equally strong traditions of the British Official Secrets Acts, they were possibly lying for their country at 

this point]. 

Here is an analysis of the COLOSSUS's strengths and weaknesses, measured against the criteria of 

modernity discussed so far ..... 


than 



Analog 


Decimal 



Stored Program 

Yes Yes Yes General purpose in 

principle, but in 

practice all the inputoutput 

peripherals 

were tuned for codebreaking 

applications, 

so considerable 

reconfiguration would 

have been necessary. 

Externally 

programmable due to 

shortage of memory.




ASIDE: A moment's pause before moving away from the codebreaking applications. It is nowadays 

altogether too easy to be carried away with the technicalities of cryptology, and we should not forget 

that lives were at stake every minute of every day. When you broke a code, these tended to be your 

enemy's lives, and when you did not, they were your own. Either way, the casualties were real people, 

not numbers. Dakin (1993) recalls being emotionally moved later in the war by the number of German 

sailors receiving messages telling them that their homes had been AUSGEBOMBT, and Eyton (1993) 

reports being unable - then - to make sense of a curious phrase from an Aegean maritime intercept 

later in the war, when a cargo of Jews was reported as being en route for the ENDLÖSUNG (= "final 

solution"); the code, on this occasion, was stronger than the cipher! On the lighter side, Jack Good, it 

is reported, went out of his way to acquire an "007" car registration plate once the James Bond stories 

hit the headlines in the early 1960s, and drove it, no doubt, with a cryptic smile. To see what Hut 4 is 

doing nowadays (31st May 2003), click here. 

2 - The Harvards Mark 1 to 4 

The Harvard Mark 1 was a joint venture between IBM and Harvard University, under the general 

direction of Professor Howard Hathaway Aiken (1900-1973). Eager to develop a giant digital 

calculator to rival MIT's big analog machines (see Part 2), Aiken had approached the Monroe 

Calculating Machine Company for development funding in 1936. They had turned him down, but had 

passed him on to IBM's Thomas J. Watson, who agreed more or less on entrepreneurial instinct to 

underwrite the project. Construction began in 1937, and went on for six years [for more detail of this 

early period, click here]. The end result was that by January 1943 Aiken's team had put together a 

machine known as the Automatic Sequence-Controlled Calculator (ASCC), or "Harvard Mark 1". 

The Harvard Mark 1 was the largest (55 feet long, 8 feet high, and containing over three quarters of a 

million parts) electromechanical calculator ever built. It was sited at the IBM installation at Endicott, 

NY, and (like Colossus) was something of a "transitional" species, retaining moving parts 

characteristic of the old da Vinci machines, but incorporating Babbage-style modularity and 

programming (not surprising, since Aiken had explicitly based his first-cut design on Babbage's four 

main modules - see Part 1). It received its processing instructions on previously perforated paper tape, 

and data input/output on punched cards. It was fitted with 72 23-decimal-place registers (one of the 24 

decimal wheels making up each register was reserved for use as a sign digit), each cannibalised from 

IBM's pre-war range of electromechanical calculators, and was thus capable of doing very big sums to 

very high levels of accuracy. These registers were "accumulators" - they would store whatever 

number was put into them until next required, and then allow it to be added to. A further 60 registers 

were "read only", and were manually set to program constants prior to the run commencing. Each 

tape-punched instruction served to identify the next operation to be carried out, together with the 

location of the registers containing the operands for that operation and the destination of the answer. 

The main drive shaft rotated at 200 rpm, meaning that the machine could work at the rate of just over 

three "elementary operations" (such as simple additions) per second. 

The system remained under trial and improvement until mid-1944, whereupon it was shipped lock, 

stock, and barrel to the Harvard Computation Laboratory. It was then immediately leased by the US 

Navy's Bureau of Ships - no less than three admirals being present at the official inauguration on 7th 

August 1944 (Williams, 1999) - and put to work in aid of the war effort, with armed guards patrolling 

the campus. It continued in service until 1959. An improved version of basically the same design was 

laid down in 1942, for installation at the US Naval Proving Ground, Dahlgren, VA. This was the 

Harvard Mark 2, or the "Dahlgren Calculator" (Freeland, 1947). The basic technology was unchanged, 

but enough improvements were incorporated to push performance up to around 30 simple additions 

per second (that is to say, it was about ten times as fast as the Mark 1, but a lot noisier). It contained 





13,000 high specification multiple-contact relays (at $15 apiece), and could do floating point arithmetic. 

It was also built for greater ease of maintenance - many key components were modular and could be 

exchanged with minimal fuss in the event of failure (Freeland, 1947). A third machine in the series 

was completed in 1949, and incorporated magnetic drum storage and a stored program, and thus 

marked a major modernisation. The technical platform was mixed valve and relay (5000 and 2000 

respectively). A fourth machine, the Harvard Mark 4, went live in 1952, and was even more modern, 

but by then Harvard had lost its IBM backing, and the running was being made elsewhere. The Mark 4 

was nevertheless one of the first deployments of a newer form of computer memory device, "the 

ferrite toroid single-bit flip-flop" (more on which shortly, in the section on The Whirlwind Project). 

Here is an analysis of the first two Harvard machines' strengths and weaknesses, measured against 

the criteria of modernity discussed so far ..... 

Electronic rather than 



Analog 


Decimal 

No - electromechanical Yes No - decimal (a hangover 

from the days of the desk 

calculator, and a major 

design weakness) 




General purpose, within 

the limitations of its 

rudimentary instruction 

set, but not stored 

program. 

3 - The Bell Telephone Laboratories Machines 

Bell Labs began their involvement with computers following Stibitz's experiments with binary adding 

circuitry in 1937 (see Part 2), and although they started after Aiken their machines were much smaller 

and thus a lot quicker into service. Samuel B. Williams led their Model 1 Relay Calculator project (aka 

the "Complex Number Computer"), and had the product ready for action in January 1940. It was 

publicly demonstrated in September 1940, being operated over a teletypewriter link. It was not 

programmable, however, and this defect was remedied as an adjunct to Bell's work on flak systems in 

the Model 2 Relay Calculator (or "Relay Interpolator"), a tape-controlled device with self-checking 

arithmetic. This became operational in September 1943 at the US National Defence Research Council, 

where it was initially used to produce lifelike test data for Bell's AA Predictor No. 9. The machine 

contained 500 relays, and remained in use until 1961. Cesareo (1946) details its biquinary adding 

circuits, if interested. The Model 3 Relay Calculator (or "Ballistic Computer") was started in 1942, 

completed in June 1944, contained 1300 relays, and remained in use until 1958. It was purposedesigned 

to speed the analysis of test firing data. Juley (1947) describes it as another teletypewriter 

tape machine, and identifies four separate input tapes, one containing coded data from cine film of the 

target position, the second containing the gun control parameters under test, the third containing 

reference data, and the fourth (which was read as a continuous loop), containing the master control 

instructions, or program. Biquinary notation was used as before. The Model 4 Relay Calculator was 

basically similar to the Model 3. The Model 5 Relay Calculator (or "General Purpose Relay 

Calculator") was, as its name suggests, a truly general purpose computer, complete with conditional 

logic branching. The Model 5 was a two-off project, one machine being produced for the National 

Advisory Committee on Aeronautics, Langley Field, VA, and the other for the US Ballistic Research 

Lab, Aberdeen, MD (henceforth "BRL"). The machine was started in 1944, completed in 1946 

(Langley Field) and 1947 (BRL), contained 9000 relays, and weighed about ten tons. It was relatively 

slow, but generally reliable and required minimal changeover time in that the use of tapes allowed 

runs to be prepared offline.




The limiting factor in all these machines was still the technology. Circuits were hand-built and handsoldered 

out of individual capacitors, valves, and resistors, mounted on a metal chassis. The 

machines worked, but only after a fashion - they were big, heavy, got very hot, and kept breaking 

down as fuses blew, switches failed, and valves burned out. The next breakthrough came in 1947, 

when John Bardeen, Walter H. Brattain, and William Shockley - more Bell Labs researchers - brought 

together a number of earlier discoveries and invented the "transistor", a development for which they 

were awarded the 1956 Nobel Prize for Physics ..... 

Critical Invention - The Transistor (1947): A transistor is a "cold-running" electronic switch. In its 

original form it consisted of a "semiconducting" - that is to say, unidirectional - crystal of germanium, 

onto which was placed a metal contact. This "point contact" device made use of fundamental 

properties of this type of interface, namely that electrons are drawn away from the contact more easily 

in the conducting medium than in the non-conducting crystal. Such units could therefore be installed 

in electronic circuits in place of valve diodes, where they would rectify AC the same way, but with no 

need either (a) for a heating current, or (b) for a glass capsule. They therefore allowed the work of 

the thermionic valve to be done at fractional cost, size, and power. A different layout followed 

shortly, in which two point contacts were applied to one face of the crystal, and a flat contact on the 

opposite face. This served in place of valve triodes, allowing one part of a circuit to switch the current 

flowing in another part. 

4 - The Moore School's ENIAC and EDVAC 

"There are 10 types of people in the world - those who understand binary, and those who do not" 

(Anonymous Internet wag, October 2002.) 

As with the British codebreaking machines, the major historical step away from electromechanical 

architectures in the US came in 1943. This was when the Moore School of Electrical Engineering at 

the University of Pennsylvania built the Electronic Numerical Integrator and Calculator (or ENIAC). 

Somewhat ironically, the project only came about because the Moore School had acquired one of 

Bush's analog differential analysers, and this brought them to the attention of the technical staff at 

BRL, who had more sums to do than their own differential analyser would cope with. Lieutenant Paul 

N. Gillon, the officer in charge of computation at BRL, therefore requisitioned time on the Moore 

School machine, and Lieutenant Herman H. Goldstine was assigned to the Moore School as liaison 

officer and project coordinator. This gave Goldstine access to two differential analysers, one at BRL, 

and a bigger one at Moore (Moye, 1996), but still the backlog of ballistics computation work was piling 

up. 

Enter John William Mauchly (1907-1980), a Cincinnati physicist, and John Presper Eckert (1919- 

1995), a Philadelphia electrical engineer. Mauchly and Eckert were Moore School lecturers, and it so 

happened that the quirky performance of the analog systems had been irritating the both of them as 

well. Indeed, Goldstine's arrival coincided with a paper Mauchly had written in August 1942, proposing 

a digital electronic computer. Goldstine knew a bit about mathematics himself, and was so impressed 

with Mauchly's ideas that he immediately sought the necessary funding from the ordnance department 

budget. Moore School professor John Grist Brainerd (1904-1988) presented the business case to 

BRL's commanding officer, Colonel Leslie E. Simon, and his senior scientific advisors, and was not 

beyond using a little non-military camouflage to help his case, deliberately describing the proposed 

hardware as an "electronic diff. analyser", and so confusing digital differencing with analog 

differentiation (Winegrad, 1996). 





Brainerd was successful, and the contract for ENIAC was duly signed in June 1943. The project 

proceeded under the codename "Project PX". Brainerd was appointed project manager, Eckert chief 

engineer, and Mauchly principal consultant (Moye, 1996). Others involved were Arthur W. Burks, 

Thomas K. Sharpless, and Robert F. Shaw. Eckert's initial role was to increase the average life 

expectancy of the electronic valves which were going to be required, because the fact that large 

numbers of them were going to be used meant that the final system was otherwise at risk of being 

permanently out of service. 

ASIDE: The problem of valve burn-out, it will be recalled, had been Zuse's worry back in 1938, when 

he elected to keep the Z3 project electromechanical - see Part 2. However Tommy Flowers' advice on 

the Colossus development had been that the majority of valve failures took place when they were 

warming up, and that systems which could be switched on and left on were much less vulnerable. 

That and high specification manufacturing brought performance up to acceptable standards. 

Eckert was also responsible, he later recalled, for testing whether the Pennsylvania mice liked the 

taste of the electrical insulation on his cable stock. The types they refused to chew when half-starved 

were the ones which got used, on the grounds that the mice would be less inclined to build their nests 

inside the completed machine later on. Construction began in June 1944, final assembly took place in 

autumn 1945, the machine went live in February 1946, and was delivered to BRL in January 1947 

(Moye, 1996). It weighed in at 30 tons, contained 18,000 thermionic valves, and its computing power 

was used, yet again, to prepare military ballistics tables. It also assisted the nuclear weapons 

programme (although it took time off in 1949 to compute to a record 2035 places of decimals). Input 

was on IBM 80-column cards, and, since this was commonly available technology, it allowed the 

necessary data to be shipped in and out as trays of Hollerith cards (on one occasion, around half a 

million of them, direct from the nuclear physicists at Los Alamos). Each memory unit had its own 

external neon light, so that the electronic state of the processor could be visually assessed by the 

operator, and the machine could be run in single-instruction mode so that progression through a 

program could be step-by-step monitored if needed. Modular construction allowed critical circuit 

components to be replaced in minutes, thus helping to achieve a mean time between failures of 5.6 

hours (Muuss, 1992/2002). 

Thanks to its electronics, the ENIAC was nearly 2000 times as fast as the ASCC, leading Eckert, 

rather disparagingly, to dismiss the rival Harvard machines as just "fancy tabulators". Around 5000 

simple additions were possible per second (compared to the Mark 1's three). Moye (1996) explains 

that ENIAC could do in 30 seconds what took the Bush differential analyser 15 minutes (far less 

accurately) and a skilled mathematician 20 hours; one commentator even pointed out that it was 

faster than the projectiles it was tracking. The system was decommissioned in 1955. [To see the 

wording of the US War Department's public announcement of the project in 1946, click here.] 

Here is an analysis of the ENIAC's strengths and weaknesses, measured against the criteria of 



than 



Analog 


Decimal 



Stored Program




Yes Yes No - decimal, 10 

places of. 


General purpose, but 

not stored program. 

The ENIAC profile table still contains two significant NO entries - it computed in decimal rather than in 

binary, and it had no memory to spare for program storage. In the world of computer design, these are 

both signs of considerable immaturity, but the decimal issue represented by far the greater practical 

barrier, for it is an example of how "functional fixedness" can impede technological innovation. As with 

the Harvard Mark 1, the ENIAC's designers thought in decimal, and so presumed that their creation 

should do likewise. "Proper" computers, on the other hand, were already computing in binary rather 

than decimal. Wynn-Williams had seen this, Zuse and Stibitz had seen this, and so too had Atanasoff, 

but the Harvard and Moore School teams had simply built decimal logic circuits out of binary basics, 

and, for technical reasons beyond the scope of this paper, that was actually a circuit designer's 

nightmare. 

ASIDE: Upon learning after the war that the Americans had used 18,000 valves in their ENIAC, Zuse 

is reputed to have shaken his head and asked what on earth they had all been for. He and Schreyer 

had studied valve-based logic circuits in 1936 (see Part 2), and knew that a binary system of ENIAC's 

overall capability should need less than 3000 valves, that is to say, ENIAC was an order of magnitude 

larger than it strictly needed to be. This is a measure of the inherent inefficiency of trying to do 

decimal computation with essentially binary hardware. 

In March 1946, a dispute broke out between Eckert and Mauchly on the one hand, and the University 

of Pennsylvania on the other, as to who should own the rights to the ENIAC patents. As a result, 

Eckert and Mauchly resigned from the Moore School and formed the Electronic Control Company, 

to be renamed the Eckert-Mauchly Computer Corporation in December 1947. Neither the Moore 

School, nor Eckert and Mauchly, fully recovered from this split. 

The decimal-binary issue was not fully resolved until 1946, when the Hungarian-American John von 

Neumann (1903-1957) joined the Moore School team, just as they began work on the Electronic 

Discrete Variable Automatic Computer, or EDVAC, the ENIAC's replacement. Von Neumann had 

visited the ENIAC development in August 1944, as part of his fact-finding duties as academic advisor 

to a number of US government agencies, and had followed this up with a paper extolling the virtues of 

all things binary in 1945 (von Neumann, 1945/1982). 

Now the beauty of binary is that it simultaneously eases data transmission and manipulation. In binary 

computing machines, information is stored in "binary digits" (or "bits" for short) [the term "bit" was 

introduced in the early 1950s by the Institute of Advanced Studies' John Tukey (see next section but 

one)]. Conceptually, a bit is either a nought or a one, but physically it can be any convenient local 

state within the underlying hardware, typically a voltage being high or low, a switch being open or shut, 

an area of magnetic medium being magnetised (that is to say, "written to") or not magnetised ("not 

written to"), a hole punched or not punched into a Hollerith card or length of teletypewriter tape, or 

whatever. Such changes of state got referred to as "flip-flopping", and any mechanism which could be 

used to do it got called a "flip-flop". As a computer designer, therefore, you could store as many bits 

of information as you could build flip-flops. 

The time was now right to share a few of the secrets, and the Moore School therefore took the very 

farsighted step of ensuring that everyone in the rapidly burgeoning industry would all be singing from 

the same hymn book. Between 8th July and 31st August 1946, they ran a 48-lecture course entitled




"Theory and Techniques for Design of Electronic Digital Computers". There were 28 officially named 

attendees, including Maurice Vincent Wilkes (Cambridge), and Bletchley Park's Irving J. ("Jack") 

Good and D. Rees (both by then at the University of Manchester), and they were taught by experts 

drawn from the Harvard and Moore School teams. 

EDVAC's sponsor was the BRL at Aberdeen, but without Mauchly and Eckert it was a slow and 

troubled development. The machine was eventually assembled in August 1949, but continued to 

suffer significant teething troubles until October 1951. It sported 5000 valves, and was fitted with 128 

mercury delay lines [see next section], each capable of holding eight 44-bit words. Eckert explained 

the project problems this way: "Other people tried to build the machine that I didn't build, and they 

managed to foul it up and it never got really built decently" (Netlingo, online). Nevertheless, it 

achieved an impressive mean time between failures of around 8 hours (Muuss, 1992/2002). Here is 

an analysis of the EDVAC's strengths and weaknesses, measured against the criteria of modernity 

discussed so far ..... 


than 



Analog 


Decimal 

Yes Yes Yes Yes 




Note that we now have a run of four straight yesses across the EDVAC's key points profile, as a result 

of which many commentators rate it as the class-defining modern computer - the first working "Eckertvon 

Neumann machine" (see next section but two). The EDVAC should also get the credit for 

including the first workable "Operating System" (see Part 4), and for solving the problem of program 

"branching", known officially as "conditional control" ..... 

Key Development - Conditional Control: This is a facility whereby one machine instruction moves 

not to the immediate next but to the beginning of a logically related series of instructions further down 

or further up the program. This gives the programmer the ability to apply a degree of modularity to the 

totality of his logic. It is a vital part of effective programming, and will be further discussed in Part 5 

and Part 6. 

5 - The National Physical Laboratory Projects 

Background: Britain's National Physical Laboratory (NPL) was founded in 1902, and from its 

workshops at Teddington, Middlesex, was involved in the calibration and testing of scientific and civil 

engineering projects for a century. During the war, it took part in many top secret research and 

development projects, including Barnes Wallis's bouncing bomb, aerodynamics, and ship design. In 

the late 1940s, the Director of the NPL was Sir Charles Galton Darwin (1887-1962; grandson of the 

famous naturalist), and the Superintendent of the Mathematics Division was John R. Womersley 

(1907-1958). 

Many Colossus personnel were transferred to the NPL after the war, including Alan Turing in October 

1945 to lead their computerisation efforts. By 1946 Turing had compiled plans for a machine which 

was grandly intended to resolve, given the right programming and sufficient run time, any computable 

problem. It was thus a physical realisation of his hypothetical "Turing Machine", and was originally




intended to be bigger in terms of processing power than all the US machines put together. The NPL, 

equally grandly, believed that if Britain was going to have a large computer of its own to rival the 

American ones, then Teddington was "the obvious place for it" (Womersley, 1946). Turing presented 

his proposals in a 1945 design draft entitled "A Proposal for Development in the Mathematics Division 

[of the NPL] of an Automatic Computing Engine (ACE)". 

ASIDE - System Acronyms: Computing has a long tradition of the contrived computer acronym. 

Unlike ENIAC and EDVAC, the ACE was deliberately greater than the sum of its initials. There are 

similar "in jokes" with LEO, the Lyons machine, the fact that ACE was followed by DEUCE, and the 

fact that many nuclear weapons calculations during the 1950s were carried out, literally, by a MANIAC. 

The project did not make much progress, however, primarily because it was technically overambitious. 

The design called for a number of huge technical steps forward (not least a number of 

parallel processors and a convoluted instruction set), and was accordingly going to require more staff 

than were available (Flowers, for example, declined an offered post because he was busy repairing 

the nation's war-damaged telephone system). By December 1946, things had got so bad that the NPL 

directors called upon one of the delegates to the Moore summer school, Cambridge's Maurice Wilkes, 

for an opinion on the project's viability, and he wisely suggested that a scaled down version of the 

system be put together to test the basics (Wilkes, 1946). This was called the Pilot ACE. 

In 1948, Turing transferred to Max Newman's laboratory at Manchester, and the Pilot ACE continued 

in development for two more years under James H. Wilkinson and E.A. Newman, and executed its 

first program on 10th May 1950 (making it, they claim, the fourth group in the world to deliver a stored 

program electronic digital computer), and was publicly demonstrated in December that same year. It 

contained a mere 800 valves, could perform 16,000 simple additions per second in optimal conditions 

(making it very fast for its day), and input and output were on punched cards. The machine also had 

available 18 delay lines (eleven slow ones, each capable of storing 32 32-bit words, and seven 

smaller but faster) ..... 

Key Development - Delay Lines: This was an apparatus capable of maintaining an electrical pulse 

train indefinitely, by constantly using it to repropagate itself. The British National Physical Laboratory 

(see next section) commissioned Dollis Hill's Flowers and Coombs to do some basic research here in 

June 1946, and they had a prototype 1000-bit delay line working in January 1947. The most common 

form was the "mercury acoustic delay line", an elongated bath of mercury, some one to two metres 

long, with a crystal oscillator at both ends. The pulse train was input to the oscillator at one end, and 

thereby generated a matching pressure wave (push or no-push) within the mercury. This was then 

detected by the oscillator at the far end, and converted back into electrical pulses. Typically about 

sixteen 35-bit words would be in transit between the oscillators at any one time, arriving at around one 

bit per microsecond. The processor had to wait for the desired word to arrive at the far end before it 

could retrieve it, which was a major source of microdelay. Delay lines were used on the EDVAC, Pilot 

ACE, EDSAC, BINAC, and UNIVAC systems, and can be described as reliable but slow. 

Another GCCS veteran, Treorchy-born Donald W. Davies (1924-2000), joined the project as a 

mathematician in September 1947, and made important contributions to the final design. He also 

coded an early noughts-and-crosses computer game before going on to become a major force in 

packet-switching data transmissions (an ancestor of today's Internet). Pilot ACE was decommissioned 

in June 1956, and its main components are in the Science Museum. Work on the larger follow-up 

machines, DEUCE, Full ACE, and the American ACE-clone, the Bendix G15, is described in Part 4. 

The NPL was also involved in one of the early defence computers, MOSAIC. 





6 - The IAS Machine and the "Eckert-von Neumann" Architecture 

Having influenced the design of the Moore School's EDVAC, von Neumann returned to Princeton and 

set up a project there in March 1946, sponsored by the US's newly formed Office of Naval Research. 

The intention was to build the best that could be built in terms of performance and reliability. It was 

named the IAS machine, after the hosting Institute of Advanced Studies. The project was led by von 

Neumann, and implemented the basic design he had been preaching since 1944 (see under ENIAC 

above). The resulting hardware sported 3000 valves, and adopted a binary processing with a parallel 

bus. It could store 2048 40-bit words on magnetic drum and 1024 words in electronic form. It was fast, 

being capable of 30,000 simple instructions per second (or 1000 complex instructions such as 

division). One of their team, a programmer named John Wilder Tukey (1915-2000), is famous for 

having coined the terms "bit" (a contraction of "binary digit") and "software". 

Alert readers will have noted how John von Neumann's name has occurred several times so far. 

Basically, this is because he had established a considerable reputation as a mathematical genius 

before the war. He had joined the staff at Princeton University in 1930, and in 1933 had became one 

of the six mathematics professors at their newly founded Institute for Advanced Studies. He was thus 

automatically involved in any computer development carried out at Princeton, and, by virtue of his 

eminence, as advisor to a host of projects elsewhere (not least, the Manhattan Project). He also 

taught the young English postgraduate Alan Turing between 1936 and 1938, before the latter returned 

to Britain to work on the British codebreaking effort. 

Above all, von Neumann had used the war years to crystalise a particular technical vision of how 

digital computers ought to work, and in the closing months of the war he drew up the plans for what 

came to be called the "von Neumann architecture" for a "general purpose computer" (GPC). His 

proposals were published in Goldstine and von Neumann (1945), von Neumann (1945), and Burks, 

Goldstine, and von Neumann (1946), and did much to foster the necessary common understanding 

and standardisation of approach. 

ASIDE: The technical vision was not uniquely von Neumann's, but only he combined the 

understanding with a position of sufficient influence to do something about it (Zuse, by contrast, was 

probably technically ahead in 1946, but was working on a shoestring in a country ravaged by war). In 

the remainder of this paper, we are going to follow Maurice Wilkes' argument (Hipwell, 1999) that 

ENIAC's Presper Eckert contributed at least as much real substance to this architecture as the more 

theoretical von Neumann. He therefore prefers the term "Eckert-von Neumann architecture". 

In the event, there was little disagreement over von Neumann's proposed macro-architecture, 

because in terms of its main modules it was essentially little different to Babbage's Analytical Engine, 

a century beforehand [see Part 1]. To qualify as an "Eckert-von Neumann machine", a computer has 

to have a number of particular qualities: 

it needs to be electronic not electromechanical 

it needs to be digital not analog 

it needs a binary micro-architecture, not decimal 

it needs to be functionally organised so as to have separate modules for (1) memory, (2) control 

unit, (3) calculation, and (4) communication with the outside world (ie. input/output, or "I/O" for 

short), all interconnected by a wiring loom known as the "bus" (a term derived from the "bus-bars" 

used to carry signals around the old electromechanical switching gear). 





it needs to run binary stored programs from memory, accessing binary data temporarily in that 

same memory (from which it follows that the control unit must be able to tell the one type of 

content from the other - or else). 

These were the design concepts put across at the 1946 Moore School summer school, and they 

influenced the design of every machine then in the pipeline except the decimal computer ENIAC, 

which was already too near completion to do anything about. Specifically, it evolved into Williams and 

Kilburn's Manchester Mark 1, the NPL's Pilot ACE, Eckert and Mauchley's BINAC, the Institute of 

Advanced Studies' machine, and Wilkes' EDSAC. In short, the Eckert-von Neumann architecture 

shaped the computer as we know it today. It is therefore necessary to look in greater detail at the 

functional components, because a large proportion of modern computer jargon dates from these 

machines - click to be transferred to the associated subfile. 

7 - The Engineering Research Associates Machines 

Engineering Research Associates (ERA) was formed in January 1946 by a team of experts from the 

American wartime cryptanalysis effort. They were led by Howard T. Engstrom (1902-1962), previously 

a Yale mathematics professor, and William C. Norris (1911-). The company was based in St. Paul, 

MN, and did well thanks to the US military's continuing need for code-breaking number crunching. In 

fact, at a time when some of the Moore School and Harvard developments were struggling, ERA were 

soon "one of the most advanced computer companies in the world" (source). Their largest project 

during this period was the 1947 "Task 13" project, another early attempt at a general purpose stored 

program computer. Gray (1999/2003 online) is the most accessible source on the resulting ERA 1101. 

The early work was subsequently scaled up as the Atlas mainframe, and ownership transferred in 

1952 when ERA merged into the Remington-Rand Corporation. As explained in Part 4 (Section 1.3), 

the Atlas then formed the basis of the UNIVAC 1103 production machine. ERA's senior staff were 

never entirely happy as part of Remington, and in 1957 Norris led a minor exodus to set up the 

Control Data Corporation. 

8 - The Standards Bureau Machines 

The American National Bureau of Standards (NBS) also became involved in early computer 

development. This came about thanks to their prior interest in the production of mathematical tables - 

experience which meant they had to work very closely with military research units during the war. This 

cooperation continued after the war, and in 1947 the Office of Naval Research sponsored the 

"National Applied Mathematics Laboratories" (NAML) as the division of NBS responsible for advising 

government agencies on computing issues. This brought with it a research funding role, and resulted 

in two computer development projects. The first contract went in October 1948 to the Institute for 

Numerical Analysis at the University of California, Los Angeles (UCLA), under the direction of wartime 

code-breaker Harry D. Huskey, and the other went to its headquarters laboratories in Washington, DC, 

under the direction of Samuel N. Alexander ..... 

BIOGRAPHICAL ASIDE - HARRY D. HUSKEY: [Compiled from a number of Internet sources.] Harry 

D. Huskey (1916-) became involved in ENIAC in 1944, when it was about half built, and worked on 

input and output devices for the machine. When the ENIAC team started to split up, he accepted an 

invitation from the UK to join the ACE project at the NPL [see Section 5], where he was instrumental 

in initiating the construction of a test model. On returning to the USA in 1948, he joined the NBS, 

which then pursued two different lines of development: the serial SEAC and the parallel SWAC. 

Huskey designed SWAC in 1950-53. He moved to UC Berkeley in 1957 and in 1966 founded the 

Computer Science Department at UC Santa Cruz. After SWAC, Huskey designed a "minicomputer" 

built by Bendix as their G15. 





BIOGRAPHICAL ASIDE - SAMUEL N. ALEXANDER: From the Charles Babbage Institute website: 

"Alexander received his A.B. and B.S. from the University of Oklahoma in 1931, and earned his M.S. 

from the Massachusetts Institute of Technology in 1933. He was a laboratory engineer for Simplex 

Wire & Cable Company, a physicist in electronic instrumentation for the Navy, and senior project 

engineer for Bendix Aviation Corporation, before coming to the National Bureau of Standards in 1946. 

There he was chief of the Electronic Computer Laboratory, 1946-1954; head of Data Processing 

Systems Division, 1954-1964; and head of the Information Technology Division, 1964 until his death 

in 1967. He worked on development of input-output devices for use with electronic computers and 

wrote specifications for and supervised the procurement of the UNIVAC computer. When delivery of 

this computer was delayed by design problems, he was assigned to direct the design and assembly of 

the NBS Interim Computer, later named SEAC". 

Due to the widely separated geographical locations of the two development sites, the systems 

became known as Standards Western Automatic Computer (SWAC) and Standards Eastern 

Automatic Computer (SEAC) respectively. SWAC was a serial processing machine fitted with 40 

Williams-Kilburn electrostatic storage tubes, giving a total memory capacity of 256 40-bit words. 

Backing storage was on an 8192 word magnetic drum. The system remained in use until 1962. SEAC 

was basically an EDVAC clone (Huskey, 1980), and thus a serial processing machine. Its memory 

initially consisted of 3072 bytes of mercury delay line storage (Kirsch, 2003 online). Being a simpler 

design, and prioritised as a stop gap machine to compensate for delays on the UNIVAC project, it was 

ready earlier than SWAC, going operational in May 1950 (Ibid.). Urban (2001/2003 online) offers 

some informative and entertaining reminiscences. 

9 - The Whirlwind Project 

At MIT, meanwhile, their summer school delegates had gone straight to work on a machine called 

"Whirlwind". This work was carried out under the aegis of Professor Gordon S. Brown (1907-1996), 

then the world authority on the theory of servomechanisms (see, for example, Brown and Campbell, 

1948), whose Servomechanisms Laboratory had already spent the war years on the sort of analog 

computation, power-assisted, fire control mechanisms which had transformed the fire control industry 

from ready reckoner to lethal science. The sponsor, once again, was the Office of Naval Research. 

Now it so happened that one of Brown's 1944 projects had been the US Navy's ASCA flight simulation 

system. This was being developed to an analog computer specification, with the recently graduated 

Jay Wright Forrester (1918-) in charge of the computing aspects, and, by a fortunate coincidence, 

Forrester had on his team a young engineer named Perry Crawford. Crawford had written his master's 

thesis on the topic of digital fire control systems, and according to Forrester himself was the person 

who first called his attention to the possibility of digital computation. Forrester accordingly proposed 

that Whirlwind should do the ASCA processing digitally, rather than electromechanically, and work 

began against the revised digital specification in early 1946. It then continued as a series of 

incremental developments until a system was ready for acceptance trials in early 1950. The initial 

specification was for a ten-ton machine offering 32 different op codes. The Williams-Kilburn Tube (see 

next section but one) was for rapid access memory until that technology was replaced in 1953. 

Gordon Welchman, late of Bletchley Park, assisted the application development team between 1948 

and 1951. One of the first systems programmers was Jack Gilmore, who has some brief 

reminiscences on line. 

The Whirlwind project is rightly famous for having introduced ferrite core RAM, and for promoting the 

use of subroutines. The ferrite story began in 1949, when a Harvard researcher named An Wang 





(1920-1990) developed the ferrite toroid single bit flip-flop, and continued in 1951 when an MIT 

researcher used these units to build a workable "core memory" ..... 

Critical Invention - The Ferrite Toroid (1949) and Ferrite Core Memory (1951): Wang's invention 

was a tiny ferrite toroid. Ferrite is a clay-iron oxide mix, baked as a ceramic. It therefore has good 

magnetic properties. Before firing, the mixture can readily be pressed into shape. A toroid is the 

technical name for the shape of a doughnut, so it has a central hole through which a thin wire can be 

passed. The passage of a current through the wire will then affect the magnetic state of the ferrite, 

and the magnetic state of the ferrite will affect the passing current. This therefore offered a 

conceptually neat way of linking two electrical states (On/Off) with two magnetic states (On/Off), or, to 

put it another way, of storing electrical pulses in ferrite on demand, and retrieving them as electrical 

pulses when needed. Wang filed for a patent on 21st October 1949 (granted 17th May 1955), but his 

invention fell short of RAM as we know it today, largely because Wang himself did not fully realise the 

implications of what he had done. This required a second advance, namely of wiring the ferrite toroids 

from two directions at once, that is to say, of passing two wires through each toroid so that they ended 

up strung together like the knots ("nodes") on a fishing net. The technique was developed by MIT's 

Whirlwind team in 1951, and a matrix of 16,384 toroids was fitted to the Whirlwind in August 1953 [for 

a picture, click here]. The technology remained in use until the mid-1970s, when integrated circuits 

allowed much greater miniaturisation. 

Waldrop (2001) points out that Whirlwind was not designed for calculating per se. It was built as an 

electronic flight simulator, "a machine for which there was never an 'answer', just a constantly 

changing sequence of pilot actions and simulated aircraft responses" (p73). In consequence, the 

machine rates as the first major real-time digital computer. Forrester subsequently spent a number of 

years networking a large number of Whirlwind clones into a giant command and control system known 

as SAGE, which effectively was US strategic air defence between 1963 and 1983. 

10 - The IBM SSEC 

The Selective Sequence Electronic Calculator (SSEC) was IBM's first in-house digital computing 

project, and it owes much of its success to the fact that it was conceived in a moment of anger. Pugh 

(1984) suggests that IBM's Thomas J. Watson Sr was so deeply angered by the lack of credit given to 

IBM during the development of the Harvard Mark 1 that he authorised the follow-up project in-house. 

The project began in March 1945, and was led by Wallace J. Eckert, originally a Columbia University 

astronomer. Faced with some difficult astronomical calculations during the 1930s, Eckert had pushed 

IBM's tabulating equipment to, and beyond, its limits, so that by 1934 it could carry out multiplications 

and subtractions as well as additions, and could do so, moreover, in simple controlled sequences. 

When Watson wanted someone good, and someone non-Harvard, Eckert got the job. The 

specifications were ready in January 1946, and at Watson's direct insistence outperformed everything 

Harvard was working on. The machine was ready in July 1947, was publicly announced on 27th 

January 1948, and consisted of 21,500 relays and 12,500 valves. It had eight 20-decimal digit 

registers, and could perform about 250 simple additions per second. It was replaced in 1952 by the 

IBM701 series (see Part 4). Apart from anything else, the SSEC earned some of its fame from the fact 

that Watson sited its computer hall at 590 Madison Avenue, New York, where it was deliberately 

visible from the street [picture]. As a result, the SSEC rapidly became the popular image of what 

computers ought to look like. 

11 - The Manchester University Machines 

Some of the Bletchley Park team, initially Newman, Good, and Rees, but eventually Turing himself, 

together with some of the TRE people, notably Frederic (later Sir Frederic) Calland Williams (1911- 





1977), Thomas ("Tom") Kilburn (1921-2001), and Geoff Tootill, ended up after the war at Manchester 

University. Newman, Good, and Rees were the first to arrive in around October 1945, and 

strengthened the Department of Mathematics. Good and Rees were amongst the delegates to the 

1946 Moore School summer school, and, upon their return, the team sketched out the design for a 

second British Turing machine (to complement Turing's own proposed Turing machine at the 

NPL). Williams arrived in January 1947 as Professor of "Electrotechnics", and Kilburn and Tootill 

(initially on secondment from TRE) joined later. Using TRE surplus equipment, the team started to put 

together a Small-Scale Experimental Machine - the SSEM, or "Baby". 

ASIDE: Burton (2003 personal communication) attributes the design of the SSEM to Kilburn, assisted 

by Tootill, and points out that the motivation was as much the investigation of storage technology as 

computation. 

The main SSEM build took place during 1947, and the machine ran its first program 21st June 1948. It 

contained some 500 valves, could process seven different instructions, and could access up to 1024 

bits of randomly accessible information on what has come to be known as a Williams-Kilburn 

[Cathode Ray] Tube ..... 

Key Development - Williams-Kilburn [Cathode Ray] Tube: This was a cathode ray tube (CRT) 

(just like those used in televisions), which made use of the one-second-or-so residual electrostatic 

charge left on the screen following each passing of the electron beam [for technical details, see the 

Manchester University website]. Appropriately equipped with sensors, CRTs could thus operate as 

fast "random access" devices. The technology was subsequently used on the IAS machine, the 

Manchester Mark 1, and the Whirlwind project (until it developed ferrite core RAM in 1953), and can 

be described as fast but not particularly reliable. Impressed by the speed factor as a marketing 

advantage in their confrontation with Remington-Rand, IBM did much to improve the reliability of CRT 

technology, and installed the technology in the highly successful IBM701 series (see Part 4). 

The Baby was the world's first stored program machine (beating BINAC - see below - by nine months), 

and Kilburn wrote the first program. Tootill's technical notebook is now partly online, and shows some 

of the possible operations [page 28 is from 19th June 1948, and gives a particularly good idea of the 

sort of programming involved]. The system was demonstrated to Sir Ben Lockspeiser, Chief Scientist 

at the Ministry of Supply, in October 1948, and he was so impressed that government funding was 

made available via Ferranti Limited for a scaled up version (Lavington, 1980/2002 online). This was 

known as the "Ferranti Mark 1". 

ASIDE: There is some confusion in the literature as to the evolutionary tree leading from SSEM to the 

Ferranti Mark 1, especially when the name "Manchester Mark 1" is seen. If interested in the exact line 

of inheritance, see the University of Manchester's own material on SSEM, Manchester Mark 1, and 

Ferranti Mark 1. 

Turing joined the Mathematics Department as reader in 1948, whilst among the younger members of 

the electrotechnics team were the Cwmamman-born Gordon Eric ("Tommy") Thomas (1928-), the 

Pontypridd-born David B.G. ("Dai") Edwards (1928-), Alec Robinson, Richard Grimsdale, and J.C. 

("Cliff") West. Tommy Thomas's website is full of informative fact and anecdote, and shows that the 

Internet is no barrier to the properly trained old-timer. The Mark 1 also had access to more permanent 

storage on a magnetic drum. 





Key Development - Magnetic Drum: This was a non-ferrous cylinder, coated with magnetic medium, 

and rotated against a row of magnetic read-write heads connected to the input-output controller. It 

could thus be used a temporary storage for one or more rotations of the drum during program 

execution, or as backing storage between programs. Drums were used on the Manchester Mark 1 [for 

pictures, click here], and the Whirlwind project (although again only until it developed ferrite core RAM 

in 1953). 

12 - The Cambridge University EDSAC and the Lyons LEO 

Cambridge University's attempt at an Eckert-von Neumann machine was led by Maurice Wilkes. The 

machine in question was the Electronic Delay Storage Automatic Calculator, or EDSAC. Work 

began as soon as Wilkes returned from the Moore School summer school, and the team included J. 

Bennett, W. Renwick, R. Piggott, S.A. Barton, David J. Wheeler, and (later) Stan Gill. The 

development lifecycle was carefully managed, and the machine went live just under three years later, 

on 6th May 1949. It was based around 32 random access mercury delay lines, each holding 16 35-bit 

words, could execute around 750 simple additions per second, and was used to support departmental 

research across the university. Here is the complete set of EDSAC "order codes", as laid down in 

Wilkes and Renwick (1950/1982). Note (a) how input and output feed in and out of memory (the 

"storage locations" mentioned), and (b) how memory is manipulated by accumulators and registers. 

This is still how computers do their work. The hard part is doing it all in the right order, and that is 

where computer programmers (and lots and lots of very expensive time for testing) come in. 

A n = Add the number in storage location n into the accumulator. 

S n = Subtract the number in storage location n from the accumulator. 

H n = Transfer the number in storage location n into the multiplier register. 

V n = Multiply the number in storage location n by the number in the multiplier register and add into 

the accumulator. 

N n = Multiply the number in storage location n by the number in the multiplier register and subtract 

from the accumulator. 

T n = Transfer the contents of the accumulator to storage location n and clear the accumulator. 

U n = Transfer the contents of the accumulator to storage location n and do not clear the accumulator. 

C n = Collate the number in storage location n with the number in the multiplier register, ie. add a '1' 

into the accumulator in digital positions where both numbers have a '1', and a '0' in other digital 

positions. 

R 2 n-2 = Shift the number in the accumulator n places to the right; ie multiply it by 2 -n . 

L 2 n-2 = Shift the number in the accumulator n places to the left; ie multiply it by 2 n . 

E n = If the number in the accumulator is greater than or equal to zero execute next the order which 

stands in storage location n, otherwise proceed serially. 





G n = If the number in the accumulator is less than zero execute next the order which stands in 

storage location n, otherwise proceed serially. 

I n = Read the next row of holes on the tape and place the resulting 5 digits in the least significant 

places of storage location n. 

O n = Print the character now set up on the teletypewriter and replace it with the character 

represented by the five most significant digits in storage location n. 

F n = Place the five digits which represent the character next to be printed by the teletypewriter in the 

five most significant digits in storage location n. 

X = Round off the number in the accumulator to 16 binary digits. 

Y = Round off the number in the accumulator to 34 binary digits. 

Z = stop the machine and ring the warning bell. 

Wilkes and Renwick continue: 

"Ordinary 5-hole punched tape of the kind used in telegraphy is used for input. Each row of holes 

represents a 5-digit binary number and the basic input operation is to transfer this number to the 

store." (Wilkes and Renwick, 1950/1982, p418.) 

Wilkes is often credited with the invention of "Assembly Code", the generic name for software which 

translates human-readable instructions into machine instructions [more on this in Part 4 (Section 3.2)]. 

EDSAC was replaced in 1957 by EDSAC II. 

Here is an analysis of the EDSAC's strengths and weaknesses, measured against the criteria of 



than 



Analog 


Decimal 

Yes Yes Yes Yes 




The EDSAC was also the prototype for the Lyons Electronic Office ("LEO") series of production 

machines. Aris (2000) begins this story in 1923, when J. Lyons and Company, tea merchants and 

caterers, took on a Cambridge University mathematics graduate named John Simmons in order to 

bring some scientific rigour into the design and operation of its corporate processes. Slowly Lyons 

became one of Britain's best managed companies, and experts in what was then known as "O and M" 

(= organisation and methods) or "OR" (= operational research). This exposed them to the tabulating 

and calculating equipment of the time, and they began to incorporate this in very creative ways into 

their corporate systems. Indeed Simmons's motto was that an organisation's records ought to show its 

managers what needed to be done next, not what had already been done.




Simmons was joined in 1936 by David Caminer (1915-), who by the late 1940s had risen to manager 

of the Systems Research Office, "a forward-looking team, some twenty strong, considering new 

systems approaches and new technologies" (Aris, 2000, p5), and it was against this background of 

disciplined risk-taking that two of the company's directors, Thomas R. Thompson (d.1972) and Oliver 

Standingford, went off on a fact-finding tour of computing installations in the US. What they wanted to 

know was whether the new breed of computers was going to replace punched card tabulators, and 

what influence they were going to have on office automation. They consulted with established experts 

such as Goldstine, and upon their return prepared a computerisation proposal which would cost Lyons 

£100,000 up front, but deliver some £50,000 annual savings in administrative and clerical effort. This 

was the first attempt at electronic office automation in the civilian world, and Lyons helped defray what 

was at that time a major investment risk by allocating a further £3000 to the EDSAC team in 

Cambridge for technical advice. Lyons advertised for a project leader, and in January 1949 recruited 

an ex-TRE electronics engineer named John M.M. Pinkerton (1919-1997). No insuperable problems 

were encountered, and the machine - to all intents and purposes an EDSAC clone - ran its first 

program on 5th September 1951 (Bird, 1994). In 1949, Pinkerton devised the typical broughtforward/carried-forward 

batch processing routine for payroll applications, and with the aid of Caminer 

computerised a number of vital management systems. Caminer boldly raised his team of 

programmers in-house. In other words, he made the since-often-challenged value judgement that it 

was better to know the company and learn how to program, than the other way round. The company's 

payroll system first ran live in early 1954 (Caminer, 2001, online), and its stock replenishment system 

was sophisticated enough to allow "weather-sensitive logistics", increasing the number of salads 

supplied on hot days and the number of steak and kidney puddings on cold! 

The LEO 1 contained 5000 valves, and used mercury delay line storage. It also used three buffered 

input channels, and two buffered output channels, enabling large blocks of data to be read or written 

at a time. In this way, the record for employee (n+1) would be on its way into the machine while that 

for employee (n) was being processed and that for employee (n-1) was on its way out of the machine. 

[For some of Pinkerton's detailed reminiscences, click here; for Caminer's, click here. Later versions 

of the machine, LEO 2 and LEO 3, are described in Part 4. The last British Telecom LEO 3-26 was 

withdrawn from service in 1980, a few weeks after the present author joined them as a trainee 

systems analyst.] 

13 - BINAC and UNIVAC 

Having resigned from the Moore School, Eckert and Mauchly's next projects were the UNIVAC for the 

commercial sector and the BINAC for the military. The BINAC development started first in response to 

an order from the Northrop Aviation Company for a small high reliability machine. The build lasted 

from October 1947 to August 1949, and the system was delivered in September 1949, making it the 

first operational US stored program computer. It developed 3500 additions per second from a 700valve 

system with 512 30-bit registers, and boasted 16 order codes in its instruction set. Every critical 

module was twinned, so that each could check the output of the other, shutting down automatically 

should a discrepancy be detected. The machine was only five feet high and four feet long. 

In purely commercial terms, however, BINAC was a disaster, coming in seriously over budget on what 

had been a fixed-price contract. The eventually more successful Universal Automatic Computer, or 

UNIVAC, development followed in 1948. This began life as a one-off for the US Census Bureau, 

under a contract signed in September 1946, but again development costs soon began to exceed the 

agreed price of $350,270, and in 1948 Eckert and Mauchly had no choice but to sell 40% of their 

company to American Totalisator Company in return for an injection of capital. A subsequent deal in 





November 1949 saw the company incorporated into the Remington-Rand Corporation, who funded 

the rest of the development. 

The basic binary code used 6 substantive bits, giving it a repertoire of 64 different characters. There 

was also a seventh parity bit ..... 

Key Development - Parity Bit: Parity bits are additional bits tagged on to the end of an otherwise 

already meaningful bit sequence. They are set according to a mathematical algorithm, and then 

regularly rechecked during processing. They are thus extremely effective ways of detecting incipient 

equipment failure or file corruption. 

UNIVAC delivered 2000 simple additions per second from a 5400 valve system with 1000 84-bit 

words in mercury delay line memory [pictures]. A total of 46 machines were produced before the 

range was replaced by the UNIVAC 2 (see Part 4). They were generally reliable and comparatively 

easy to program. 

14 - Hardware Summary Table, 1943-1950 

The EDSAC, LEO 1, and UNIVAC are convenient demarcation points between computing's formative 

years and the early production years (covered in Part 4). Here is a progress summary table for those 

formative years. The material contained is from many sources, including Berkeley (1949/1961), 

Wilkes (1956), Hollingdale and Tootill (1965), Evans (1983), and a host of US and British Internet 

primary sources, including, sadly, many obituaries. The concluding entry - for UNIVAC - is repeated at 

the beginning of the first table in Part 4, because it is a transitional machine. 

Name/ 

Claim to Fame 

Relay Interpolator 

First use of biquinary 

notation for additional 

reliability 

The Bombe 

First series of UK 

electromechanical digital 

computers 

The Robinsons 

First UK electronic 

digital computers 

Project Leader(s)/ 

Purpose 

Samuel Williams, 

George Stibitz 

Ballistics computation 

for the AA Predictor No. 

9 (see Part 2). 

Max Newman, Tommy 

Flowers, Alan Turing, 

C.E. Wynn-Williams, 

Gordon Welchman, 

Jack Good (from 1941) 

Military code-breaking 





Jack Good (from 1941), 

Shaun Wylie (from 

Date/ 

Sponsor 

Started 1941 

Operational September 

1943 

Decommissioned 1961 


Laboratories, for the US 

National Defence 

Research Laboratories 

Started late 1939 

Operational late 1941 

Bletchley Park Military 

Intelligence Centre 

Started 1942 

Operational mid-1943 



Remarks 

Also known as Bell Labs 

"Model 2 Relay 

Calculator". (The Model 

1 was described at the 

end of Part 2.) 

Once the prototype had 

proven itself, several 

hundred further 

machines were built by 

1945. 

Valve-based 

experimental machines, 

soon replaced by the 

Colossus series (see 

below). 





1943) 


Ballistic Computer Samuel Williams, 

George Stibitz 


for the AA Predictor No. 

9 (see Part 2). 

Colossus 1 



Colossus 2 



ASCC (or "Harvard Mark 

I") 

Largest ever electromechanical 

calculator; 

digital rather than 

analog 

AA Predictor No. 9 

Third generation analog 

flak predictor 






Donald Michie (from 

1942) 







Donald Michie (from 

1942), A.W.M. Coombs 


Howard H. Aiken, 

Robert Campbell, 

Grace Hopper (from 

1942) 


and other important war 

work. 

Started 1942 

Operational June 1944 


Laboratories, for the US 

National Defence 

Research Laboratories 

Started January 1943 

Operational December 

1943 



Started March 1944 

Operational June 1944 



Started 1937; 

operational January 

1943 on-site at IBM, 

August 1944 at 

Harvard; further 

development to 1947 

(when replaced by 

Mark 2 - see below); 

dismantled for museum 

use 1959. 

Harvard University, 

largely funded by IBM 

Samuel Williams Started 


Bell Labs 



Calculator". 

A further nine machines 

were built by 1945. 

ASCC = Automatic 

Sequence-Controlled 

Calculator 

A work-horse, but not 

earth-shatteringly 

innovative. 

Very successful analog 

system. It would still be 

another decade before 

digital systems started to 

compete for battlefield 

computation. It did, 

however, make 

considerable use of 

digital equipment for 

testing purposes - see 

the entries for the Relay 





Z4 

First complete 

programming language 

PLANKALKÜL 

Harvard Mark II 

First computer "bug" 

located 15th September 

1945 by Grace Hopper 

(a moth jammed into 

one of the 13,000 or so 

component relays) 

ENIAC 

First purely electronic 

computer 

General Purpose Relay 

Calculator 

Early self-checking 

system, and therefore 

comparatively reliable 

Whirlwind 1 

First use of ferrite core 

memory; first real time 

command and control 

applications 

Konrad Zuse 

General purpose 

computing 

Howard Aiken, Grace 

Hopper (until 1949), 

Edmund C. Berkeley, 

Frederick Miller 

John Brainerd, John 

Mauchly (until 1946), 

Presper Eckert (ditto), 

Herman Goldstine, 

Arthur Burks, Thomas 

Sharpless, Robert 

Shaw 


and other important war 

work. 

Bell Labs team, incl. 

George Stibitz and 

Samuel Williams 

Gordon Brown, Jay 

Forrester, Robert 

Everett, Perry 

Crawford, William 

Papian, Harlan 

Anderson (from 1952), 

Started 1941 

Completed 1946 

Konrad Zuse personally 

Started 1942 

Acceptance testing July 

1947 

Delivered January 1948 

to the Naval Proving 

Ground, Dahlgren, VA 

Harvard Computation 

Labs 

Started May 1943; 

operational February 

1946; delivered to the 

Aberdeen Proving 

Ground, MD, January 

1947; recommissioned 

August 1947; further 

development until 

October 1955. 

Moore School of 

Electrical Engineering, 

University of 

Pennsylvania, for the 

Ballistics Research 

Labs, Aberdeen, MD 

Started 1944 

Two-off, one 

operational July 1946 at 

the National Advisory 

Committee for 

Aeronautics, Langley 

Field, VA, and the other 

February 1947 at the 

US Army's Ballistic 

Research Labs, 

Aberdeen, MD. 

Started 1944 as an 

analog flight simulator 

project; respecified for 

digital computation late 

1945-early 1946; 

operational June 1950; 

Interpolator and the 

Ballistic Computer 

above. 

Eckert and Mauchly fell 

out with the University of 

Pennsylvania in March 

1946, and left to form 

their own company. 



Computer". These 

machines cost roughly 

$500,000 each. 

Anderson and Olsen left 

in 1957 to found the 

Digital Equipment 

Corporation (DEC) [for a 

fuller story, click here]. 

Welchman had been one 





EDVAC 

First US large-scale von 

Neumann (ie. binary 

stored program) 

computer; came 

complete with a 

operating system 

IAS 

Early US stored 

program machine 

Pilot ACE 

Fastest ever processor 

Ken Olsen, Jack 

Gilmore (from 1950), 

Charles Adams, John 

Carr, Gordon 

Welchman (from 1948 

to 1951) 

Gunnery fire control; 

real-time simulation 

Moore School team, 

now incl. John von 

Neumann, but no 

longer Eckert and 

Mauchly, who had 

transferred to the 

UNIVAC project 

(above) 

John Von Neumann, 

Herman Goldstine, 

Julian Bigelow (from 

January 1946); Willis 

Ware (until 1952); John 

Tukey; Ralph Slutz 

Click here for the story 

of Bigelow's dog! 

John Womersley, Alan 

Turing (until 1948), Jim 

fitted with 16kb ferrite 

core store August 1953 

(enough for 1024 16-bit 

words). 

MIT, for the US Navy 

Scoping meeting 

August 1944; design 

draft 1945; build started 

1946, but subject to 

repeated design 

upgrades as problems 

were solved and new 

techniques developed; 

assembled and 

delivered while still nonoperational 

August 

1949; ran first program 

November 1951; 

operational April 1952; 

decommissioned 

December 1962. 

Moore School of 

Electrical Engineering, 

University of 

Pennsylvania, for the 

Ballistics Research 

Laboratory, Aberdeen 

Proving Ground, MD. 

Started March 1946 

Operational Spring 

1952 

Institute for Advanced 

Study, Princeton 

University 

Specification work 

1946; development 

of the Bletchley Park 

originals. 

EDVAC = Electronic 

Discrete Variable 

Automatic Computer. 

This was not a 

particularly well 

managed project. 

ORDVAC (see Part 4) 

started many months 

later and nearly beat it 

into service. 

The IAS was to all 

intents and purposes a 

research machine. It had 

no fixed delivery date, 

and was constantly 

being tinkered with as 

new ideas - some good, 

some bad - came and 

went. Thus although 

development began 

before EDSAC the 

machine did not become 

operational until after it. 

Eventually, however, it 

would spin off a number 

of major clones. 

Huskey, an American on 

placement, returned to 





at the time, with a 

separate module for 

parallel computation of 

multiplications and 

divisions. 

IBM SSEC 

First IBM in-house 

electronic digital 

computer. 

Baby 

First stored program; 

Williams tube storage. 

Harvard Mark III 

First major use of 

magnetic drum memory. 

Manchester Mark I 

First large-scale von 

Neumann computer; first 

Williams-Kilburn tube 

random access memory; 

first magnetic drum 

store; development 

prototype for Ferranti 

Mark 1 production series 

Wilkinson (from May 

1946), Edward A. 

Newman; G.G. Allway; 

Harry Huskey (from 

January 1947), Michael 

Woodger, Robin 

Gandy, Donald Davies 

(from September 1947) 

Wallace Eckert, R. 

Seeber, Frank 

Hamilton, Wayne 

Brooke 

Frederick Williams, 

Tom Kilburn, Alec 

Robinson, Geoff Tootill 

research prototype 

Howard Aiken, Grace 



An Wang (between 

1948 and 1951), 

Frederick Miller 

Frederick Williams, 

Tom Kilburn, Alan 

Turing (from September 

1948), Geoff Tootill 

(until January 1949), 

Alick Glennie, Jack 

Good (until 1948), 

David Rees (until 

1949), P.M.S.Blackett, 

David Edwards (from 

October 1948), Tommy 

Thomas (same), Alec 

Robinson, Cliff West; 

Andrew Booth 

1949; pilot operations 

April 1950, then 

constantly improved 

until discarded 1958 in 

favour of the full ACE 

(see Part 4). 

National Physical 

Laboratory 

Started March 1945; 

acceptance testing late 

1947; operational 

January 1948; 

decommissioned 

August 1952 

IBM 

Started 1947 

Operational 21st June 

1948 

Manchester University 

Started 1947 

Operational March 

1951 


Labs for the US Navy at 

Dahlgren, VA 

Started 1948; Pilot 

Operations April 1949; 

Fully operational 

October 1949; 

Replaced February 

1951 by a Ferranti Mark 

1 

Manchester University, 

with research funding 

from Ferranti and the 

Royal Society 

the US to manage the 

SWAC project, see 

below. 

SSEC = Selective 

Sequence Electronic 

Calculator 

Williams and Kilburn had 

worked together since 

1942 on a number of 

military electronics 

projects. They moved to 

Manchester University in 

1946. Tootill joined as 

Kilburn's assistant in 

1947. 

An Wang patented the 

ferrite toroid (see main 

text) in 1949, left to 

found his own company, 

Wang Labs, in 1951, and 

from 1965 was a major 

force in the pocket 

calculator market. 

Geoff Tootill left for 

Ferranti after the Baby 

had been born, and 

established close liaison 

between that company 

and Manchester 

University 

EDSAC Maurice Wilkes, David Started 1947; EDSAC = Electronic 





First full-sized stored 

program computer; first 

bootstrap (fast start) 

routine; first subroutines 

and reusable code; 

development prototype 

for J. Lyons and 

Company's LEO 

production series. 

MOSAIC 

Early British use of 

valve-transistor mix. 

BINAC 

First twinned processor 

for greater reliability; 

early use of magnetic 

tape rather than 

punched cards; first US 

stored program 

computer. 

Wheeler, W. Renwick, 

S. Barton, G. Stevens, 

Stan Gill (from 1949) 

Dollis Hill engineers 

under A.W.M. Coombs 

Harvard Mark IV Howard Aiken, Grace 



An Wang (between 

1948 and 1951), 

Frederick Miller; Ken 

Iverson (programming) 

LEO 1 

Early use of buffered I/O 

channels; early UK use 

of transistors 

SEAC 

Probably the first US 

stored program 

computer to go fully 

operational 

operational May 1949; 

further development 

until 1953; 

decommissioned July 

1958, when replaced by 

EDSAC II 

Cambridge University, 

with some sponsorship 

from J. Lyons and 

Company. 

Started 1947 


Dollis Hill, for the 

Ministry of Supply 

Eckert and Mauchly Started October 1947 

Program Testing March 

1949 

Pilot operations August 

1949 

Delivered September 

1949 

Eckert-Mauchly 

Computer Corporation, 

Philadelphia, PA (on 

behalf of Northrop 

Aviation) 

John Pinkerton, Ernest 

Lanaerts, David 

Caminer 

General purpose 

commercial computing 

SWAC Harry Huskey 

Delivered 1952 


Labs 

Started 1949 

Completed 1953 

J. Lyons and Co Ltd 

Sam Alexander Operational May 1950 

US Bureau of 

Standards, 

Washington, DC 

US Bureau of 

Delay Storage Automatic 

Calculator 

The team subsequently 

published many of their 

ideas in the first textbook 

of programming, "The 

Preparation of Programs 

for an Electronic Digital 

Computer" (Wilkes, 

Wheeler, and Gill, 1951). 

BINAC = Binary 

Automatic Computer. In 

purely commercial terms, 

this was little short of a 

disaster, forcing Eckert 

and Mauchly to sell 

control of their company 

to the Remington-Rand 

Corporation. 

Iverson subsequently 

developed the APL 

programming language. 

LEO = Lyons Electronic 

Office. 

SEAC = Standards' 

Eastern Automatic 

Computer 

SWAC = Standards' 

Western Automatic 





UNIVAC 1 

First use of magnetic 

tape as long-term 

storage; first stores 

system project (on the 

USAF machine from 

1952); first payroll 

project (on the General 

Electric machine from 

1953). 

John Mauchly and 

Presper Eckert, Grace 

Hopper (from 1949) 


Computing 

Standards, Los 

Angeles, CA 

Started 1948 

Operational March 

1951 

Initially Eckert-Mauchly 

Computer Corporation, 

Philadelphia, for the US 

Census Bureau. 

Computer 


UNIVAC = Universal 

Automatic Computer. 

Eckert and Mauchly's 

company was bought out 

by Remington-Rand in 

1950. A total of 46 

machines were 

eventually built, selling at 

around $1M each. 

1 - Computing 1951-1958 - First Generation Hardware (US) 

After the top secret development effort of the 1940s [see Part 3], a number of civilian General 

Purpose Computers (GPCs) were delivered more or less simultaneously in the early 1950s, led by the 

Ferranti Mark I and the LEO I in February 1951, and followed closely by the US Census Bureau's 

UNIVAC in March 1951. The design principles were those of the 1950 Eckert-von Neumann machine 

[reminder], and the technology was basically chassis-mounted valve-based circuitry - hot, heavy, and 

unreliable. The stage was then set for a relentless expansion in commercial data processing capacity 

as large corporations started to install Eckert-von Neumann derivatives - known nowadays as "First 

Generation" Computers - alongside their existing data tabulating machinery. As the decade 

progressed, a number of other GPCs emerged from the established centres of excellence, and the 

final list includes the IBM 701, the Harvard Mark IV, the Bell Labs Models V and VI, the NPL's DEUCE, 

Cambridge's EDSAC II, Manchester's Marks II through V, and the LEOs II and III; each faster, more 

reliable, and offering more memory than its series predecessor. But because the centres of 

excellence were themselves still learning, some surprisingly fundamental innovations were still being 

made, and in due course these would usher in a newer generation of systems. The transistor was one 

such innovation, and, having invented the technology in the first place, Bell Labs were one of the first 

to experiment with transistorised digital circuitry, and their 1954 TRADIC contained 700 point-contact 

germanium transistors. Manchester University did likewise with two small research machines, which 

they had running in November 1953 and April 1955 respectively, and so, too, did the UK Atomic 

Energy Research Establishment, Harwell, with their 1955 CADET. Among the lesser innovations in 

this period was the development of magnetic tape storage ..... 

Key Innovation - Magnetic Tape: The first coated tape method of audio recording was developed in 

1927 by Fritz Pfleumer in Germany [timeline for magnetic recording technology]. The commercial 

development rights to Pfleumer's ideas were then acquired by AEG in 1932, and with assistance in 

plastic film technology from BASF a modern format reel-to-reel tape recorder [picture] was ready for 

demonstration at the Berlin Radio Fair in 1935. This breakthrough for the broadcasting and home 

entertainment industries was not lost on the emerging data processing industry, and magnetic tape 

readers and writers were included on the Eckert-Mauchly Computer Corporation's BINAC 

development in around 1949, and then on the 1951 UNIVAC, proving faster and more reliable than 

the earlier paper tape systems.




part paper is to study the penetration of computing concepts into cognitive theory, it is worth 

noting at this juncture that magnetic tape storage has little explanatory or metaphoric value in 

this respect. The essence of a tape as a tape is that it is dismountable, which biological 

memory most certainly is not, and the essence of the data stored upon it is that it is stored 

"serially", that is to say, there is no overriding logical sequence to the individual items stored 

nor is there any quick method of retrieving a particular record from mid-file - you just have to 

start searching at the beginning and keep looking until you chance upon it, which takes time. 

Biological memory, on the other hand, remains permanently online, and seems to rely on two 

considerably more flexible storage techniques, namely (a) "sequential" storage, where the 

individual records either arise naturally in, or have been sorted into, some clear logical 

sequence (time-stamped order, say), and (b) "random access" storage, where either an "index" 

or a "hashing algorithm" [details] allows a target record to be retrieved from mid-file. We 

therefore see little mileage in the tape metaphor, although our final evaluation will not be 

available until 2004. >> 

1.1 The MIT Systems 

Two of the very biggest innovations - ferrite core memory and the concept of real-time computing for 

command and control - came from MIT's Whirlwind team. Whirlwind's success for the US Navy in the 

1940s [reminder], plus deteriorating relations with the then Soviet Union, prompted the USAF to 

commission an experimental air early-warning system from them. Whirlwind showed that such a 

complex linking of radar and computing systems was feasible on 20th April 1951, when it 

simultaneously tracked three separate aircraft from radar and computed their interception parameters 

(Waldrop, 2001) [the hard part, apparently, lay in getting the interceptors round behind their 

approaching targets]. This demonstration resulted in massive government funding for air defence 

technology, and the result (although it was not fully operationally deployed until 1963) was SAGE (= 

Semi-Automatic Ground Environment), "a continent-spanning system of 23 Direction Centres [picture], 

each housing up to 50 human operators, plus two redundant real-time computers capable of tracking 

up to 400 airplanes at once" (ibid., p75). The machines themselves were massive Whirlwind clones, 

code-numbered AN/FSQ-7, and each contained more than 50,000 valves and ran "the largest 

computer program written up to that time" (source). 

BIOGRAPHICAL ASIDE - J.C.R. LICKLIDER: J.C.R. ("Lick") Licklider (1915-1990) was a 

psychologist-in-computing who made his name on the SAGE project. He had previously been with the 

Harvard Psychoacoustics Laboratory, where he had worked on measuring and improving the 

intelligibility of the voice communication systems available to bomber crews. He was thus one of the 

founding fathers of the signal-to-noise-ratio approach to perception which burst upon the 

psychological scene in the 1950s. He joined MIT in 1950 to work on the human factors aspects of 

multiple mainframe computing, and soon became convinced that it was only a matter of time and 

good design before properly trained operators would be able more or less to hold a conversation with 

their CPU. This was the birth of the "on-line transaction processing" type of modern computing, as 

already profiled [reminder]. In 1960, Licklider summarised these ideas in what is now seen as a 

classic paper, entitled "Man-Computer Symbiosis" (Licklider, 1960/2003 online), in which he wrote "..... 

the resulting [man-computer] partnership will think as no brain has thought and process data in a way 

not approached by the information-handling machines we know today". In 1962, Licklider moved to 

the Pentagon's Advanced Research Projects Agency (ARPA), to continue his work on distributed 

command and control systems, where he put forward detailed proposals to raise the connectivity of 

the various systems then in use, so that they could exchange data more easily. He left ARPA in 1963, 

leaving these concepts to be fleshed out and made to work by his successor, Larry Roberts, under the 

name ARPANET [more on which in Part 5]. Licklider also contributed towards MIT's 1963 "Man and 





Computer" (or "MAC") project [more on which in Part 5], which eventually evolved into the world's first 

"online community" (Waldrop, 2001), and wrote a number of influential papers profiling the sort of 

knowledge interrogation software which Internet search engines have since made commonplace. 

1.2 The IBM Systems 

As we have already seen in Part 1, Part 2, and Part 3, IBM had been the data processing corporation 

half a century before binary electronics was invented. By 1945, its punched card business had 

corporate customers worldwide, with storerooms full of data and processing suites full of card sorters 

and tabulator-adders. Yet these punched card archives largely defied complex data analysis, because 

the tabulator-adders were basically little more than large desk calculators fitted with card readers - 

they were like fish out of water when given multiplications and divisions to carry out. IBM's strategy 

after the war was therefore to see to its customers first and to do pure R & D second. This, after all, 

had been the strategy which had made them number one in the first place, and their CEO, Thomas J. 

Watson, saw no reason why it should not keep them there. So they took the new-fangled digital 

circuitry and installed it in their tabulator-adders, thus turning them into tabulator-multipliers such as 

the IBM 603 (1946) and IBM 604 (1948). 

As for the pure R & D, IBM had been there with its chequebook for the 1937-1943 Harvard Mark I 

development [reminder], and had pushed through the 1947 SSEC [reminder] with no little urgency 

once Watson had decided that digital computing skills were too strategically important not to have in 

house. This was an inspired decision, and the SSEC experience immediately became the basis for 

the 1952 IBM 701 "Defence Calculator". This was a typical first generation computer, initially designed 

for the US defence market, and around 25 times faster than the SSEC it replaced. What made this 

machine historically significant is the fact that it also span off to become IBM's first top-of-the-range 

production machine for the civilian market, selling to the US Weather Bureau, aerospace companies, 

and the like. The project was directed by Nathaniel Rochester and Jerrier Haddad [team bios], and 

when the machine was formally announced on 29th April 1952 it came with enough CRT Main 

Memory for 2048 36-bit words, plus drum and tape backing store. Nineteen machines had been sold 

by the time it was replaced by the IBM 704 in 1955. The 704 was essentially a 701 upgraded to take 

the new and far more cost-effective ferrite core memory, and 123 of these were sold by the time it was 

replaced in turn by the IBM 7090 in 1960. 

The 701 was a large system, both physically and functionally, and with a price tag to match. However, 

thanks to the vision of one of its then junior engineers, Cuthbert C. Hurd (1911-1996), IBM 

management were persuaded to include a scaled down version - the IBM 650 - in their sales portfolio. 

This was a smaller mass-market machine, lacking the expensive CRT RAM, but deliberately intended 

to be compatible with their tabulating machine range. The 650s retailed at between $200,000 and 

$400,000 according to the precise configuration, and around 1800 of them were sold (Gray, 

1999/2003 online). 

The IBM 650 was also honoured to be the first production machine to offer a random (or "direct") 

access disk memory option. To understand the true significance of this particular innovation, we must 

remind ourselves that our previous mentions of random access have related to main memory (where 

the words had even stamped the initials "RA" into the acronym RAM). When it came to backing store, 

however, the situation remained that files of any size would have to be stored as a succession of 

contiguous records - perhaps key-sorted, perhaps not - on magnetic tape [see earlier inset]; main 

memory could not (and, fifty years later, still cannot) hold more than a fraction of the total data 

available to the system. And the problem with magnetic tape, of course, was that as often as not 





several thousand feet of very delicate data and several minutes of waiting would be between you and 

the record you were after. 

Now we have already seen how magnetic drum storage had been successfully implemented on the 

Harvard Mark 3 and the Manchester Mark I systems, and designers had already recognised that a 

spinning disk would have advantages over a rolling drum, if only the problems of size, cost, capacity, 

and reliability could be overcome ..... 

Key Innovation - Magnetic Disk: Inspired by the shape and ease of manufacture of the gramophone 

record, the magnetic computer disk was a platter (or stack of platters) of non-ferrous material, thinly 

coated with a magnetic oxide emulsion and accessed by a read-write head (or heads) mounted on the 

radius line. When installed as a "disk drive" computer peripheral, this technology allowed data to be 

stored in concentric circular "tracks", one beneath each position of the head(s). If you now took your 

giant tape file and wrote the records n-at-a-time onto as many tracks as it took, you could - providing 

you knew (or could in some way compute) the platter-track address - get hold of any one of them 

again in only a few tens of milliseconds, even if it were situated right at the end of the file. 

The search for workable disk technology began in earnest at IBM in 1952, under Arthur J. Critchlow 

[IBM fact sheet and pictures] and the story has recently been re-told by Rostky (1998/2004 online). 

IBM announced the new technology on May 1955, and named it RAMAC. Each 50-platter drive stored 

what would today fit onto three standard floppy disks. It remains only to note that the direct access 

facility revolutionised both operating system design and application programming. To systems 

programmers direct access technology offered the sort of "paging" which would soon be used to 

deliver "virtual memory" systems [see Part 5; Section 1.2], and to applications programmers it offered 

not just disk-based files permanently online, but also "indexed sequential" organisation thereof 

capable of converting record key into a disk address. It also, in 1961, assisted at the birth of the 

modern database. 

1.3 The Remington/Sperry Systems 

IBM did not have things entirely their own way, however, for they were facing increasing commercial 

competition in the early 1950s from the Remington Corporation [reminder]. In February 1950 and 

December 1951, respectively, Remington acquired the controlling interests in the Eckert-Mauchly 

Computer Corporation (EMCC), and Electronic Research Associates (ERA). EMCC, it will be recalled, 

was the company which the Johns Eckert and Mauchly had set up in 1946-7 to build BINAC and 

UNIVAC [reminder], and ERA was the company set up in 1946 by Howard T. Engstrom (1902-1962) 

and William C. Norris (1911-) to build the US Navy's 1947 "Task 13" machine (the machine which 

evolved into the US National Security Agency's October 1950 Atlas 1101 computer) [reminder]. And 

despite the fact that Remington's own computing department, the EMCC people, and the ERA people 

were geographically separate units, and retained a "high degree of autonomy, indeed rivalry" (Gray, 

2002/2003 online), Remington had a minor star in EMCC's UNIVAC 1, which they duly capitalised 

upon by rebranding a demilitarised variant of the Atlas 1101 [picture] as the UNIVAC 1101, complete 

with a parallel organised arithmetic unit. They also won a second National Security Agency contract 

for the Atlas II (1950-1953), an Air Force contract for the (three-off) UNIVAC 1102 (1952-1956), and 

got government permission to market a civilian version of the Atlas II, to be called UNIVAC 1103 

(Gray, 2002/2003 online). 

This was all cutting edge stuff, of course, and it was projects like these which attracted the likes of 

Seymour Cray (1925-1996) into computing. Cray joined ERA in 1951, and impressed management so 

much that in 1953 they appointed him Project Engineer for the 1103 (Breckenridge, 1996/2003 





online). He rewarded their faith in him by turning the 1103A into one of the most innovative machines 

of its day. One development in particular - a "program interrupt" facility - was developed on an 1103A 

at the Lewis Research Centre, Cleveland (Gray, 2002/2003 online), an outstation of the US National 

Advisory Committee on Aeronautics (NACA). 

Key Innovation - "Program Interrupts" (First Mention): According to Gray (2002/2003 online), the 

1103A interrupt facility "permitted the 1103A to interrupt the processing of one program to handle 

another". This might be useful, for example, if an urgent job arose part-way through the execution of a 

much longer one, but where too much processing had already been done just to abandon it and start 

again later. To do this switchover safely, requires taking careful note of the position of the executing 

program, and then being able to reinstate all the registers and Main Memory settings to their preinterrupt 

state afterwards, and this in turn requires sophisticated systems software and additional 

memory resources. We return to this topic in Part 5.




..... and so on. The decimal point, in other words, is now free to "float" from wherever it started off 

until it arrives at its standardised new position, leaving the power term to remember where it had been. 

The "precision" of a given system is the number of significant digits catered for in the mantissa. Thus 

the number 14741 in a precision-3 system (as shown above) loses the fourth and fifth significant digits 

and will be treated as 14700, and this means that we risk introducing "rounding error" into our 

arithmetic if we throw lots of significant digits at a machine which has not been set up with the 

precision necessary to handle that number of digits safely. However, the advantage of scientific 

notation is that it greatly simplifies the task of computerising the multiplication process, because your 

two multiplicands will now always lie between 1 and 9 (and can therefore easily be fixed point 

multiplied), and the power terms can be multiplied by adding the two exponents. Thus a precision-2 

multiplication of 0.0201 by 35192 will proceed as follows ..... 

(1) Convert each multiplicand to scientific notation, thus ..... 

(2.0 x 10 -2 ) x (3.5 x 10 4 ) 

(2) Do the multiplication as described above, giving ..... 

7.0 x 10 -2 x 10 4 

(3) Calculate the new exponent as described above, giving ..... 

7.0 x 10 2 

(4) Convert the answer back into everyday form, giving ..... 


700 

As it happens, the arithmetically correct answer is 707.3592, so we are about 1% out, the difference 

arising from the aforementioned rounding error. It would therefore be wise to increase our precision, 

and a precision-4 multiplication of the same two numbers duly gives a better approximation, namely 

707.3 [you actually need a precision-7 multiplication to remove the error altogether]. Unfortunately, 

rounding error is endemic in floating point arithmetic, so for scientific applications the precision is 

nowadays set high at an IEEE-recommended 32 bits for "single precision" working, or 64 bits for 

"double precision" working [details]; and even then things can go wrong, as when an unexpected 

rounding error of this sort contributed to a failure in a Patriot missile launch during the First Gulf War, 

resulting in a Scud strike on a US barracks, killing 28 servicemen [details]. As Goldberg (1991/2003 

online) puts it, "squeezing infinitely many real numbers into a finite number of bits requires an 

approximate representation", thus presenting the computing industry with the intriguing paradox that 

the faster you can do your calculations the more you need to worry whether one of these inherent 

inaccuracies has taken place. [For a fuller introduction to the intricacies of floating point arithmetic, 

complete with worked examples, click here.]




the result of the overall calculation by roughly estimating what the answer should be. In 

addition, the ability to use the "number line" may provide both conceptual (left) and visuospatial 

(right) support. Our full evaluation will not be available until 2004, but, in the meantime, 

interested readers may find no little fascination in the following neuropsychological case 

study data . 

In 1955, Remington merged with Sperry Gyroscopes to form the Sperry-Rand Corporation, and in 

1956 the 1103 was supplemented by the markedly smaller UNIVAC "File Computer". This machine 

got its name from another important innovation, namely the long-term storage of large commercial 

data files on magnetic drum, rather than on punched card - thus mounting a direct assault on IBM's 

hitherto captive market. Not only could large bodies of commercial data now be rolled forward on a 

daily, weekly, monthly, or yearly basis, but it would henceforth no longer be necessary to trolley the 

files in and out of the machine each time they were needed. 

Key Innovation - Periodic Batch Processing: Accountants and bankers have had to "carry forward" 

balances from the end of one accounting period to the beginning of the next ever since money was 

first invented, and the basic principles of book-keeping within such an accounting period are laid out in 

Luca Pacioli's "Summa de Arithmetica" (1493). [William Goetzmann, of the Yale School of 

Management, places the first recognisable bank in Uruk in Mesopotamia (modern Iraq) around 5,000 

years ago; click for details; picture ; for a delightful and totally fascinating history of the profession of 

accountancy, click here.] The calculations, however, were done by hand until the advent of 

mechanical calculators towards the end of the 19th century [reminder], and - if you were lucky enough 

to be able to afford it - were then semi-automated by the Hollerith style punched card industry of the 

early 20th century. Now the point about punched card processing is that data flowed from storage 

point to storage point via machine after machine and through tray after tray, being merged, sorted, 

updated, copied, collated, resorted, etc. Finance Departments suddenly had to be totally precise (a) in 

how they allocated their records - the cards - into files, and (b) how the files then metamorphosed as 

they passed through the various processing stages. Fortunately, although the nature of the data 

varied widely according to the nature of the business involved, there were some clear basic patterns. 

By far the greatest volume of data was "transaction data", that is to say, individual records of 

individual happenings during the period in question - individual sales, individual deliveries, individual 

money transfers, etc. However, this type of data only really meant anything when seen in the context 

(a) of the situation at the end of the preceding period (as set out in the opening balances contained in 

some sort of permanently maintained "master file"), and (b) of supporting detail such as rate books 

("reference data") and customer details (as set out in some sort of "customer file"). Thus the 

sequence of events in a typical 1920s stock system might be to open up a master file of opening stock 

levels (containing one record card per item per location), and then to "tally forward" each stock level 

by the receipts, issues, and adjustments of that item contained in one or more "transaction files". At 

period end, this tally forward would generate the theoretical carried forward stock levels, which could 

then be audited against a physical stockcheck, if necessary. The experience of the Lyons Company's 

office systems guru, John Simmons, is probably indicative. He had been appointed in 1923, 

remember, in order to bring scientific rigour into the design and operation of Lyons' corporate 

processes [to streamline, first and foremost; to automate if that helped streamline; and to computerise 

if that helped automate], and their 1949 LEO project [reminder] succeeded in automating the batch 

processing routine for payroll applications in December 1953 [more on this in Section 2.4].




diagrams to help explain cognition, they are already standard practice (albeit they are not 

always very well done technically). We have written at length on this subject elsewhere, and 

the subject can safely be approached from any of three directions, for the material constantly 

cross-refers. 

Lyons' and Sperry's pioneering work led to a growing confidence that large corporate files could be 

safely committed to a medium which was inherently unreadable by humans, and this was 

commercially highly significant because it enabled the new electronic systems to threaten the data 

tabulating industry in its own back yard; to offer an upgrade pathway for the literally thousands of tons 

of legacy data still held on punched cards. The design spotlight therefore fell on such factors as 

storage capacity, processing speed, and system reliability, and it soon became standard design 

practice to assess whether the file handling and the number crunching aspects of a given process 

presented broadly balanced demands. If they did, then all was well, but if either was slow compared to 

the other, then you had to suspect a bottleneck of some sort ..... 

Key Innovation - I/O vs CPU Bottlenecks: New terminology soon emerged to describe the various 

problem scenarios. If a process struggled when reading data in or when writing data out it was 

referred to as "peripheral bound", but if it struggled during the number-crunching phase it was 

referred to as "processor bound". When the present author joined British Telecom in 1980, he 

learned of "the Great ISOCC Tea Trolley Disaster" [English humour]. ISOCC was the BT computer 

system then responsible for charging for operator-connected calls. For a time, however, "telephone 

tickets" [picture] were being produced by the nation's telephone operators faster than the billing 

centres could process them; specifically, it took about 25 hours to process every day's input slips, so 

the processing backlog simply got longer by the day. We can no longer recall with certainty whether 

the problem lay in getting the data punched into the machine (in which case the process would have 

been peripheral bound), or in carrying out the necessary calculations once it had been (in which case 

it would have been processor bound), but it was probably the former.




output processes away from the main computer, whose precious time must not be squandered on 

sluggish menial tasks. These are delegated to a subsidiary computer, the essential function of which 

is to transcribe information from one physical medium to another ....." (p239-240.) 

The upshot of all these problems was that Lyons and Sperry perfected some historically important 

methods of coping more effectively with peripheral bound processes by strategically placing additional 

memory resources about the system ..... 

Key Innovation - "Buffers" and "Buffering": "Buffers" in general are simply areas of temporary 

storage somewhere in size between a register and a decent slice of Main Memory, and they are 

important because they allow "buffering", that is to say, "the temporary holding of information in 

transit" (Purser, 1987, p312). Like any other form of digital storage, a buffer consists ultimately of a 

contiguous series of flip-flops, and the underlying technology may vary from machine to machine. To 

understand how buffering works, we need to remind ourselves (a) that Eckert-von Neumann GPCs 

[reminder] habitually process their input and output files through reserved record areas in Main 

Memory, (b) that file reading and writing are comparatively slow processes, and (c) that Lyons' and 

Sperry's customers were trying to funnel enormous volumes of data through card or magnetic tape 

readers. Bit String Buffering: The Lyons and Sperry designers therefore added what was effectively 

a small free-standing register between the relatively fast data bus and the relatively slow peripheral 

device controllers. As data arrived in the form of a slow stream of bits from a peripheral device, it was 

loaded into an "input buffer", and only when that buffer was full was the accumulated stream 

released - either at a higher serial rate, or in parallel - onto the bus to complete its journey to its 

destination in CPU or Main Memory. This short delay left the CPU free to be getting on with 

something else. A similarly arranged "output buffer" could buffer data en route from the output 

record area to an output device. Pinkerton (1990/2003 online) profiles the buffering system on the 

LEO as follows: "The buffers in each of the input channels were all valve circuits and mercury delay 

lines. They had little short tubes which assembled individual numbers and put them into position, one 

after the other until they filled it up. The same thing on the output side; some of the buffers were 

doubled on the input though not on the output. The logic allowed four input channels and four output 

channels ....." Main Memory Buffering: It is also possible to use Main Memory for buffering. This can 

be done by doubling (etc.) the number of Main Memory record blocks allocated to each file, and by 

then routinely loading these one record ahead of the ongoing processing. This sort of "double 

buffering" introduced a degree of record-level overlap into the system, such that the input delay for 

record coincided with the processing time for record , which, in turn, coincided with the 

output delay for record . For very fast processes, "treble buffering" (etc.) could be resorted to, 

thus creating even more overlap. It follows that a given input character was likely to have been 

buffered twice on its way to the CPU, once at the device stage, and then again at the Main Memory 

stage. Instruction Buffering: We deal with another type of buffer - the "instruction buffer" - in 

Section 2.3, under the heading Pipelining. "Store and Forward" Buffering: This is a form of 

buffering which occurs (in addition to all the others) at the subordinate nodes in a communications 

network. It is needed whenever three or more computers have been interconnected, and it allows 

transmissions to be stored temporarily at node #2 en route for node #3, should the line to node #3 be 

down or otherwise engaged, or should the CPU at node #3 be too busy to accept the input 

immediately. Modern telecommunications - including the technology currently bringing you this page - 

devotes much of its attention to such problems, and network designers need to carry out a complex 

traffic queuing analysis before deciding how much buffering store to provide at each intermediate 

node.




Sperling (1960)] and (b) of saccade-based text processing [see Gough (1972)] are both prime 

candidates for it. It is also poorly handled in matters of human communications, where the 

"store and forward" version of buffering is not catered for in any of the common forms of the 

"sociogram". This, as we have repeatedly argued elsewhere [eg. Smith (1997; Chapter 1)], 

seriously erodes the explanatory value of most modern cognitive models. 

2 - Computing 1951-1958 - First Generation Hardware (UK) 

The 1945 demobilisation took all but a select few of the British wartime engineers from their top secret 

work and returned them - tightly sworn to silence by the Official Secrets Act - to peacetime 

employment. We begin this phase of our story with one of these demobilised boffins, Andrew D. Booth, 

one of the pioneers of magnetic drum memory ..... 

2.1 The Birkbeck and "British Hollerith" Machines 

Andrew D. Booth (1918-) was a Birkbeck College physicist who, as an employee of the British Rubber 

Producers Research Association, had been involved in X-ray crystallography during the war ..... 

ASIDE: The British Rubber Producers Research Association (BRPRA) was founded in 1938 to 

promote formal scientific knowledge of said product. It set up research centres in both Malaya and 

Welwyn Garden City, Hertfordshire [pictures], and one of its first researchers was Cardiff-born George 

Alan Jeffrey (1915-2000), later Professor of Crystallography at the University of Pittsburgh. Now the 

point about rubber is that it is a highly strategic commodity, perfectly capable of winning or losing wars. 

Without it, for example, you have no tyres for your vehicles or aeroplanes, no engine mountings, no oil 

seals, no hoses, no rubber dinghies, etc. Strategically, therefore, you either have to own the hot 

places in the world where the product can be grown naturally, or you have to have the raw materials 

and industrial base to manufacture it synthetically. Either way, you need a first class team of 

physicists and chemists trying to make the stuff longer lasting and constantly analysing specimens cut 

from wrecked enemy equipment to see if they had managed to do the job better than you had (much 

of Jeffrey's war was spent X-raying slices of rubber cut from wrecked German aircraft). It was this 

strategic war work which the BRPRA was there to organise, and, humble though the job might sound, 

the rubber boffins probably contributed every bit as much per capita to the war effort as did the 

codebreakers at Bletchley Park. It was Jeffrey who recruited Booth, and it was the fact that X-ray 

crystallography creates raw data like there is no tomorrow that led Booth to develop automatic 

calculating machinery as a laboratory aid to data analysis in much the same way that Wynn-Williams 

had scratched together his thyratron circuits at Cambridge in the early 1930s. 

Booth moved to Birkbeck College, University of London, after the war, and in 1946 his automatic 

calculating work brought him to the attention of the US National Defence Research Committee's chief 

"talent scout", Warren Weaver [bio follows in Section 4.1]. Weaver was intrigued by what he saw, and 

put Booth forward for a study scholarship under John von Neumann at Princeton's Institute of 

Advanced Studies [a cynic might ask in retrospect who was studying whom]. Accompanied by his 

research assistant Katherine H.V. Britten (whom he subsequently married), Booth was at Princeton 

from March to September 1947, and upon his return to Britain proceeded to build a small relay 

computer named the Automatic Relay Computer (ARC) (Lavington 1980/2003 online). He 

demonstrated this machine to Weaver on 23rd May 1948 at BRPRA's Welwyn Garden City centre 

(Hutchins, 1986/2003 online), and we shall be finding out what Weaver did next in Section 4.1. But 

what made the ARC more than just a British version of, say, the Bell Mark II relay computer [reminder] 

was the fact that Booth had cleverly linked it to a simple magnetic drum memory ..... 





Key Innovation - Magnetic Drum Storage: The advantage of magnetic drum storage over tape lies 

in the fact that the storage surface rotates continuously against a linear array of read-write heads 

[picture]. This means that your data is re-available to you once per revolution, unlike tape-borne data, 

where there is a lengthy re-wind time between passes. The sequence of magnetically coded pulses 

recorded by any one head is known as a "track", and each stored bit offers itself back to the head for 

reading and/or overwriting every few milliseconds [this rotational delay being known as its "latency"]. 

The system has quite a history, in fact, for the idea of "rolling up" your data storage in order to save 

space is as old as the scrolls of ancient times, and the idea of winding data around a cylinder, so that 

it spirals gradually from one end to the other, is clearly seen in both the Greek cryptographical system 

known as the scytale [reminder] and Edison's famous cylinder phonograph [picture]. It is therefore not 

surprising that when, in 1898, the Danish inventor Valdemar Poulsen was looking for somewhere to 

keep his magnetised wire recordings, he chose a drum [picture]; nor that the computer pioneer John 

Atanasoff toyed with the drum concept in the late 1930s on the Atanasoff-Berry Computer [reminder], 

albeit he ended up using surface capacitors as his storage substrate rather than a magnetic coating 

[picture] (Gray, 1999/2003 online). What is not so clear is who first applied Pfleumer's ferrite emulsion 

as a magnetic lacquer coating to a drum, and the first clear suggestion to this effect seems to have 

been in an MIT master's thesis by one Perry Crawford. 

BIOGRAPHICAL ASIDE [INCOMPLETE] - PERRY O. CRAWFORD (? - ?): According to Jay 

Forrester, the Whirlwind Project Director, it was Crawford who first called his attention to the 

possibility of digital computation (Forrester, 1988/2003 online), this having been the subject of his MIT 

master's thesis during the period 1939? to 1942?. Mindell (2002) mentions Crawford as having 

succeeding Claude Shannon as postgraduate student at MIT, sometime around 1940, and it was in 

the period 1940 to 1942 that Crawford developed his ideas on the use of digital methods to fire control 

problems. During 1942 to 1945 Crawford served (as an attached civilian) with the navy's Special 

Devices Centre, later at Sands Point, Long Island, building flight simulators and training devices and 

coming up with the name "Whirlwind" into the bargain. In October 1945 he went to work for the 

Special Services Division of the Office of Naval Research. Crawford left the navy in 1952, and moved 

to IBM, where he became involved in the SABRE project [see Part 5]. He was still around to be 

interviewed in 1995 (by Mindell), but seems to have published little. 

Booth experimented with the drum concept in his Birkbeck College laboratory in 1946-1947, and 

passed on the details to the Manchester University team who added it to their Baby [reminder] (Booth, 

1995/2003 online). On balance, however, it is probably fairer to credit the first large scale investment 

in drum technology neither to MIT nor Birkbeck, but to ERA's John Coombs, as part of the US Navy's 

Project Goldberg, also in around 1946. ERA used a 5" drum revolving at 3000 rpm, and set their 

packing density at 230 bits per inch [source]. The literature also mentions an 8" drum developed in 

1948 by the University of California at Berkeley (Spice, 2001/2003 online) and recording at 800 bits 

per inch, and other units on the Harvard Mark III and the SEAC. 

After making his name with the ARC, Booth moved up to thermionic valves, trying out his circuitry in a 

1949 prototype machine called the Simple Electronic Computer (SEC). When he was happy that he 

knew what he was doing, he followed this up with a number of larger, but still drum-equipped, 

machines in his 415-valved APE*C Series, where the APEC stands for "All Purpose Electronic 

Computer" and the asterisk indicates the particular commercial sponsor at the time. Thus the APERC 

was delivered to the British Rayon Research Association, the APEHC was delivered to the British 

Tabulating Machine Company ("H" because BTM were the holders of the Hollerith licence in Britain), 

the APENC was delivered to a Norwegian sponsor, and the APEXC was his own Birkbeck machine. 

The APEHC was BTM's first excursion into electronic computation, and they quickly reworked it in 





house as the HEC. They then - goaded no doubt by IBM's success with its electronic multipliers [see 

Section 1.2] - used the HEC experience to build punched card processors of their own, such as the 

BTM 541 (1953) and BTM 555 (1957) . The HEC was also the inspiration for the BTM 1200 (1954) 

and BTM 1201 (1957) computers, and thus indirectly for the ICT 1300-series and ICL 1900-series 

mainframes which followed them. 

2.2 The Last of the Boffins 

So what of the boffins who had been kept on after the war in the secretive government and military 

research stations we heard so much about in Part 3. Well basically we spoke of four such sites - 

Bletchley Park, the National Physical Laboratory (NPL), Dollis Hill, and the Research Establishment at 

Malvern, Worcestershire, so there are only four stories to tell, and we shall take them in order of 

mention. 

After the war, the GCCS at Bletchley Park continued to develop its Colossus machines, sold an 

unspecified number to friendly foreign governments [which is one of the reasons their existence was 

not acknowledged for such a long time], and remained active in the security business for many years. 

In the end, however, the unit was relocated and the site itself has recently become a museum [to see 

what Hut 4 is doing nowadays (31st May 2003), click here]. But GCCS made no further computers [or, 

if it did, they are still classified], and so it now moves outside the remit of this paper. 

We left the NPL in 1949, struggling to get their cool but decidedly complicated Pilot ACE up and 

running [reminder]. In 1948, Turing had been transferred to Max Newman's laboratory at Manchester, 

and the Pilot ACE continued in development for two more years under James H. Wilkinson and E.A. 

("Ted") Newman. It executed its first program on 10th May 1950 (making the NPL, they claim, the 

fourth group in the world to deliver a stored program electronic digital computer), and was publicly 

demonstrated in December that same year. The NPL then transferred the production rights in Pilot 

ACE to the English Electric Company [company history], the then owners of the Marconi interests, 

who tidied it up a bit before putting it to market as the Digital Electronic Universal Computing 

Engine (DEUCE), eventually delivering more than 30 machines at around £50,000 apiece [source]. A 

full (84-page!) technical specification of the DEUCE is available online. The NPL's (Full) ACE was 

ready in 1958, still with delay-line storage, whereupon it was decided that there was no longer any 

role for government owned mainframe development. Full ACE thus marked the end of the NPL's 

involvement in mainstream computer development, so it, too, now moves outside the remit of this 

paper. 

ASIDE: Rumour - probably not totally without foundation - has it that the Royal Aircraft Establishment 

actually bought two DEUCEs, so that they could run their really important programs on both of them, 

only trusting the results if both machines came up with the same answer (Kershaw, 1994/2003 

online)! For more on Pilot ACE, see Newman (1994/2003 online), and for DEUCE, see Fisher (2003 

online). 

As for the Post Office boffins at Dollis Hill - that is to say, Tommy Flowers, A.W.M. Coombs, and their 

respective teams [reminder] - their fate is easy to relate because as telecommunications engineers in 

the first place they simply reverted to their former existences. Nevertheless there were occasional 

opportunities for off-site adventure, as when Coombs was called in to assist at ..... 

..... the War Department's own high-tech installation at Malvern, home, as we mentioned briefly in Part 

3, of two of Britain's early defence computers. The first of these was a derivative of Pilot ACE called 

MOSAIC, sponsored by the Ministry of Supply for missile tracking applications. This was a 6000-valve, 





2000-transistor, serial processing machine built between 1947 and 1954 by the Post Office's A.W.M. 

Coombs and team (Lavington, 1980/2003 online), and its Main Memory comprised 1024 40-bit words 

in mercury delay lines ("nearly a ton" of the stuff, according to Lavington). The second British defence 

computer was a more technically adventurous parallel processing machine called TREAC. This was 

designed in 1947 by Albert M. Uttley, went operational in 1953, and used a 512-word Williams-Kilburn 

system for fast store. The Australian Computer Museum also remind us of the work of Trevor Pearcey 

(1919-1998), a TRE veteran who in 1946 emigrated to Australia, where he designed the 1949 

Australian CSIRAC computer, since claimed as the fifth stored program computer to be completed. 

Key Innovation - Serial vs Parallel Processing: To do things "in series" is to do them one after 

another. To do things "in parallel" is to do them simultaneously. Serial computers therefore execute 

their data moves and their arithmetical operations one after another, whilst parallel computers do 

them simultaneously. As originally conceived, parallel processing computers used one wire per bit 

when moving whole words of data at a time between their registers and their logic gates, whilst serial 

computers used one wire only, and moved one bit at a time. The parallel machines were accordingly 

much faster, but much more electrically complicated. EDSAC's Maurice Wilkes explained the 

differences this way ..... 

"The most obvious division of computing machines is between those which are serial in operation and 

those which are parallel [but] the subject is an endless one in that many different variants of each kind 

of machine are possible. I do not consider that the question of whether it is better to build a serial or a 

parallel machine will ever be finally answered; each type has its advantages, and the final decision will 

always be dependent on the designer's personal preferences, and to some extent on his terms of 

reference. Also, as time goes on, the balance of advantage and disadvantage will swing as 

improvements are made in this or that component, or as entirely new components become available. 

Certain fundamental comparisons between serial and parallel machines can, however, be drawn 

readily enough. The arithmetic unit of a parallel machine tends to be much larger than the arithmetic 

unit of a serial machine, since a separate flip-flop or equivalent circuit element must be provided to 

accommodate each digit in the various registers. Moreover, since addition of the digits takes place 

simultaneously, or nearly so, a separate adder must be provided for each digit. The disparity 

increases as the fundamental number length is increased. The control, on the other hand, is much 

simpler in a parallel machine. In the first place the necessity for the generation of a set of digit pulses 

does not arise, and secondly, the timing is much simpler, since a number can be moved, or an 

addition performed, by the application of a single pulse to a set of gates ....." (Wilkes, 1956, p66) 

What we are looking at, therefore, are alternative ways of organising a single CPU - serial for cheap 

but slow, or parallel for complicated and expensive but fast; it is just another design decision to be 

made in the early stages of a machine development project.




task, but until you know which modules count as Control Units [and that is a philosophical 

problem as much as an engineering one] you cannot be sure what these resources are each 

contributing, or, indeed, to what extent they are in fact co-operating. Moreover, because each 

component CPU can be serial or parallel within itself, you can theoretically have PDP in a 

network of simultaneously active serial CPUs, albeit this would be slower than PDP in a 

network of simultaneously active parallel machines. You could even have PDP in a part-serial, 

part parallel, processing network. Our full evaluation of the literature pertaining to this issue 

will not be available until 2004, but there is much to learn in the meantime from the literature 

on brain injury. See, for example, our timeline notes on the nineteenth century neurologists 

Dax and Lordat, or the debate between the localisers and the globalists [timeline; glossary]. 

Note especially that both the hierarchical block diagram of Kussmaul (1878) and the 

transcoding block diagram of Charcot (1883) both derive from this type of evidence, and 

therefore so, too, do modern derivatives thereof, namely Norman (1990) and Ellis and Young 

(1988) respectively. >> 

2.3 The NRDC Machines 

Another cluster of first generation computers evolved out of the tripartite collaboration of Manchester 

University, the Ferranti Company, and Elliott Brothers, and the coordinating force here was the 

Government's scientific funding office, the National Research and Development Corporation (NRDC) 

[not to be confused with the American NDRC mentioned in Section 2.1 above and seen again in 

Section 4.1]. This organisation was set up in 1949 by the then Trade Minister Harold Wilson (later 

Prime Minister between 1964 and 1970, and 1974 to 1976), under the direction of John Anthony 

Hardinge Giffard (1908-2000), Third Earl of Halsbury, in an entirely laudable attempt to stretch the 

British taxpayer's return on state-funded research. This meant co-ordinating the work of the remaining 

defence establishments with interested parties throughout industry and academia, and the newly born 

computing industry was high on the NRDC's list of strategic priorities. 

ASIDE: In a blistering appraisal of the whole NRDC experience, Hendry (1989) explains how most of 

the companies the government helped had gone out of business by the mid-1960s [and the survivors 

- as we shall be seeing in Part 5 - have either gone since, or are pretty sick]. For a number of reasons, 

some screamingly obvious but others quite subtle, the NRDC tended to "help to no advantage". It 

transpired that neither government gifts, nor advantageous development loans (nor, indeed, roving 

facilitators) were particularly effective instruments of public policy. "At no time," Hendry concludes, 

"did the aid given or offered to any firm make any perceptible difference to that firm's business 

strategy" (p168). In the ten years to 1959, the NRDC distributed just short of £1 million in cash, and 

underwrote loans for a further £1.25 million. This compares with US military patronage for the US 

computer industry during the same period of "over $1 billion" (p161). For his part, Lord Halsbury 

described the whole experience as rather like "pushing mules uphill" (Halsbury, 1991, p272), and had 

little positive to say about the quality of the decision making in the companies he had been trying to 

assist. The Ferranti company was founded by Sebastian Ziani de Ferranti (1864-1930) in 1889 in 

London, to manufacture electrical generating equipment. During the First World War they produced 

munitions, and in the 1920s moved into radio and consumer electricals. The radio experience then 

stood them in good stead come the 1930s, when the RAF needed re-equipping, and again when the 

radar contracts started to come through shortly afterwards. 

So let us start with the collaboration between Manchester University - whose Mark 1 we have already 

spoken about in detail [reminder] - and the local Ferranti works at Moston (later West Gorton), 

Manchester. The strategy here had already been hammered out at an NRDC meeting on 14th 

December 1949, and involved Ferranti preparing the Manchester Mark I for market as the Ferranti 





Mark I, thus freeing up the academics to push ahead with further technical developments. Manchester 

University therefore began the decade by getting on with the Manchester Mark II, alias "MEG". This 

incorporated a number of relatively minor developments, but when it first operated in May 1954 was 

nevertheless 20 times faster than the Mark I, thanks primarily to having changed from serial to parallel 

logic (Lavington, 1978/2003 online). This, too, was eventually marketed by Ferranti, as the "Mercury", 

and sold fairly successfully in competition with the IBM 704, because despite being a lot slower it was 

also a lot cheaper (ibid.). The university then moved on to the Manchester Mark III, an experimental 

transistorised machine, which contributed greatly to the 1956 (six-off) Metropolitan Vickers MV950, 

which has been claimed as the first operational transistorised computer. [We shall be dealing with 

Manchester's later machines, the second generation MUSE and Atlas, in Part 5]. 

Other work, meanwhile, had been going on in London and the Home Counties, the industrial player 

here being Elliott Brothers ..... 

HISTORICAL ASIDE: Elliott Brothers were founded by William Elliott in 1795 to supply Royal Navy 

officers with precision technical instruments, and had then simply grown with the technology to 

provide many of the Royal Navy's fire control systems during the analog computing era [see Part 2], 

not to mention supplying some of the parts for Babbage's original Difference Engine (Clarke, 1975). 

After World War Two, they were keen not to lose this marketing foothold, and in 1946 established a 

digital computing research unit of their own at Borehamwood, Hertfordshire. They selected John F. 

Coales (1907-1999), who had just spent the entire war on Elliott's gunnery radars, to run this unit, and 

their first major project was to develop a state-of-the-art computerised naval anti-aircraft fire control 

system, codenamed MRS. The broad specification here was for "ship-borne radar [Elliott's specialism, 

remember] [to] lock on to a target at about eight miles and then track it and supply aiming information 

to a ship's guns" (Lavington, 2000, pp8-9). A large number of R & D staff were duly taken on, and the 

computer which resulted was the Elliott 152 [picture], with logic circuits designed by Charles E. Owen 

(details in Clarke, 1975). The 152 "executed several instruction streams in parallel from an 

electrostatic read-only memory" (Lavington, 2000, p11). Government contracts being what they are, 

however, minds soon changed, and MRS was cancelled in 1949, threatening to put over half of 

Elliott's researchers out of a job (Hendry, 1989) ..... 

Now it so happened that the collapse of the MRS project coincided roughly with the inaugural meeting 

of the NRDC, so it made good political sense for the government to try to keep Coales' team together. 

The NRDC therefore chose Elliott to turn its now idle 152 into a medium-sized computer to 

complement the larger Manchester machines, issuing the first of a number of contracts in September 

1950. The result, in 1953, was the Elliott 401, the prototype of a series of five increasingly 

sophisticated "400-Series" machines. The 401 was designed by Andrew St. Johnston as a valvebased 

computer with delay line and magnetic disc memory, and ran its first program in March 1953. It 

had a front-loading modular design [picture] for ease of maintenance, achieved high availability 

figures, and actually remained in use until 1965. [For more on the 401, see Lavington (2000). The 

machine itself is now preserved at the Science Museum, London.] 

Key Innovation - Magnetic Disk Storage: One of the 401 innovations was the first magnetic disk. 

This was designed by Chris Phillips as a more compact and easier to engineer form of magnetic 

medium than the magnetic drum. However, the functional principles - track-based storage, access 

latency, etc - were the same as for the drum.




The 401 was followed in 1955 by the 402 and 403 production machines, the 403 being historically 

noteworthy because it fielded an early version of "pipelining" ..... 

Key Innovation - "Pipelining" and Related Concepts (First Mention): "Pipelining" is a technique 

"whereby multiple instructions are overlapped in execution" (Patterson and Hennessy, 1996, p125). 

We have already seen how the buffer concept allowed a temporary memory resource to be used to 

speed up I/O [see Section 1.3]. The Elliott 403 designers simply applied a similar concept to the 

instruction stream as well, arranging for the FETCH part of the basic FETCH-and-EXECUTE cycle 

[reminder] to be a step ahead of the EXECUTEs. This was accomplished by providing an 

"Instruction Buffer", to contain instruction in FETCH mode, while the Instruction Register 

[reminder] contained instruction in EXECUTE mode. Needless to say, when instruction had 

been successfully executed, an important decision needed to be made - had that instruction resulted 

in any form of program jump? If it had not, then the operands corresponding to the presumed next 

instruction, that is to say, instruction in the Instruction Buffer, could safely be used, and were 

duly copied to the Instruction Register in a ready-to-execute state. If, on the other hand, a program 

jump had been requested, then the presumption had been wrong, and the contents of the Instruction 

Buffer were unsafe, had to be discarded, and a new FETCH operation done to initiate the program 

branch. Since the safes were generally more frequent in practice than the unsafes, the technique 

delivered real savings in speed of processing. [We return to these concepts in Part 5, when dealing 

with the IBM 7030 and CDC 6600.] 

The last of the Elliott 400-Series was the Elliott 405. This sold well both at home and internationally 

[possibly under the name NCR 304?], thanks to a licensing agreement with the American NCR 

Corporation. [For more on the early Elliott range, click here or see Gabriel (1997/2003 online), or 

Hoare (1981/2003 online). Jack Smith (2001/2003 online) provides a handy memoir of how an Elliott 

403 contributed to the Australian weapons research programme. For the later "800-Series" machines, 

see Part 5.] 

Key Innovation - Direct Memory Access: The architecture devised for the Elliott 405 allowed its 

programmers to maximise CPU performance by re-routing much of its non-essential traffic around it 

rather than through it. Using an electronic equivalent of a city orbital [US = beltway], data en route 

from peripheral to Main Memory was given a direct access route, without going via the CPU (hence 

the epithet "direct"). This was implemented by giving each peripheral its own controller, with its own 

instruction set. This way of doing things immediately became an industry standard, and is nowadays 

known as "Direct Memory Access" (DMA) [further details]. 

The success of the 400-series kept Elliott so busy during the early 1950s that they even had to give 

some of their good ideas away. We refer here to the 1952 "Nicholas" - another Charles Owen design, 

with system software by George Felton - a machine which Elliott put together in a hurry to carry out inhouse 

data processing. So successful did this prove, that the NRDC arranged for Ferranti's London 

works to turn it into a marketable package, and the result - the "Pegasus" - ran its first program in 

October 1955 and entered commercial service six months later (Lavington, 2000). It proved a highly 

reliable general purpose serial computer, and despite having to make do with thermionic valves and 

magnetic drum storage, its designers had devised a "powerful, straightforward" (p16) 49-item threeoperand 

instruction set [detailed listing] which made for very concise programming, although in 

achieving this they had been assisted by one of the NRDC engineers, Christopher Strachey ..... 

BIOGRAPHICAL ASIDE - CHRISTOPHER STRACHEY: [This from Campbell-Kelly's (1985) technical 

biography.] Christopher Strachey (1916-1975) was the son of a First World War cryptologist. He 





graduated in mathematics and physics at Cambridge, and ended up as a wartime radar engineer. 

Employed in 1939 by the Standard Telephone and Cable Company on the development of thermionic 

valve technology, he had occasion to run complex calculations through a small differential analyser, 

and this aroused his interest in computing. Upon his demobilisation in 1945, he obtained a position as 

a science teacher, firstly at St. Edmund's School, Canterbury, and later at the prestigious Harrow 

School, where a chance encounter with Norbert Wiener's recently published "Cybernetics" reawakened 

his interest in computing. He therefore approached the National Physical Laboratory's Pilot 

ACE development team a few miles away across Middlesex, and by January 1951 was attempting to 

write programs in his spare time. Inspired by an article on computerised board games by the NPL's 

Donald Davies (Davies, 1950), he chose to attack the problem of getting a computing machine to play 

draughts. He did not quite succeed, but his program was promising enough to earn him a second 

attempt, this time on the Ferranti Mark I at Manchester University, and over the ensuing months he 

improved the code so much that the university promised him a job as soon as finances allowed. In the 

event, however, he was poached by Lord Halsbury's newly created NRDC before this could happen, 

and joined them in June 1952. He presented his draughts program at the Second ACM Conference in 

Toronto in September 1952, and the consequent boost to his reputation then earned him a 

succession of roving placements in both North America and Britain. This included time on site in 1953 

evaluating progress of the Elliott 401, in 1954 improving the Ferranti Pegasus, and in 1958 helping to 

develop the MUSE [more on which in Part 5]. He left the NRDC in 1959 to set up in private 

consultancy, and for six years toured the country, contributing to the development of third generation 

programming languages [see Part 6]. Finally, he was headhunted in 1965 by Oxford University to 

direct their recently established Programming Research Group, and worked there until his death in 

1975. 

One of the things Strachey did for Pegasus was to help design an enlarged set of CPU registers, in 

what is now known as a "general register" arrangement (Lavington, 2000). He began by looking at 

the inefficiencies and inadequacies of earlier instruction sets and found that the chief time stealers - 

the "red tape" instructions - were control branches, data transfers, and handling large data arrays. He 

therefore arranged a simultaneous upgrade of the logic circuitry, the register set, and the instruction 

set. A 39-bit word size was chosen, within which was a six-bit op code field. This would theoretically 

have allowed up to 64 separate operations, but only 49 were initially used. The operations were 

presented as eight blocks of eight, by sub-dividing the op code into two three-bit triplets, and 

transliterating each of these into octal [see detailed listing, Column 4]. Thus 010011 was treated as 

010 (octal/decimal = 2) followed by 011 (octal/decimal = 3), and shown as 23 (decimal 19). 

TECHNICAL ASIDE - OCTAL: Octal is the base eight numbering system, which means that each left 

order integer represents a power of eight higher than the one to its right. Only the digits 0 to 7 

inclusive are used, because the decimal 8 will always "carry one" - thus octal 7 plus octal 1 gives octal 

10 (decimal 8), and octal 777 (decimal 511) plus octal 1 gives octal 1000 (decimal 512). 

Programmers soon began to remember these numeric codes as "mnemonics" for the operations 

they controlled [more on which in Section 3.2]. Eight accumulator registers were built into the CPU, 

numbered X0 to X7, with X0 always set to binary zero. These could be used for any relevant purpose, 

specifically indexing large data arrays, loop counting, and holding intermediate values during complex 

calculations. This is how array handling worked ..... 

Key Innovation - Handling Data Arrays: When allocating Main Memory for data storage, it 

frequently happens that a data item naturally occurs a number of times. Suppose, for example, that 

you needed to store for every one of a thousand employees. The trick here 





is to set up a contiguous "data array", that is to say, one thousand consecutive word addresses in 

Main Memory. You can then select the particular occurrence you are momentarily interested in by 

"indexing" that array with a bracketed suffix. Thus will get you 

record #8 when INDEX reads 7 (all computer counts start from zero, remember), record #652 when it 

reads 651, and so on (it will also blue screen on you if you are careless with your indexing and try to 

access a value less than zero or greater than 999). 

About 40 Pegasus machines were sold before the product line was discontinued in 1962: the sixth off 

the production line helped Vickers Armstrong design the Concorde supersonic airliner, and the 25th 

has been restored to working order and is on display in the Science Museum, London. "On the 

international stage," writes Lavington (2000, p57), "the huge number of modern commodity computers 

with a general register-set architecture is testimony to the usefulness of Christopher Strachey's ideas 

for Pegasus". [For background detail on Pegasus, see Cooper (1990/2003 online) or Lavington (2000). 

Donald Kershaw was a user of this kit, and provides some recollections online (Kershaw, 2002 

online).] 

2.4 EDSAC and EDSAC Clones 

We have already explained in Part 3 how Cambridge University's EDSAC had come from behind in 

the years 1946 to 1949 to put together the world first stored program computer [reminder]. The 

machine continued to be improved during the early 1950s, and brought forth many innovations, not 

least microprogramming [more on which in Part 5] and assembler programming [see Section 3.2 

below]. For Cambridge University's official collection of reminiscences from this period, click here. 

The EDSAC development which most concerns us at this juncture is Maurice Wilkes', David 

Wheeler's, and Stan Gill's work on "subroutines", ca 1947. Smotherman (2002/2003 online) reviews 

the early history of the subroutine concept, and suggests that Ada, Countess of Lovelace, deserves 

first mention in that in 1842 she proposed reusable routines for Babbage's Analytical Engine 

[reminder]. Alan Turing then proposed much the same for the Pilot ACE in 1946, followed by the 

EDSAC team in 1947. Konrad Zuse also deserves mention in that his Z4 was upgraded ca. 1950 to 

allow a single subroutine to be executed by mounting it on a second tape reader. Here are the some 

of the technicalities ..... 

Key Innovation - Subroutines: Subroutines are "self-contained sequences of orders each of which 

performs a distinct part of the calculation in hand" (Wilkes, 1956, p86). More importantly, they allow a 

discrete operation to be developed once and then re-used as often as wanted, and as such they 

represent probably the greatest single aid to programmer productivity ever devised. In practice, 

however, there are several ways of benefiting from pre-written code. The first is to copy a trusted preexisting 

program in its entirety and then edit it where necessary, the second is to edit in a block of 

instructions from such a program, and the third is to set a block of instructions up as a program-inminiature 

- the "subroutine" - and then formally transfer control to it. All three ways work, but only the 

subroutine approach creates genuinely reusable code. The transfer of control is known as making a 

"call", and the eventual transfer back is known as a "return". Wilkes explains that it is frequently an 

engineering choice whether to perform a given operation via a subroutine, or else to hardwire in some 

additional logic circuitry. As is often the case in such matters, there is a trade off between complexity 

(circuitry costs money to design and test) and speed (subroutines add execution time), and it is the 

relative frequency of the task which often swings the decision one way or the other. The EDSAC, for 

example, deliberately chose a slow subroutine to perform division on the grounds that divisions were 

comparatively infrequent. Other "obvious examples of subroutines suitable for including in a library are 

ones for calculating sines, cosines, exponentials, and similar functions" (ibid.). 





Key Innovation - "Return Codes": One of the complications introduced by subroutines is that the 

calling program must be sensitive to the possibility that the called subroutine might fail in some way. 

Such a failure will often "crash" or "loop" the entire machine, but if it does not, then it falls to the calling 

program NOT to carry on in what is then probably a corrupt state. The way around this is (a) for the 

calling program to precede the call with the setting of a "return code" data field to a non-zero value 

(to be interpreted as "failure"), (b) for the last instruction in the called program to set that same field to 

zero (to be interpreted as "success"), and (c) for the first instruction in the calling program after the 

return to test for zero or non-zero. If the subroutine has worked, then the return code will have been 

set to zero, and the calling program can proceed about its business. If the subroutine has not worked, 

then the calling program can branch to a pre-written soft abort control sequence. So successful did 

the return code idea work in practice, that designers soon introduced a whole range of non-zero return 

codes (alternatively, "error codes" or "diagnostics"), each enabling a different type of failure to be 

accurately identified. Internet users see these every day, of course - click here for a non-existent 

Internet link, and note the resulting error code. 

EDSAC was also the inspiration for the Lyons Company's LEO I [reminder], and here again the main 

player was a demobilised wartime boffin, an ex-TRE electronics engineer named John M.M. Pinkerton 

(1919-1997). Pinkerton took charge of the project in January 1949, and the resulting EDSAC clone 

ran its first test program on 5th September 1951 (Bird, 1994), and its first business application - a 

bakeries valuation - on 29th November 1951 (Land, 1999/2003 online). It then parallel ran its first live 

payroll on 24th December 1953, at which time its designers claimed that what took an experienced 

clerk eight minutes could be done by the machine in 1.5 seconds (Bird, 2002). After careful crosschecking 

of manual and computer output, the manual system was withdrawn, and LEO ran 

unsupported on 12th February 1954 (Caminer and Land, 2003). Apart from the immediate benefit to 

their Accounts Department, Caminer and Land (2003) describe that date as marking "a world first". A 

more powerful machine, the LEO II was begun in 1954 and entered service in May 1957. Eleven of 

these machines were built, but only the last four were equipped with the more expensive ferrite core 

memory (Ferry, 2003). A third generation machine, the LEO III is mentioned in Part 5. 

3 - First Generation Software 

Alongside the electronics and engineering developments, the early 1950s also found a growing army 

of computer programmers struggling to keep their CPUs gainfully employed. The problem here was 

essentially one of too good a press, for now that potential system sponsors knew how versatile the 

new digital machinery could be, they were raising requests for computer solutions faster than the 

necessary programs could be written. Unfortunately, the penny was also beginning to drop as to how 

much time these programs could take to write; and worse, how difficult they then were to amend; and 

worse still, how often customers would ask for such amendments. Thus ..... 

"In June 1949 I realised that a good part of the rest of my life would be spent finding errors in my own 

programs." (EDSAC's Maurice Wilkes, in Sabbagh, 1999.) [We believe (May 2003) that Wilkes is still 

alive, so it is clearly good to make lots of errors!] 

3.1 Application vs Operating Software 

To cope with this early "software backlog", the computing industry was forced to specialise on the 

programming side of things the way it had specialised during its formative years in the physics and the 

engineering, when valve men with soldering irons produced the hardware and mathematicians 

decided how it should be used. It began holding summer schools (for example at Cambridge in 1950) 

and providing training courses, and at first two, and then three, and then four, areas of specific 





expertise emerged. The first distinction to emerge was that between "computer hardware" - the 

physical machine - and "computer software" - the programs which had to be written to make the 

hardware productive [the word "software" itself was coined by John Tukey at Bell Labs]. The second 

distinction was then between "application software", programs which specifically addressed this or 

that real world problem, and "operating software" (sometimes "systems software"), programs 

which helped interface these applications with the hardware in some standardised and user-friendly 

way. A computer's "Operating System", or "OS", became the software which was actually "closest 

to" the hardware, and what was happening in essence was that one program - the OS - ended up 

(thanks to yet more call-and-return branching) executing another - the application ..... 

Key Innovation - Application Software: Applications are what you, the user, want to do with your 

computer. If you wanted to run an appointments system, for example, you would need a carefully 

designed and interlocking set of "applications", each addressing one aspect of the overall task of 

managing appointments. The distinct practical purpose of each program is known as its 

"functionality", and it is functionality which gives an application its business value. The sum total of 

individual applications is known as the "application system", and the programmers who specialise in 

coding applications are known as "applications programmers". Applications programmers are 

assisted in their work by the "programming languages" available on their machines [see next 

section], and also by a deep understanding of the real world they are trying to computerise. In the 

event, the best programmers often turned out to be the worst at understanding the real world, and so 

a separate breed of beings called "systems analysts" was recruited to do that part of the job for 

them, and hybrids of the two sorts of skills - those who can manage both real world and programming 

tasks - are called "analyst-programmers". 

Key Innovation - Operating Software: The key to understanding operating software lies in grasping 

a single basic fact, namely that a high proportion of any one program re-uses code already written 

(often at great cost) elsewhere. It therefore makes sense not just to provide the applications 

programmers with a library of tried and tested subroutines, but also with a way of accessing these 

procedures from within a programmer-friendly keying environment. The operating system is the 

mechanism by which this is all achieved, and its standard functions include interfacing with the 

operator, managing the library procedures, managing the peripherals, displaying the contents of 

magnetic media, knowing what filenames have been allocated, knowing where on the available disks 

it has put each file (and the really clever operating systems are able to store a given file in a number 

of non-contiguous fragments, so that takes a lot of managing), managing disk I-O, issuing warnings, 

help, and error messages, keeping track of date and time, and marking same on the filestock so users 

know how old they are, and last (but by no means least) controlling the execution of end-user 

programs. Some operating systems are easier to get along with than others. The worst ones are 

those invented in the days before the general public were allowed to get their hands on computers. 

The easy to use ones are called "user friendly", and the trend of late has been for them to become 

more and more user friendly as time goes by. Operating systems are written by boffins and 

maintained by "systems programmers", who (because they are the only ones who understand what 

they are doing) get paid a lot more than applications programmers. 

Figure 1 shows where all these (very expensive) people fit within a commercial computing 

installation ..... 

Figure 1 - Key Roles in Corporate Computing: Here we see the basic structures and 





personalities you would find in a typical computerised corporation. Two separate organisations 

are shown. On the left hand side of the diagram is a computer manufacturing organisation 

(Ferranti, say). On the right hand side of the diagram is a client organisation, a purchaser-user 

of computing power. We have subdivided the client organisation so as to show its Computing 

Division (large panel, left, drawn over scale) separate from its end-user divisions (stacked 

panels, right, drawn under scale), and both subordinate to the Corporate Executive (top 

centre). Within the Computing Division, we show Operations and Systems Development 

activities separately, albeit both share a common physical system (pink panel). Within the 

Systems Development Department, the principal activity is the writing and testing of application 

software for the future, whilst within the Operations Department it is running application 

software already formally authorised for live use. For the reasons set out in our e-learning 

unit on the "Operations, Maintenance and Audit" of IT systems, this separation of duties is 

vitally important. Indeed in most large organisations, the operations side of things will be 

located in a purpose-built "Computer Centre", whilst the development side of things remains 

a headquarters function. 

Note the many different specialists (red captions) dotted around the various departments. In 

the manufacturing organisation, we find the boffins who build the hardware and develop the 

operating software. Hardware boffins improve circuitry and invent memory mechanisms, etc. 

Software boffins improve instruction sets, implement ever better pipelining, etc. "Maintenance 

engineers" provide an agreed level of after-sales service (green arrow) in return for a 

consideration (pink arrow). In the Operations Department, there are "operators" to tend the 

machine itself and "systems programmers" to keep it in tune. In the Systems Development 

Department, it is usual to find a number of "systems maintenance teams", each consisting of 

the analysts and programmers familiar with a particular application system. There will usually 

also be an overarching "Systems Unit" [names vary] carrying out more strategic investigation 

and design. 

Given the many specialisms, the need also arises for help desks and liaison officers (green 

captions). These include "operations support" people to liaise with the systems maintenance 

people in order (a) to schedule work on a day-to-day basis, and (b) to report and prioritise 

system errors. The maintenance team also have to liaise with the Systems Unit over the 

commissioning of broader system enhancements. [For more on the development lifecycle of a 

computer system, see our e-learning unit on "IT Project Management", and for more on the 

sort of systems disasters which result when people do not communicate effectively, see our IT 

disasters database.] 





3.2 Interpreters, Assemblers, Loaders and Linkers, and Compilers 

As far as software productivity is concerned, there has only ever been one problem and there has 

only ever been one solution to it. The problem is the unfriendliness of machine code, and the solution 

has been to distance programmers from its complexity as far as possible. Put simply, writing efficient 

machine code from scratch is onerous in the extreme, and trying to work out how you did what you did 

at a later date is nigh on impossible. As a result, generation zero development teams devoted a lot of 

effort to simplifying the process, and their answer was to write utility programs to stand between the 

programmers and the machine code. In their simplest form, such programs offered to translate from a 

relatively human-friendly vocabulary into the decidedly human-unfriendly vocabulary of the machine's 

instruction set. These utilities were the first "programming languages", and they brought with them 

some important new terminology ..... 

Key Innovation - Programming Languages, "Source Code", and "Object Code": A programming 

language is a computer program capable of recognising selected human-meaningful input commands, 

and generating as output the logically corresponding machine code instructions. The input commands 

are known as the "source code", and source code - of essence - is far easier to read for its logical 

intention than is machine code, both by the original programmer during development, and then by a 

maintenance programmer at a later date. The output is known as the "object code", and if the 

developers have done their job properly this will have been optimised for technical efficiency, as well 

as being standardised and bug-free. Special dummy source code instructions allow explanatory 





annotation to be added to the source program as aides memoires, but withheld from the machine 

code. 

Ideally, you want to be able to tell the machine something you understand, like and have it turn that 

instruction into something the machine's arithmetic unit will understand, like 

. Unfortunately, the source instructions had to 

be kept short to save memory, and so were usually abbreviated to two- or three-character 

"mnemonics" such as M for MULTIPLY ..... 

Key Innovation - Mnemonics: In everyday English, a mnemonic is a memory aid of some sort (such 

as "ROY G BIV" for the colours of the rainbow, etc.). Because there is no point in having source code 

at all unless it is distinctly memorable, mnemonic systems usually consist of a set of handy verbal 

tags ..... 

Example: We have already seen how Pegasus programmers took to identifying their binary op codes 

by their octal couplets. Thus Pegasus op code mnemonic "four-one" [see Section 2.3] instructs the 

machine to add a particular given number to a particular accumulator. Not only is "four-one" easier to 

remember than the logically identical binary code "one-zero-zero-zero-zero-one", but it is also easier 

to convert back to binary than the decimal equivalent. Thus octal 4 gives you binary 100 and octal 1 

gives you binary 001, so octal four-one gives you 100001. 

The simplest form of translation utility works on a one-to-one basis, and would nowadays be termed 

an "Interpreter". However, this level of assistance was not a lot of use to generation zero machine 

code experts, and so was little used. Instead, the boffins concentrated on a more powerful class of 

utilities known as "assembly languages", or "assemblers" for short ..... 

Key Innovation - Assembly, Loading, and Linking: "An assembler is a translator that translates 

source instructions (in symbolic language) into target instructions (in machine language), on a one to 

one basis" (Salomon, 1993/2003 online). Jack Gilmore wrote such a program for the Whirlwind, using 

mnemonic codes, and allowing decimal input. The Assembly process then substituted one or more 

machine instructions for the mnemonic and turned the decimals into binary. This was followed by 

SHORT-CODE, developed by John Mauchley, and A-0 developed by Grace Hopper. Wilkes (1956) 

claims "an assembly subroutine" for the EDSAC in 1950. 

One point about simple assemblers was that the object code they produced was actually incomplete. 

Specifically, it did not include the object code for library-held subroutines. An additional processing 

stage was therefore needed, called "loading and linking". This was/is an additional utility program 

which located the various object code modules and - after some careful address cross-calculations - 

concatenated them into a single executable object code program. When done properly, all subroutine 

calls will branch and return to valid addresses. 

Further major weaknesses gradually became apparent. Firstly, because machine instructions are 

individually very simple actions, there often needs to be a one-to-many relationship between a 

mnemonic and its equivalent object code instructions. Secondly, the machine code from one source 

instruction often needs interleaving with the machine code from adjacent source instructions. For 

example, mnemonic-by-mnemonic execution may be ideal for interacting with a human operator, but it 

is totally unable to cope with intentional program loops. And thirdly, assemblers were hardwarespecific. 

You could not write source code once, and have it assembled onto different computers. This 





is because the one-to-one relationship between source and object instruction tied the translation 

program inflexibly to the specific host's specific instruction set. This led to the development of more 

advanced, machine-independent, programming utilities called "compilers" ..... 

Key Innovation - Compilers: A "compiler" is a package of utility programs, fronted by a powerful 

conversion routine, supported by all the necessary loaders and linkers, and complete with copious 

error detection and optimisation routines. As such, they allow programmers to write neatly structured 

source code, relying heavily on subroutines, and yet leave all the technical details to the compilation 

process. Where both the amount and the complexity of the object code per source instruction is high, 

the language is known as a "high level language". In 1951, R.A. ("Tony") Brooker was put in charge of 

Manchester Mark 1 software and by 1954 had produced the first recognisable compiler, namely the 

"Mark 1 Autocode". Compilers can conveniently be divided into "scientific", where there the source 

approximates to formal mathematical representation, or "business-oriented", where the source 

approximates to everyday English. The standard example of the former is FORTRAN, and of the latter, 

COBOL. The way things timed out, many first and second generation business systems were written 

at great cost in Assembler, only to find themselves "up for a re-write" ten years later when COBOL 

came along. In investment terms, this is not good commercial practice, and British industry (at least) 

was so eager to squeeze every drop of return out of its capital, that commercial systems written in 

Assemblers during the early 1960s were still around (as "legacy systems") nearly 30 years later. The 

present author did a stint on a large Assembler maintenance project as late as 1988. 

In fact, the word "compiler" should be treated with some caution, because its meaning drifted 

somewhat in the early years. Backus (1984) argues that many early "compilers" are better regarded 

as assemblers, for their most significant aspect is their mnemonic set, rather than any program 

structuring functionality, while Hopper (1959) emphasises their role in managing subroutines. We 

include a full (albeit short) Assembly program, and elements of a compiled program, in Part 6, where 

we shall also be looking at how programming languages give programmers hands-on control over 

their machine's short term memory resources. 

4 - First Generation Artificial Intelligence 

Thus far, we have limited our consideration of software to military applications such as codebreaking 

and ballistics, and to civilian applications such as payroll. However, a number of more adventurous 

applications had been bubbling under during the late 1940s, and finally hit the headlines in the early 

1950s. These were (1) machine translation, (2) semantic networks, (3) mechanised game playing, (4) 

man-machine conversation, (5) "neurodal" networks, (6) robotics, (7) machine problem solving, and 

(8) artificial consciousness. Taken together, these make up a domain of enquiry we know today as 

"artificial intelligence" (AI), and in the remainder of this section we look at each of these AI 

traditions in turn ..... 

4.1 Machine Translation (MT) 

Hutchins (1997/2003 online) dates the idea that computers might be used to automate the process of 

natural language translation to two conversations which took place 20th June 1946 and 6th March 

1947 between the aforementioned Andrew D. Booth [see Section 2.1] and Warren Weaver (1894- 

1978), of the Rockefeller Foundation, and a letter dated 4th March 1947 from Weaver to the 

cyberneticist Norbert Wiener ..... 

BIOGRAPHICAL ASIDE - WARREN WEAVER: Weaver was a University of Wisconsin mathematics 

professor, turned career philanthropist, turned wartime government advisor, turned "wartime 'Mr Fix- 

It'". He joined the Rockefeller Foundation in 1932 as Director of the Division of Natural Sciences, did 





much of the facilitation during the early construction of the giant 200-inch Hale Telescope at the 

Mount Palomar Observatory [this project actually lasted 1928 to 1948, with a break during World War 

Two - click here for the official history], and by the start of the war had established enough of a 

reputation as a loyal scientist to be appointed Director of the Control Systems Division of the newly 

formed US National Defence Research Committee (NDRC) [not to be confused with the British NRDC 

mentioned in Section 2.2]. Much like Princeton's John von Neumann [reminder], his role within the 

NDRC made him a roving advisor-facilitator with responsibility for just about every mathematical 

aspect of the US war effort [mostly classified, of course], not least the transition from analog to digital 

computation (see Mindell, 2002). It also involved him in at least one top secret mission across the 

Atlantic. After the war, Weaver became interested in the concept of MT, and it was on one of his 

convenient Rockefeller Foundation visits that he met Booth, who, as we are about to see, shared his 

belief that MT was theoretically possible. He also went official second author on one of the major 

classics of modern information theory, namely Shannon and Weaver (1949). 

Following Weaver's inspired and energetic string-pulling, one of the first computers off the blocks was 

Booth's own ARC [see Section 2.1], and the formative event here seems to have been a chance 

professional exchange of minds between Booth and the Cambridge geneticist Richard H. Richens. 

Richens dates their first meeting to 11th November 1947, and explains that it came about thanks to 

their shared interest in punched card methods of processing research data. Richens later explained 

that ..... 

"..... the idea of using punched cards for automatic translation arose as a spin-off, fuelled by my 

realisation as editor of [the journal Plant Breeding Abstracts] that linguists conversant with the 

grammar of a foreign language and ignorant of the subject matter provided much worse translations 

that scientists conversant with the subject matter but hazy about the grammar." (Richens, 1984; 

private correspondence cited in Hutchins 2000) 

The unlikely pairing of the x-ray crystallographer with the drum storage system and the geneticist with 

punched card experience then set to work trying to mechanise translation using a stored dictionary. In 

a jointly authored paper published a few years afterwards, they explained what progress they had 

made so far, and made a number of predictions as to how they saw the new science developing ..... 

"The most obvious way of using a computing machine for translation is to code each letter of a 

proposed dictionary word in 5-binary-digit form and to store the translation in that memory location 

having the same digital value as the aggregate value of the dictionary word. Translation would then 

consist in coding the message word (a teletyper does this automatically) and then extracting the 

translation in the same or next lower (digitally valued) storage position, the first giving exact 

translation and the second the stem translation with a remainder." 

TECHNICAL ASIDE: This is our old friend the Baudot telegraph code again [reminder; details], in 

which the letters of the alphabet are given binary codes in the range 00000 (decimal 0) to 11111 

(decimal 31). The letters C-O-W, for example, would be given the following codes ..... 

C = 01110 (decimal 14) 

O = 11000 (decimal 24) 

W = 10011 (decimal 19) 

What the authors were suggesting was that they should concatenate the three separate five-bit binary 

codes to give a 15-bit binary code (in this case, 011101100010011 or decimal 15,123). This code 





would then be automatically generated by typing the word "COW" at any standard teletype keyboard, 

and all that the computer needed to do was to store the translation of that word at storage address 

15,123 in the computer's memory. In practice, however, it was not that easy ..... 

"Despite its simplicity, this scheme is quite impracticable with any existing storage device because the 

naive process of placing each dictionary word in a storage position equivalent to its own binary 

numerical version is grossly redundant." 

TECHNICAL ASIDE: The San Jose Scrabble Club lists 973 three-letter words in the English language, 

whilst there are 32,768 different 15-bit addresses between 000000000000000 and 111111111111111 

inclusive. Storing one in the other would therefore give you an unused memory factor of 

approximately 97%! This would be an unforgivable waste of resource even in the modern world of 

cheap memory, but in the 1940s would have been a total non-starter. 

"[..... so] to overcome this difficulty, a slightly more sophisticated approach has to be adopted. 

Dictionary words are stored in alphabetical order and in consecutive memory locations. Possibly these 

might be broken up into initial letter groups such that each group starts in a storage location indicated 

by the binary coded form of its initial [.....] The coded word to be translated is sent to an arithmetic 

register and is there compared, by subtraction, with the dictionary words. In this way, by means of the 

normal conditional control transfer order [ie. you only do it when the aforementioned subtraction gives 

zero, which will only happen when the two items are identical - Ed.], the dictionary stem 

corresponding to the word can be obtained and its translation printed. Next, the remainder of the 

message word, left after subtraction of the stem, is shifted to occupy the extreme left-hand register 

position, and the comparison process is repeated, this time with the words of the ending dictionary." 

(Richens and Booth, 1955, pp45-46) 

TECHNICAL ASIDE: The authors are here addressing the problem of translating morphologically 

complex words such as "COWS", where we have a singular root noun, referred to here as the "stem", 

to which is suffixed the pluralising morpheme "-S". This is the problem of "inflection" ..... 

BASIC LINGUISTICS - INFLECTION: "Inflection is variation in the form of a word, typically by means 

of an affix, that expresses a grammatical contrast which is obligatory for the stem's word class in 

some given grammatical context" [source]. It is the mechanism by which many of the world's natural 

languages cope with the number (single or plural), gender (masculine, feminine, or neuter), and 

grammatical role of adjectives and nouns, and the number (single or plural), tense (past, present, or 

future), and person (first, second, or third) of verbs. Thus the suffix will pluralise many English 

nouns (eg. "cats") or put many verbs into the third person singular (eg. "he eats"). 

Richens' and Booth's proposal was that such words should be matched in two stages, from two 

functionally separate dictionaries, namely a stem dictionary and an ending dictionary. Thus COWS 

would divide as , translate into German as and be reconstituted (on this 

occasion correctly) as KUHE. In practice, however, this was not that easy either ..... 

Other universities quick to get involved were MIT and the Harvard Computation Laboratory. The first 

MT conference was organised by Yehoshua Bar-Hillel of the University of Jerusalem (fortuitously on a 

sabbatical at MIT), and took place 17-20th June 1952. Among the delegates were Whirlwind's Jay 

Forrester, Harry Huskey, Andrew Booth, and the linguist in charge of the simultaneous translation 

facility at the 1945-1946 Nuremberg Trials, Georgetown University's Leon Dostert. This conference 

was followed two years later by the "Georgetown-IBM" demonstration of automated translation. This 





was organised by Dostert, took place on 7th January 1954 at IBM Headquarters, New York, and used 

software developed by Paul L. Garvin with technical input from IBM's Peter Sheridan and 

management backing from Cuthbert Hurd [whom we have already met in Section 1, and of whom 

even more in Part 5]. The demonstration processed a 250-word Russian-English vocabulary, and 

made front page news the next morning [see the New York Times article; see the IBM Press Release]. 

BIOGRAPHICAL ASIDE - ANTHONY G. OETTINGER (1929-): Anthony G. Oettinger (1929-) studied 

for his 1954 doctorate at the Harvard Computation Laboratory on the requirements of an automated 

Russian-English dictionary (Oettinger, 1955). Given the abysmal state of US-Russian relations in the 

McCarthy era, there is little doubt that it was the promise of being able to translate intelligence 

material out of Russian more effectively which made MT a defence issue, and which therefore 

secured it much of its funding [see, for example, Bar-Hillel (1960)]. We meet Oettinger again in 

Section 4.5. 

Unfortunately, the Richens-Booth approach only works for the relatively simple words in a language, 

and starts to descend into a morass of ever more complicated logic branches and special rules once it 

encounters "irregular" words and complex grammatical structures. Erwin Reifler, of the University of 

Washington, Seattle, was one of the first to try to design his way around this particular problem. In 

Reifler (1955), he proposed carefully allocating separate dictionaries to separate "operational form 

classes", that is to say, to each of the standard grammatical categories. Form classes with very large 

memberships include nouns (cup, table, man, etc.), adjectives (big, happy, etc.), and verbs (eat, walk, 

fly, etc.), and form classes with very small memberships include determiners (a, the, some, etc.), 

pronouns (I, she, it, etc.), auxiliary verbs (to be/have/get, etc.), prepositions (in, to, by, etc.), and 

conjunctions (and, but, because, etc.). Clearly recognising the modular nature of biological language 

processing, he then proposed separate drum memories - up to 15 of them! Thus ..... 

"If magnetic drums are used for memory storage, we may distinguish between large-drum memories 

and small-drum memories. A number of each will be needed. [.....] Operational form classes whose 

membership is large will require large drum memories. [//] Large-Drum System: For the large 

operational form classes, a total of four large-drum units will be needed, containing the following 

memories: (a) The capital memory for substantives and substantive constituents, (b) The attributive 

adjective memory, including the cardinal numerals, except the few included in the memory of 

determinative 'pro-adjectives', (c) The principal verb memory, excluding the few verbs included in the 

memory of verbs always or sometimes requiring a predicate complement, [and] (d) The predicate 

adjective memory, including all adverbs of adjectival and numerical origin. Small-Drum System: In the 

small-drum system, an individual memory will be assigned to each of the operational form classes 

with a comparatively small membership. The ten small operational form classes discussed above may 

be entered into ten small drums, but it may be desirable with German to subdivide the class of 

propositions into six sub form-classes, according to whether they require their complements in the 

following cases: genitive, dative, accusative, genitive and dative, genitive and accusative, or dative 

and accusative. This would increase the number of small drums to 15. With the smaller number of 

drums, a greater complexity of equipment and circuitry would be necessary to handle the prepositions. 

It is, thus, a matter of engineering economics whether 10 or 15 small-drum memories are used." 

(Reifler, 1955, pp159-160; italics original) 

TECHNICAL ASIDE: In retrospect, Reifler's suggestion is nowhere near as silly as it might sound; it 

was just a couple of years ahead of its time. With the development of database technology over the 

ensuing decades, it gradually became possible to store fundamentally different datasets such as 

Reifler was proposing on a single physical resource. In other words, any Database Management 





System (DBMS) worth its salt could easily make a single magnetic disk look like 15 disks. Figure 2(b) 

shows the sort of data analysis which would have needed to be done in order to allow this to happen. 

We shall be saying a lot more about how DBMS do what they do in Part 5 (Section 3.1) and Part 6, 

and about why they are so important in Part 7. 

Coping with noun plurals and (in certain languages) case variations, as well as with verb endings, was, 

however, just the beginning, for it soon became apparent how complicated were the real-life 

languages programmers were trying to translate. The problems posed by irregular verbs, or - worse - 

by the use of ironical or figurative language, or by the intricacies of pronoun resolution, or by the 

effects of context, or by "polysemy" (that is to say, the multiple meanings of words), have still not 

been overcome half a century later, and the 1950s efforts were often laughable. Here, from 

Masterman (1967, p202), is an example of just how hopeless simple word-for-word translation can be 

[compare (2) and (3) for intelligibility, and note that Latin is a heavily inflected language] ..... 

(1) ORIGINAL LATIN: Possibile est, at non expertum, omnes species eiusdem generis ab eadem 

specie ortum traxisse. 

(2) WORD-FOR-WORD MACHINE TRANSLATION: Possible is however not prove/lacking all 

species/appearance same genus/son-in-law from same species/appearance arise draw. 

NB: Note the underlined alternatives here. These are examples of the multiple meanings mentioned 

above, where a single L1 word has two or more valid L2 translations, and where the final choice relies 

on contextual cues. 

(3) FINAL ENGLISH: It is possible, though not proved, that all species of the same genus have been 

derived from the same species. 

Now Margaret Masterman (1910-1986) knew Richens thanks to their joint involvement with 

Cambridge University's Language Research Unit ..... 

"Research on MT at Cambridge began with the informal meetings of the Cambridge Language 

Research Group in 1954. In 1956 a grant was received from the National Science Foundation to 

pursue MT research, and the Cambridge Language Research Unit (CLRU) was formed, a research 

organisation independent of the University of Cambridge, with Margaret Masterman [wife of the 

philosopher R.B. Braithwaite] as director. In later years research grants were also received from the 

US Air Force Office of Scientific Research, the Office of Scientific and Technical Information (London), 

the Canadian National Research Council, and the Office of Naval Research (Washington, DC). By 

1967, active research on MT at CLRU had declined; many of its members had moved elsewhere, 

mainly within the Artificial Intelligence field and often with a continued interest in MT [.....] There were 

four main themes in its MT research: the thesaurus approach, the concept of an interlingua, 'pidgin' 

translation, and lattice theory. The focus was primarily on semantic problems of MT, and syntactic 

questions were treated secondarily. Although procedures were intended to be suitable for computers, 

most of the proposals were tested only by manual or punched card simulations because access to a 

computer proved to be difficult for many years." Hutchins (1986/2003 online) 

All four CLRU avenues of attack are directly relevant to our argument, including their investigations of 

pidgin. Indeed, one of the group's most fruitful observations was that there were some rather telling 

similarities between the halting and generally awkward word-for-word machine translations [sentence 

(2) above] and real life "pidgins" ..... 





BASIC LINGUISTICS - PIDGINS AND CREOLES: A "pidgin" is "a reduced language resulting from 

contact between groups with no common language", and a "creole" is "a pidgin or jargon that has 

become the native language of an entire speech community, often as a result of slavery or other 

population displacements" [source]. Thus Pidgin English is any rudimentary form of English, 

especially if spoken by aboriginal peoples for trading purposes, and the pidgin spoken in Papua New 

Guinea contains many quaint phonetic corruptions, such as lusim (= abandon), bigpela man (= adult), 

klostu (= almost), and narapela (= same again) [to see the full dictionary, click here]. 

The academic point was that since pidgins somehow contained all that was necessary to render a 

complex message meaningful across a language barrier, it might make sense to design some form 

of "mechanical pidgin" into your machine translation system. And if you did this carefully, you would 

then be able to record most of L1's inflections in coded form, tucked in as "pidgin markers" 

alongside the word stems, giving you what is known as a "continuous form" translation. With a 

continuous form version safely under your belt, you would have a much better chance of producing a 

contextually, as well as grammatically, sound L2 draft. According to Masterman (1967), the term 

"mechanical pidgin" came from Richens. Here, still from Masterman (1967, p202), is how sentence (2) 

above might look in continuous form, complete with inset markers ..... 

(4) CONTINUOUS FORM MACHINE TRANSLATION WITH INFLECTION MARKERS: Possible z is 

however not prove/lacking z all m species/appearance same g genus/son-in-law z from same 

species/appearance o arise z draw p. 

Masterman selected her inflection markers from the following list from Richens and Booth (1955, 

p35) ..... 

a = accusative case; d = dative case; f = future tense; g = genitive case; i = indicative mood; l = 

locative case; m = multiple; n = nominative case; o = oblique; p = past tense; q = passive form; r = 

partitive; s = subjunctive mood; u = untranslatable; v = vacuous; z = unspecific 

The technical name for an intermediate translation form of this sort is an "interlingua" ..... 

Key Innovation - Interlinguas: An "interlingua" is a language form intentionally divorced from both 

L1 and L2 in a translation, but from which both L1 and L2 (and, ideally, all other languages) can be 

generated. Strictly speaking, this definition incorporates international languages such as Esperanto, 

but we restrict ourselves here to any sequence of heavily inflected protosemantic codes produced by 

parsing. 

Masterman is also important because she suggested a major improvement to the Richens-Booth 

continuous form interlingua. In Masterman (1957), she simply took her copy of Roget's Thesaurus 

from the shelf, and used its headings as a ready-made semantic interlingua, complete with associated 

numeric codes. We have ourselves discussed this approach in our paper, "The magical name Miller, 

plus or minus the umlaut" (Smith, 1997b), where we gave some of the credit for the idea to the 19th 

century professor of linguistics, Max Müller ..... 

"[Müller] was one of the first to recognize that word meanings are constantly evolving, and spent a 

lifetime studying the etymologies of words in a variety of languages with a view to tracking down their 

derivations (Müller, 1887). Working in this way, he reduced all languages to much smaller pools of 

word roots and fundamental concepts. To give but one example, the Greek words for lift, compare, 





tribute, spread, delay, bury, madness, endure, recover, reproach, help, and excel (to name but a few) 

all derive in various ways from, 'to bear'. Müller's central argument goes as follows: 'Give us about 

800 roots, and we can explain the largest dictionary; give us about 121 concepts, and we can account 

for the 800 roots. Even these 121 concepts might be reduced to a much smaller number, if we cared 

to do so' (op. cit., p551.). But not all authorities agree on where to draw the line. Whereas Müller 

chose a pool of 121 'original concepts', Saban (1993) chooses 31 basic 'semantic fields', and in the 

original 1852 edition of his renowned thesaurus Peter Roget went for 1,000 'related ideas'. So why the 

disagreement? Well insofar as it was responsible for importing the concept of the bit from engineering 

into psychology, the answer lies in George Miller's paper [ie. the Miller (1956) "Magical Number 

Seven" paper - Ed.]. This is because the logarithmic nature of the bit renders 31, 121, and 1,000 not 

so different after all: to be precise, they might just represent three points on the powers of two 

dimension. That is to say, we need five bits of information to specify a single one of Saban's 31 

semantic fields, seven bits of information to specify a single one of Müller's 121 original concepts, and 

ten bits of information to specify a single one of Roget's 1000 related ideas [raising two to the powers 

five, seven, and ten gives 32, 128, and 1024 respectively - Ed.]. Could we, therefore, be looking at a 

semantic memory which somehow operates according to a binary chop principle?" (Smith, 1997b, 

pp204-205) 

NB (14th July 2003): Although ignorant of her work at the time, we owe it to Masterman to point out 

that she was there 40 years before we were. This from Masterman (1957, p41): "..... in any kind of 

writing which builds up into an argument, thesaurus-heads tend to be introduced in powers of two, 

each topic being introduced concurrently with that to which it primarily contrasts". It is simply a very 

efficient way to think about things - as Hamlet found out with all his to being and not to being. Nor, it 

turns out, was Müller really the first, either, for he was simply following suggestions from the 17th 

century "universal languages" of Cave Beck and Athanasius Kircher [more]. We might also add that 

Richens' 80 or so "naked ideas" and Parker-Rhodes' (1978) 150 or so "primitive items" are not that far 

from the line. 

So to put things back into perspective, what the early MT researchers had done was to re-open a very 

old (and more than normally wriggly) can of philosophical worms, and in retrospect it is not really 

surprising that Booth and Richens did not keep their MT lead (such as it was) for long. The ARC was 

little more than a hobby kit computer, and the big machines soon overtook it, and - the pessimists 

apart - there was still a common presumption that things would be better when newer, faster, 

machines with more powerful programming languages came along. Nevertheless, what the Birkbeck 

(Booth), MIT (Yngve, Bar-Hillel), Seattle (Reifler), and Cambridge (Richens) groups had been doing 

was laying the foundations for the modern science of "computational linguistics". 

4.2 Semantic Networks 

Sadly, MT's problems did not go away, even with interlinguas and inflection markers and more 

powerful computers. Irony, ellipsis, context, and idiom, still had to be overcome. Reifler himself gives 

the example of trying to translate "he is an ass" into Chinese, assuring us that you cannot simply 

substitute the Chinese word for ass because Chinese folklore does not regard the ass as inherently 

stupid. There are other traditionally difficult and highly illustrative problem phrases, perhaps the most 

famous of which is "out of sight, out of mind", which in the absence of some extremely nifty 

programming invites translation as "invisible lunatic" - perfectly logical in its own way, but also 

perfectly stupid. Another commonly cited howler comes from the English-to-Russian MT software 

which reputedly rendered "The spirit is willing, but the flesh is weak" as "The steak's off, but the 

vodka's OK". Warren Weaver himself summarised all the criticisms in a privately (but widely) 

circulated memorandum on the subject (Weaver, 1949), and it was this which drew broader academic 





attention to the underlying issues. Thus it was that linguists and philosophers such as Bar-Hillel grew 

deeply pessimistic about MT's long term prospects [wait and see what he says about John McCarthy 

in Section 4.7!]. You could not do MT, in Bar-Hillel's view, until you had acquired a far better 

understanding of linguistics, and those who already understood linguistics were already wagering that 

you would not be able to do it then either (and, as we shall be seeing in Part 5, nobody half a century 

later has come close to relieving them of their money). 

Yet the CLRU still had the fourth of its four main themes - lattice theory - in reserve. The main worker 

here was a colleague of Masterman, Arthur Frederick Parker-Rhodes, and his basic proposal was that 

the mathematics of networks (lattice theory arose a branch of Boolean algebra) was also the 

mathematics of language [example] ..... 

BIOGRAPHICAL ASIDE - ARTHUR FREDERICK PARKER-RHODES: text to follow 

Drawing on Parker-Rhodes' ideas, Masterman re-analysed the linear array of meanings laid out in 

Roget's Thesaurus as the nodes of a large knowledge network. 

Of course, the idea that the mind might organise its available knowledge as a vast interlocking 

network of concepts is not new. One of today's leading experts on the technical structuring of 

knowledge, ex-IBM man and knowledge consultant John F. Sowa, for example, dates the idea to the 

Greek philosopher Aristotle. Aristotle's early thoughts on the hierarchical nature of definition survived 

in the network diagram drawn up by Porphyry in the third century CE, a device now known as the 

"Tree of Porphyry" [picture]. The idea was then reborn in the "Associationist" tradition of Western 

philosophy (led by David Hartley in the mid-18th century), and was also used by Jung as the basis of 

his "association of ideas" projective test [the famous "tell me the first word that comes into your head" 

test]. We shall be returning to this issue in Part 5, but mention it here because Richens - geneticist, 

self-taught database designer, and now linguistic philosopher - has recently been identified as the 

man who coined the term "semantic net" [source], and semantic networks are a very important 

topic ..... 

Key Innovation - Semantic Networks: A semantic network is "a graphic notation for representing 

knowledge in patterns of interconnected nodes and arcs [..... and] what is common to all semantic 

networks is a declarative graphic representation that can be used either to represent knowledge or to 

support automated systems for reasoning about knowledge" Sowa (2003 online). As we shall be 

seeing in Part 6, semantic networks exist within the computer world in the form of the networkstructured 

(aka "codasyl") database.




The main psychological input to the semantic network debate has been from Anderson (1983) and his 

"propositional network", as reproduced at Figure 2(a). However, very similar diagrams are heavily 

used within the IT industry to formalise the layout of large computer databases, and a specimen of 

one of these is reproduced at Figure 2(b). Curiously enough, attempts to import database concepts 

into psychological explanation are few and far between. 

Figure 2 - Propositional Networks, (a) Biological and (b) Computer: In diagram (a) we 

see how a simple network diagram can be used to analyse something as philosophically 

complex as a unit of truth. As is common with this sort of diagram, the individual concepts are 

shown as concept nodes in the network, whilst the real knowledge exists in the form of 

propositional nodes (the oval ones). The propositional nodes are vital because they 

"encode" facts (ie. propositional truths) about the concepts they link. The oval symbol on this 

occasion serves to link the otherwise separate conceptual nodes and , 

and in so doing it identifies a number of essential linguistic properties as shown in italics on 

the line linkages. Thus is the subject of the proposition, is the location, 

and specifies the relation between the two. In diagram (b), we see similar principles at 

work in a computer data model. This particular modelling convention uses four types of 

symbol. The rectangles and diamonds denote different types of concept, or entity, nodes, the 

ovals denote the attributes, or properties, of those entities, and the lines denote the 

relationships between entities and other entities or between entities and attributes. Again, the 

essence of the relationships between entities is marked on the line linkages. Properly 

implemented by a Database Management System, every occurrence of every entity type, 

attribute, and relationship can be safely stored in rapid access computer filestore, and 

retrieved in short order. This is precisely the sort of technology which would have 

allowed Reifler [see Section 4.1] to squeeze his 15 drum dictionaries onto a single 

storage resource. 





For a rich selection of other diagrams and approaches, see Sowa (2003 online). In fact, Sowa (2003 

online) identifies no less than six subtypes of network, as follows ..... 

(1) Definitional Networks: These are networks which define a concept in terms of its similarity to 

other concepts. Sowa calls this a "subtype", or an "is-a" relation, and places its value in the fact that 

the properties of the supertype are automatically "inherited" by the subtype. [Our Example: 

is a .] 

(2) Assertional Networks: These are networks which assert propositional truths. [Our Example: 

or .] 

(3) Implicational Networks: These are networks which "use implication as the primary relation for 

connecting nodes". [Our Example: which implies ,..... 

AND SO IS LIKELY TO ROLL IF PUSHED>.] 

(4) Executable Networks: These are networks which have mechanisms for actively locating content 

according to a prescribed search mask. [Our Example: A network which could respond appropriately 

to an instruction in the form LIST ALL CONTENT ASSOCIATED WITH THE TARGET .] 

(5) Learning Networks: These are networks which can extend themselves, either by adding new 

nodes or new arcs between existing nodes, or by modifying the association strengths, or "weights", 





of arcs. [Our Example: A face recognition network which can learn to recognise new faces (new 

nodes), or attach new attributes to existing ones (new arcs).] 

(6) Hybrid Networks: These are networks which combine two or more of the preceding types. 

4.3 Mechanised Game Playing 

In 1769, the inventor-showman Wolfgang von Kempelen built a chess-playing automaton which he 

demonstrated at theatres and fairs where it proved capable of beating most contestants. Unfortunately, 

von Kempelen was pulling a fast one, and the functional CPU turned out to be the world's first 

minicomputer - a human dwarf secreted within the device [picture and fuller story]. The idea remained 

appealing, however, and one of the pastimes of the first computer programmers was to investigate 

whether computers could be programmed to play games such as draughts [US = checkers], noughts 

and crosses [US = tic-tac-toe], or chess. The pioneer thinker in this area seems to have been 

Germany's Konrad Zuse [reminder], inventor of Plankalkül, the world's first higher-level programming 

language. In the period 1942-1945, Zuse sketched out designs for a chess playing program for his Z4 

computer, but it never got written and the design was only published in 1972 [source]. The formal 

glory goes instead to another of Warren Weaver's protegés, Claude Shannon of the Bell Telephone 

Company. In a manuscript dated October 1948, Shannon analysed the problems which were likely to 

be encountered when getting a computer to play chess (subsequently published as Shannon, 

1950/1993). He saw this as one of many ways in which computers could move in the direction of 

processing "general principles, something of the nature of judgement, and considerable trial and error, 

rather than a strict, unalterable computing process" (Shannon, 1950/1993, p637). He saw "the chess 

machine" as an ideal problem with which to start the quest for what he called "mechanised thinking", 

and discussed methods of codifying and then evaluating proposed moves. Not surprisingly, 

Shannon's papers inspired some ground-breaking computer programming in the early 1950s. The 

following bullets come from a number of sources, including Copeland (2000 online) ..... 

The Bletchley Park veteran, Donald Davies, published an article on the mechanisation of board 

games (Davies, 1950), and coded a simple noughts-and-crosses program for the NPL's Pilot ACE. 

In May 1951, the aforementioned Christopher Strachey [see Section 2.3], wartime radar boffin 

turned schoolteacher, scrounged time as a technical hobbyist on the NPL's Pilot ACE, and wrote 

what has been acclaimed as the world's first AI program - a draughts program. Unfortunately, the 

code had a few bugs in it, and Strachey did not get it working tidily until the following summer on 

Manchester's Ferranti Mark 1 (Copeland 2000/2003 online). 

In November 1951, Manchester University's Dietrich Prinz used Turing's newly produced 

"Programmer's Handbook" to produce the first experimental chess program, also on the Ferranti 

Mark I (Copeland, 2000 online). 

IBM's Arthur Samuels heard of Strachey's program at a 1952 conference, and adapted it for the 

IBM 701. He then had to spend the next ten years improving it, eventually adding the rudimentary 

ability to learn from experience, whereupon the code turned rather churlishly on its creator and 

started to beat him (Samuels, 1959). 

IBM's Alex Bernstein wrote the first reasonably competent chess program on an IBM 704 in 1957. 





With even more improvements, Samuels' 1959 program beat a human draughts champion in 1962. 

The program is historically significant because it used "heuristics" rather than "algorithms" to 

evaluate and score possible moves. 

Key Innovation - Algorithms vs Heuristics: The word "algorithm" derives from the Arabic "al 

Khowarasmi", the popular name of the ninth century Arab mathematician Abu Jafar Mohammed Ben 

Musa, and refers to a sequence of formal actions by which a given problem can be systematically 

resolved. It is "a systematic list of instructions for accomplishing some task" (Wikipedia, 2003). Thus 

computer programs are algorithms. The word "heuristic" derives from the Greek root - "to find" (thus 

being related to "Eureka" = "found it!"), and, strictly speaking, refers to anything which promotes an 

act of discovery. However, where algorithms consist of specific actions, heuristics consist of ruleaction 

combinations, so with an heuristic you do not know in advance what you are going to do - you 

have to wait and see what circumstances trigger what rules. The beauty of the if-then approach is that 

it can save you a lot of time. When playing chess, for example, it is rarely a good idea to exchange a 

queen for a pawn, and so an entire branch of the exhaustive search tree can be discounted at a 

stroke. Insofar as the word is used in game theory, the point about heuristics is that they attempt rapid 

penetration of a problem rather than exhaustive analysis, by virtue of which they are often referred to 

as "rules of thumb". Ultimately, of course, both algorithms and heuristics are only as good as their 

designers. If either is not particularly powerful, then the quality of the penetration will be limited. 

4.4 Man-Machine Conversation 

The fourth line of enquiry was a more philosophical one, and looked at what needed to be done to 

turn a cleverly programmed calculator into something qualitatively more than a cleverly programmed 

calculator. What, for example, might a cash register have to do to be accepted as containing a mind; 

something more than just a thing which can be switched on and off on demand? What might your 

laptop have to do to be accepted as possessed of some kind of vital spark? This question was first put 

forward in a paper from Mr GPC himself, Alan Turing, who, when not codebreaking, was "really quite 

obsessed with knowing how the human brain worked and the possible correspondence with what he 

was doing on computers" (Newman, 1994/2003 online, p12). Taking time out from his work on the 

Manchester Mark 1, Turing wrote a paper entitled "Computing machinery and intelligence" in which he 

suggested that the question "can machines think?" was philosophically unsafe, due to problems 

agreeing the meaning of the word think (Turing, 1950/2003 online). 

Of course, Turing had long believed that all but the most obscure of problems could be solved by a 

sequence of simple actions, and already for a decade programmers had been proving him right. He 

now recommended that this sequence of actions be thought of as having an existence and meaning in 

itself: a program, once devised, was a solution in prospect, as it were, and simply "awaited" a 

machine to execute it. Turing then brought these two propositions together by arguing that the mind 

would not only prove one day to be "programmable", but that the eventual program would be 

"implementable" on a machine. And once you could do that, he said, you would have a machine 

which would be indistinguishable from a human; that is to say, a machine which could think. As to how 

you would test this indistinguishability, he proposed objectively establishing whether the machine, so 

programmed, could perform as successfully as a human in fooling an interrogator in an "imitation 

game", in which a man (A) and a woman (B) have to fool (C) as to which is the man and which is the 

woman. The knowledge pertaining to (A) and (B) is accumulated in the mind of (C) by asking 

questions, the only restriction being that the answers to those questions should be typewritten so as 

to prevent vocal clues being given. 





Turing's imitation game evolved somewhat over the years, and in its later form became popularly 

known as the "Turing Test". This runs as follows: if a human in room A were to communicate via 

keyboard and screen with an entity in room B which might be a human but which might also be a 

computer trying to appear human, then the definition of "humanness" would rest on whether the real 

human could tell the difference or not after five minutes of questioning. Serious academic attempts to 

"pass the Turing Test" began in the 1960s, and we shall be looking at some of these in Part 5. Reader 

(1969) even sketches out the processing modules which would be necessary to build such a machine 

[check it out], but the layout he proposes turns out to be yet another instance of the cognitive control 

hierarchy, indistinguishable in essence from Lichtheim's (1885) "House" diagram, and surpassed in 

supporting detail by Frank's (1963) "Organogramm". 

4.5 "Neurodal" Networks and Machine Learning 

The fifth line of enquiry was pitched more at the hardware side of things, and can be traced to a 

number of seminal papers from the 1940s, led by the American neuropsychologist Warren S. 

McCulloch (1898-1968). The first of these was McCulloch and Pitts (1943), an attempt at 

mathematically modelling the workings of biological neurons. The authors called their artificial neurons 

"neurodes", and each was a simple arrangement of electronic components designed to do two main 

things, namely (a) to output a signal similar to the bursts of action potentials output by biological 

neurons, and (b) to ensure that this output was modulatable - sensitive to what other neurodes in the 

vicinity were doing. In this way, quite simple combinations of neurodes were capable of performing the 

logical operations AND, OR, and NOT to much the same end effect as the electronic circuitry then 

being developed for use in computers. Pitts and McCulloch (1947) then went an important step further, 

by discussing what would happen if you took many such neurodes and wired them together. 

Specifically, they proposed that it would be possible to end up with some sort of artificial pattern 

recognition system. And McCulloch and Pfeiffer (1949) considered how binary principles might exist 

within biology. They portrayed the nervous system "as if it were a wiring diagram and the physiology 

of the neuron as if it were a component relay of a computing machine" (p369). Their aim was then to 

"set up working hypotheses as to the circuit action of the central nervous system as a guide to further 

investigation of the function of its parts, and as a scheme for understanding how we know, think and 

behave" [ibid.]. This is part of their observations ..... 

"Judging by the speed of response, neurons fall into the middle range of man-made relays. They are 

about a thousandth as fast as vacuum tubes, about as fast as thyrotrons, but faster than 

electromechanical and mechanical devices. Because they are much smaller than electronic valves, 

though the voltage gradients are about the same, they take lower voltages and less energy. A 

computer with as many vacuum tubes as a man has neurons in his head would need the Pentagon to 

house it, Niagara's power to run it, and Niagara's water to cool it. The largest existing calculating 

machine has more relays than an ant but fewer than a flatworm. Neurons, cheap and plentiful, are 

also multigridded, the largest having upon them thousands of terminations, so that they resemble 

transistors in which the configuration of electrodes determines the gating of signals." (McCulloch and 

Pfeiffer, 1949, p370) 

HISTORICAL ASIDE: In fact, the idea of nerve net computation is far older than the attempts to 

construct it. One of the first to suggest that learning was accompanied by the formation of new 

synaptic connections was the Aberdeen logician, Alexander Bain (1818-1903). Inspired by the work of 

Lionel S. Beale (1828-1906), pioneer in medical microscopy, and specifically by Beale (1864), Bain 

tried to find a likely neuroanatomical substrate for the sort of semantic networks popular with 

psychologists of the "Associationist" persuasion. The process relied on the "contiguity" - that is to say, 

closeness together in time or space - of the elements to be associated. "Contiguity," he wrote, "joins 





together things that occur together, or that are, by any circumstance, presented to the mind at the 

same time ....." (Bain, 1879, p127). He set out his technical proposals in his 1873 book "Mind and 

Body", from which the following clearly indicates his line of argument: "For every act of memory [.....] 

there is a specific grouping, or co-ordination, of sensations and movements, by virtue of specific 

growths in cell junctions" (Bain, 1873, p91; cited in Wilkes and Wade, 1997). Bain then analysed 

differently interconnected clusters of neurons using simple abstract circuit diagrams (reviewed by 

Wilkes and Wade (1997). The next major historical figure was Santiago Ramon y Cajal (1852-1934) 

(eg. Ramon y Cajal, 1911), whose general idea was that plasticity in neuron-to-neuron connections - 

what are now known as "synapses" - made it possible for neural pathways to connect themselves up 

on demand - that is to say, as learning took place. Pathways could thus appear where previously just 

disconnected neurons had existed. Moreover, the biological act of creating those pathways 

underpinned the psychological act of memorising the experience in question. Some years later, 

Rafael Lorente de No (1902-1990) extended the debate by microscopically analysing the layout of the 

synaptic "buttons" on neural cell bodies (Lorente de No, 1938). Working at the limits of magnification 

of the microscopes then available, he found many hundreds of synaptic buttons dotted about the 

neural membrane, thus reinforcing suspicions as to their role in neural circuitry. Subsequent studies 

have confirmed this view, and with today's very powerful microscopes veritable forests of synaptic 

buttons can be seen, and not just on the neural soma but out on the dendritic trees as well. Another of 

Lorente de No's contributions was to show how interneurons could be used to feed excitation back 

into a given neural circuit, thus keeping that circuit active long after the original source of excitation 

had been removed. This arrangement is commonly referred to as a reverberating circuit. However, 

the most influential exposition of neuronal net theory came from Donald O. Hebb (1904-1985). In his 

1949 book, "The Organisation of Behaviour", Hebb described the interlinking of neurons as creating 

what he called a cell assembly, which he described thus: "..... a diffuse structure comprising cells in 

the cortex and diencephalon (and also, perhaps, in the basal ganglia of the cerebrum), capable of 

acting briefly as a closed system." (Hebb, 1949, p. xix). Hebb's ideas of how cell assemblies form and 

function can be gathered from the following: "The general idea is an old one, that any two cells or 

systems of cells that are repeatedly active at the same time will tend to become 'associated', so that 

activity in one facilitates activity in the other" (Ibid, p70). The idea of cells repeatedly assisting each 

other's firing is particularly well brought out in what has since come to be known as "Hebb's Rule". 

The next step was to go ahead and wire a few neurodes together, and in 1951 Marvin Minsky did just 

that (Minsky, 1994). As part of his postgraduate researches in the mathematics department at 

Princeton, and in conjunction with Dean Edmonds, he built SNARC (= "Stochastic Neural-Analog 

Reinforcement Computer"), the first machine to display learning behaviour, thanks to an inbuilt 

reinforcement-sensitive 40-neuron "neural net". This was followed a year later by William Ross 

Ashby (1903 - 1972)'s "Design for a Brain" (Ashby, 1952). Ashby was the cyberneticist who had 

popularised the concept of "homeostasis" in biological systems. He therefore took a more 

macroscopic view of neural architecture than had McCulloch or Minsky, that is to say, he was more 

concerned with what the nervous system was trying to achieve as an organic whole with interrelating 

modules, rather than with what individual neurons were up to. His work with biological homeostasis 

had convinced him that many biological control phenomena were simple negative feedback systems, 

save that they had biological sensors and comparators, and during the 1940s he had experimented 

with a simple machine called "the homeostat", which was sensitive to environmental events and 

could initiate corrective behaviurs to neutralise any "perturbation" in their stable settings. Angyan 

(1959) reports on a more advanced machine called Machina Reproducatrix, fitted with enough 

sensors and motors to give it a light-seeking "tropism", however we need to talk about this in Part 7, 

and so will leave the details until then. 





ASIDE: The term "tropism"was coined by Loeb (1888, 1890) to describe the wholly involuntary 

behaviour of organisms lacking a nervous system. Just as plants can turn towards the sun using nonnervous 

mechanisms, so, too, is much simple animal behaviour unwilled. To be classified as a 

tropism, the relationship between the stimulus and the response must be rigid and resulting directly 

from the action of some external energy source. Tropisms can be subcategorised by energy type and 

direction of response as follows: Geotropisms: positive - turn towards the pull of gravity; negative - 

turn away from the pull of gravity, Heliotropisms (or phototropisms): positive: turn towards the light; 

negative - turn away from the light, Thermotropisms: positive: turn towards heat; negative - turn away 

from heat, and Rheotropisms: positive: turn upstream (in air or water); negative - turn downstream. In 

animals with nervous systems, this type of behaviour is provided by reflexes. For a longer 

introduction to the various types of innate and learned animal behaviour, see Section 1 of our e-paper 

"Communication and the Naked Ape". 

In fact, 1952 was a busy year, because it also saw Claude Shannon following up his chess machine 

with the blueprints for a maze-solving mechanical mouse (Shannon, 1952/1993), and Anthony G. 

Oettinger writing a program called "Shopper", the first program (as opposed to learning hardware) 

capable of learning from experience (Oettinger, 1952). Copeland (2000/2003 online) describes 

Shopper as operating in a virtual world containing a mall of eight shops stocking a number of items. 

Shopper would be sent off to purchase a particular item, and would have to visit shops at random until 

successful. The learning lay in the fact that Shopper would memorise some of the items stocked in the 

unsuccessful visits. Subsequent shopping expeditions, either (a) for repeat purchases of the first item, 

or (b) for first time purchases of one of the memorised items, would be right first time, thus showing 

the value of short term memory resources in supporting adaptive behaviour. 

We must also mention Albert M. Uttley, whom we first met in Section 2.2 as the TRE boffin who 

designed TREAC, the first British parallel processing computer. Over the years, Uttley gradually 

extended his interests to include biological as well as workbench electronics. Like McCulloch, he was 

particularly fascinated by the logic by which neurons were interconnected, and was one of the first to 

describe the sort of statistical connection rules which might control the biological learning process. In 

Uttley (1955), he derived mathematical formulae to describe such things as dendrite distribution and 

axonal connections. 

However, the most famous of the early machines was built by Frank Rosenblatt in the mid-1950s, and 

called a "perceptron". The essence of Rosenblatt's design was that the neurodes were arranged into 

two banks, or "layers". One of these was connected to an artificial eye and called an input layer, and 

the other was connected to the chosen output mechanism (usually an array of flashing lights) and 

called an output layer. Each point in the input layer was wired to each point in the output layer, and 

the effective strength of these connections was specifically designed to be varied. Learning was then 

a process of changing the strength of the connections - a process known as weighting. As we shall 

be seeing in Part 5, McCulloch's neurodes and Rosenblatt's perceptron formed the basis for one of 

modern science's most active and exciting research areas, namely "Connectionism". 

The point about perceptrons is that the weighting process delivered learning by experience. There 

was no pre-written program telling the hardware what to do - rather the machine worked it all out for 

itself. Perceptrons took the academic world by storm, therefore, especially where there were problems 

which were proving beyond the programmers in the first place - such as most of higher cognition. 

Thus ..... 





"It is not easy to say precisely what is meant by learning or what corresponds to it in a machine. The 

machine is able to learn up to a point, but once that point has been passed it is helpless. Here it 

differs from a human being, who is able to learn and to go on learning. [//] A program which would 

enable a machine not only to learn but also to go on learning, and to adapt itself to each new situation 

as it arose, I will call a 'generalised' learning program. If such a program could be constructed it would 

presumably consist of a relatively small initial nucleus of orders, and would adapt and extend itself as 

circumstances required, replacing its subroutines and switching sequences by others of a more 

general kind, and creating new subroutines to perform fresh functions. There does not appear to be 

any reason for believing that the construction of such a program is inherently impossible. Although 

limitations of speed and storage capacity would undoubtedly soon make themselves felt, it is not 

these so much as shortage of ideas which is at present holding up progress." (Wilkes, 1956, 

pp291-293; emphasis added) 

4.6 Robotics 

The defining essence of a robot is that it carries out work on behalf of its master. Strictly speaking, 

therefore, a robot needs bear no physical resemblance to any biological form (although, for reasons 

which are still being looked into, we seem to prefer that they do). As such, the broad concept can be 

traced back several thousand years [see our e-resource on the history of automata]. Even in 1950, 

the name "robot" was already at least 30 years old, being usually credited to Karel Capek's 1921 play 

"Rossum's Universal Robots", and Isaac Asimov's "Laws of Robotics" were 10 years old. As for the 

technology itself, it was at least 40 years old, and had been forged, as always, on a war anvil ..... 

HISTORICAL ASIDE - MILITARY ROBOTICS: The military have always proved generous sponsors 

for companies specialising in technological innovation, and we have already described elsewhere 

[reminder] how the Sperry Gyroscope Company grew into a major international corporation on the 

back of mechanical and electromechanical naval control systems. Sperry were also quick to see the 

same opportunity for fully automated aerial weapon systems, and as early as 1913 were using 

gyroscopic stabilisers as part of a radio-controlled aircraft (Pearson, 2003 online). The demands of the 

First World War extended the science of military robotics into the control of aerial torpedoes and the 

design of better bombsights and perhaps the best known products of this early research were the 

World War Two German V-1 and V-2 pilotless rocket systems, which both had autopilots and onboard 

guidance computers capable of steering them several hundred miles. Much less spectacular, but 

deadly nonetheless, were the Ruhrstahl SD1400 "Fritz X" and the Henschel Hs293A "stand-off" 

bombs [picture; pictures and discussion]. These were "Lenk-", that is to say guided, "bomben", and 

were both small winged glider bombs designed for anti-shipping use. The SD1400 was heavy and 

free-falling, with an armour-piercing capability, whilst the Hs293 was smaller and rocket-assisted, but 

lacked the armour-piercing capability. They were released from their mother aircraft while still a 

number of miles from the target, and steered on their short one-way flight by (initially) radio signals 

generated by a small joystick [picture]. The Lenkbomben were developed in the period 1940-1943, 

and when ready for field deployment were issued to specially equipped Luftwaffe squadrons 

codenamed KG40 and KG100. History's first successful guided missile attack on a surface ship then 

took place on 27th August 1943 in the Bay of Biscay, when the corvette HMS Egret was sunk and the 

Canadian destroyer Athabascan damaged by Hs293s launched from KG100 aircraft. The following 

month, the cruisers HMS Uganda and USS Savannah, together with the battleship HMS Warspite, 

were seriously damaged by Fritz Xs while supporting the Salerno landings, and the Italian battleship 

Roma was sunk by one or two hits [accounts differ] from Fritz Xs while attempting to defect to the 

Allies under the terms of the Italian surrender. The battleship Italia was also hit on this occasion, and 

her escort, the battleship HMS Valiant, damaged by a near miss, but both managed to make their way 

to Malta [source]. In November 1943, the British troopship Rohna was also sunk en route from Oran 





to Bombay carrying American troops, and this incident, in terms of lives lost (1138 dead), was actually 

a worse disaster than the attack on Pearl Harbour (Cassanello, 2003 online) [fuller story; in 

memoriam]. Still in the Mediterranean, the cruiser HMS Spartan was then sunk off the Anzio 

beachhead in January 1944 [fuller account]. The Allies responded very quickly to this new age threat, 

analysing the German radio control frequencies, and adding radio countermeasure systems (="RCM", 

or "jamming" equipment) to their front-line naval assets as fast as the equipment could be built and 

installed. This upgrade extended to a number of landing ships being fitted out as Fighter Direction 

Tenders (FDTs) in readiness for the 1944 invasion. These vessels were selected because they would 

be stationed off the landing beaches in a command and coordination role alongside existing 

headquarters ships such as HMS Largs, Hilary, and Bulolo. As a result, when the invasion went 

ahead in June 1944 the Allied fleet emerged relatively unscathed. For example, we find the following 

entry in the log of the battleship USS Texas: "the day [7th June] started with a detection of several 

anti-ship missile radio signals and subsequent jamming" [source]. KG100 was active for a few days off 

the Normandy beaches, and scored at least one sinking, that of HMS Lawford on 8th June [divers 

examined the wreck in 2002, and the nature of the damage confirms that a glider bomb was the most 

likely culprit]. Off Arromanches, they also hit, but did not sink, HMS Bulolo [picture], the Force G (Gold 

Beach) headquarters ship, striking her - fortunately for the ship as a whole, if not those actually up 

there - high on the superstructure [the specialist German bomb-aimers were trained to aim at their 

target's waterline for maximum effect, but even under ideal conditions were lucky to hit within a five 

metre radius]. The Germans were apparently slow to respond to Allied RCM with "countercountermeasures", 

but eventually replaced the radio controlled Hs293A with the wire-guided, and 

therefore RCM-immune, Hs293B. However, as the war moved progressively inland the opportunity to 

field this improved system was lost, and the specialist squadrons were disbanded. In all, 319 Fritz X 

and Hs293 missiles are reported to have been launched in action, of which roughly 100 scored hits. 

40 warships and 30 merchant ships were damaged or sunk [source]. In addition to the ships named 

above, German war historians also claim the destroyers HMS Jervis, Inglefield, Boadicea, and 

Intrepid as sunk, and the cruiser USS Philadelphia damaged [confirmation]. In addition, one of the 

aforementioned FDTs, FDT 216, is on official record as having been sunk by an air-launched 

"torpedo" on 7th July 1944, but it is unclear from the sources available to us whether this was of the 

guided or free-running type. The next major advance with tactical rocketry was the "homing" missile. 

These were developed typically for use against either aircraft or submarines, and the functional 

principle is that the missile "locks on" to an external energy source (typically the engine exhaust heat 

of an aircraft or the propeller noise of a submarine) and then twists and turns as much as is necessary 

to keep that source in its sights (allowing for deflection as necessary). This type of system reached a 

state of some sophistication in air-to-air missiles such as Sidewinder. Laser guided bombs were 

developed during the 1980s and saw action during the 1991 Iraq War. They have since been partly 

replaced by JDAM smart bombs [News24 picture], where the projectile homes on coordinates 

programmed into a highly flexible tactical command system, and conveyed to the weapon after its 

release by signals from a satellite. JDAMs are a few metres less accurate than laser-guided munitions, 

but are cheaper, can be used in larger numbers at a time, are "fire and forget", and are not affected 

by cloud, darkness, or smoke. 

So we now have something of a pattern emerging. With conventional munitions, the projectiles are 

totally "dumb" - mere lumps of iron, devoid of any form of intelligence; no more robots than spears or 

musket balls are robots. With the operator-guided weapons, the projectiles are responsive, but still 

dumb - they make no decisions of their own, but instead receive input (from the remote joystick) and 

generate output (to their steering mechanism). And with the early pilotless rocket systems, all the 

control systems were pre-set before launch, and the missile followed the programmed trajectory as 

closely as it was physically able. This mixture of technologies means that in the typical air-ground 





combat engagement of modern warfare we often pitch significantly different control systems against 

each other. We might, for example, have a tactical dual between a ground unit armed with a fire and 

forget shoulder-launched surface-to-air missile such as a Stinger, and a helicopter armed with a laserspotted 

air-to-ground round such as Hellfire [pictures and details], or between a city's SAM batteries 

(radar-guided, passive or active), and a B-2 loaded with JDAMs. The common denominator, of course, 

is that all forms are ultimately placed on target by a human, even if the act of aiming took place at a 

keyboard many thousands of miles away and many weeks beforehand. The intelligence (and we use 

the word cautiously) is in the mind of the operator whose eye is on the target (literally or figuratively) 

and whose hand is on the joystick. So the machines are not really intelligent at all. Even the JDAM 

has no "flexible control over the sequence of its operations" (Berkeley, 1949, p5), nor is it likely to 

acquire any for a good few years yet. In fact, Carnegie Mellon University's Hans Moravec [more on 

whom in Part 5] doubts that such "hazardous duty" systems should be called robots at all - he 

prefers the title "autonomous machines", because "they have the bodies of robots, but not the brains". 

ASIDE: We use the word "intelligence" cautiously, because it is one of those words which can mean 

whatever the speaker at the time wants it to mean. It can mean advanced philosophy to some, 

contemplative planning to others, or just the ability to hold a target in the crosshairs, and it is precisely 

this vagueness which has kept the Turing Test [see Section 4.4] so relevant all these years. The focus 

of our attention must therefore turn away from robotic mechanisms and design architectures, and look 

instead directly at the intelligence we are trying to inject into our robotic brain ..... 

4.7 Machine Problem Solving 

We turn, therefore, to the highest of all forms of guidance, namely reasoned action, and the nearest AI 

got to this in the 1950s was in its experiments with machine problem solving. The most successful of 

these was the collaboration between the Rand Corporation's Allen Newell and J. Clifford Shaw, and 

Carnegie Mellon University's Herbert A. Simon (1916-2001) to investigate how machines might 

profitably mimic (and potentially help explain) human mathematical problem solving. One of their 

programs is still regarded as defining the science ..... 

The "Logic Theorist": This 1956 program was designed to test the truth of specific mathematical 

theorems. It did this by allowing the programmer to input five basic propositions (called "axioms"), 

against which were applied a number of "rules of inference". This enabled further logical 

propositions to be derived, by a process based upon the human process of formal mathematical 

argument, and as each derived sentence is generated it can be checked to see if it matches the 

theorem under test. If it does, then the audit trail of successive inferences by which it was derived 

automatically constitutes the mathematical proof required. If it does not, then the program advances to 

the next permutation. Unfortunately, the problem with this approach is basically one of time, because 

ideally you would have to explore every combination of axiom and rule through every possible 

iteration (a brute force computational approach sometimes known as the "British Museum algorithm") 

[formal definition]. Remembering the distinction we raised in Section 4.3, this is therefore an excellent 

example of problem solving by algorithm rather than by heuristic. 

Logic Theorist was the central exhibit in 1956 at a conference on AI organised at Dartmouth College 

by John McCarthy (1927-), one of their mathematics lecturers ..... 

BIOGRAPHICAL ASIDE - JOHN McCARTHY: McCarthy had been following developments in 

machine cognition very closely, and had already coined the general descriptor "artificial intelligence" 

in 1955. He would go on in 1958 to develop the LISP programming language, and in 1959 wrote an 

influential paper entitled "Programs with Common Sense" in which he defined machine common 





sense as follows: "..... a program has common sense if it automatically deduces for itself a sufficiently 

wide class of immediate consequences of anything it is told and what it already knows." (McCarthy, 

1959/2003 online). As to how this might be achieved, reference should be made to the five system 

features proposed in the original paper, if interested. However, the fifth of these features in particular 

has turned out to be remarkably prescient ..... 

"5. The system must be able to create subroutines which can be included in procedures as units. The 

learning of subroutines is complicated by the fact that the effect of a subroutine is not usually good or 

bad in itself. Therefore, the mechanism that selects subroutines should have concepts of interesting 

or powerful subroutine whose application may be good under suitable conditions." (Ibid., p3.) 

McCarthy's 1959 paper is also noteworthy as an early example of the ill feeling and interprofessional 

disdain which can sometimes be seen between linguistics professors and the engineers who gravitate 

so frequently into AI. "Dr McCarthy's paper," wrote Bar-Hillel in the peer review section of the cited 

paper, "belongs in the Journal of Half-Baked Ideas [and] before he goes on to bake his ideas fully, it 

might be well to give him some advice ...." (Ibid., p11). Be that as it may, McCarthy had pointed 

unerringly at the central problem of any hierarchical control system, namely where to place (and how 

to build) the bit that makes the all-important judgements of interesting, powerful, etc. McCarthy is 

currently professor of computer science at Stanford University, and is well on the way to making his 

lifetime's work available on the Internet [index]. 

Another program, the "Geometry Theorem Prover" was reportedly inspired by a tentative program 

structure drawn up in 1956 by MIT's Marvin Minsky. This was a sequence of instructions capable of 

proving a particular geometrical problem. Minsky passed his notes to a young IBM researcher named 

Herbert Gelernter, who then implemented it on an IBM 704. The resulting software was capable of 

analysing a geometrical diagram for its constituent propositions, and of then attempting to derive 

further proofs in much the same way as Newell, Shaw, and Simons' Logic Theorist. 

Newell, Shaw, and Simon struck back in 1957 with the "General Problem Solver", a program 

expressly designed to simulate the processes of human problem solving. Here is Copeland's 

(2002/2003 online) summary ..... 

"..... work continued on the project for about a decade. General Problem Solver could solve an 

impressive variety of puzzles, for example the 'missionaries and cannivals' problem: How are a party 

of three missionaries and three cannibals to cross a river in a small boat that will take no more than 

two at a time, without the missionaries on either bank becoming outnumbered by cannibals? GPS 

would search for a solution in a trial-and-error fashion, under the guidance of heuristics supplied by 

the programmers. One criticism of GPS, and other programs that lack learning, is that the program's 

'intelligence' is entirely second-hand ....." 

The period under consideration ended with a paper by Newell, Shaw, and Simon (1958) on what they 

called "the problem of complexity". In it, they surveyed the attempts to date (including their own) and 

the heuristics used, and concluded that the complexity of heuristic programs was beyond the power of 

the programming languages then available, and appealed for more powerful languages. In Part 5, we 

shall be looking at what came along. 

4.8 Artificial Consciousness 

Finally, there has been a line of enquiry which has gone one important step past machine intelligence, 

looking for the secret of biological consciousness itself. Unfortunately, this remains an area where 





there is no hard data, little simulation, and a lot of speculation. As with intelligence, we simply do not 

know what consciousness is in philosophical terms, and so we need to be ready to come across it by 

accident in any of the various sub-areas of AI. It might be in the interlinguas of the verbal mind 

(Section 4.1), or in the data networks of the knowing mind (Section 4.2), or in the game playing 

heuristics of the game-playing mind (Section 4.3), or in the ability to pass the Turing Test (Section 4.4), 

or in some lucky artifact of the neural network (Section 4.5), or in the onboard intelligence of a third 

generation robot (Section 4.6), or even in the reflection which characterises good problem solving 

(Section 4.7). In short, we do not know what we are looking for, and that always makes life difficult for 

programmers [time, in fact, to call in the systems analysts ;-)]. We therefore close with quotable 

quotes on this very point by two of generation zero's greatest ..... 

"We know the basic active organs of the nervous system (the nerve cells). There is every reason to 

believe that a very large-capacity memory is associated with this system. We do most emphatically 

not know what type of physical entities are the basic components of the memory in question." (von 

Neumann, 1958, p68; emphasis original) 

"There is no difficulty in programming a universal machine to perform any set of operations when 

once the rules for performing them have been stated explicitly; this is true however complex the 

rules may be and however many alternative procedures of a conditional type are specified" (Wilkes, 

1956, p291; emphasis added.). 

5 - Still to Come 

That concludes our review of the history of first generation computing technology during the period 

1951 to 1958. In Part 5, we bring the review up to the present day, and identify several more key 

technical innovations, not least Database Management Systems, in Part 6 we look at computer 

memory in greater detail, especially as used in the COBOL programming language, the IDMS DBMS, 

and the TPMS TP monitor, and in Part 7 we undertake a comparative review of how well the full 

richness of computer memory subtypes had been incorporated into psychological theory. 

Part 5 - A Brief History of Computing Technology, 1959 to Date 

1 - Mainframe Computing 1959-1970 - Second and Third Generation Technology 

So to restate Part 4 succinctly, the average mainframe in 1958 was different in several technical 

respects to the machine which had existed in 1950, and was being used in exciting new ways both 

commercially and academically. Ferrite core memory had become the de facto standard for Main 

Memory construction, and machines now came complete with an operating system and an assembly 

language. However, two innovations in particular were already making such an impact on the industry 

that they are nowadays seen as the defining characteristics of an entirely new breed of system, 

namely the "second generation" computers (1959-1964). The first of these class characteristics, a 

technological advance, was that electronic circuitry could now be transistorised, and therefore made 

far smaller than in its first generation predecessors; and the second, a design advance, was that 

second generation computers used microcode. These machines were then followed by the even more 

advanced "third generation" computers (1965-1970), where the class characteristics were (a) the 

replacement of the chassis-mounted transistor with the integrated circuit, in which all functional 

components except the ferrite core Main Memory were miniaturised onto a silicon wafer, known as a 

"silicon chip", (b) the fact that programming was now increasingly done in compiled high-level 

languages such as COBOL, and (c) the provision of a virtual memory operating system. In this section, 





we review the impact of microcode, together with a dozen or so other noteworthy developments from 

the period 1959 to 1970. 

1.1 The Impact of Microcode 

Microprogramming is "a systematic technique for implementing the control unit of a computer. It is a 

form of stored-program logic that substitutes for sequential-logic control circuitry" (Smotherman, 

1999/2003 online). To understand what this means, we have to remember the sequence of events in 

the idealised Eckert von-Neumann machine's basic processing cycle, namely that individually simple 

instructions were interpreted by the Control Unit, which then passed an appropriate signal pattern to 

the logic gates of the Arithmetic/Logic Unit [reminder] (either bit-by-bit down a single wire if a serial 

design, or simultaneously down a number of wires if parallel). Unfortunately, the more you wanted the 

ALU to do at a time in the interests of processing speed, the more complicated the logic circuitry had 

to be, and the more complicated the circuitry, the more it would cost, the longer it would take to 

develop, and the more often things would go wrong. The resulting pressure to avoid complex 

instructions left programmers struggling to reduce complicated mathematical procedures to 

sequences of overly simple steps, and led, in turn, to very long programs. 

The win-win solution, on the other hand, was to find a way of providing a high functionality instruction 

set without paying the price in CPU complexity, and this is what EDSAC's Maurice Wilkes achieved in 

1951. What Wilkes proposed was that the Control Unit should abandon the one-to-one relationship 

between the program instruction coming in and the ALU instruction going out. Instead, a repertoire of 

more complex program instructions was provided, each of which, when detected by the Control Unit, 

was simply replaced on a many-for-one basis by a logically equivalent series of simpler instructions. 

The user-visible instructions were called "macro-instructions", and the machine-visible ones were 

called "micro-instructions" or "microcode". It thus became the microcode which controlled the 

action of the ALU, and not some momentary input pattern derived on a one-for-one basis from the 

program instruction. Wilkes continued to perfect this approach during the 1951 to 1958 development 

of his EDSAC II, and then IBM were among the first to buy in to the concept (and a fortune they were 

to make out of it), fielding it in their 1964 System/360 [see Section 1.6]. 

1.2 The Manchester University Atlas 

While its London factory was winning its spurs with the Pegasus [Part 4 (Section 2.3)], Ferranti's 

Manchester works continued its collaboration with Manchester University and started work in 1956 on 

a transistorised computer. This was to be fitted with core memory, and was given the name MUSE 

because it aimed to hit the magic one million instructions per second (mips) [MUSE was short for 

"microsecond engine", the Greek letter "mu" (Cyrillic ) being the standard technical abbreviation for 

"millionth"]. In fact, it took a full six years for the product - soon rebadged "Atlas" - to reach the 

showroom, largely thanks to the sheer intricacy of the engineering required. One major problem was 

that no one program would be able to utilise such a fast processor, because at 1 mips, all programs 

were going to be seriously peripheral-bound. It therefore made sense to allow several programs 

simultaneous access to the machine, with each program vacating the CPU during its slower inputoutput 

operations. This arrangement is known as "multiprogramming" ..... 

Key Concept - Multiprogramming: "Multiprogramming involves the simultaneous or parallel 

execution of two or more programs by an operating system on a single machine" [source]. In Atlas's 

case, up to 16 programs - all batch - could be managed concurrently, and it was left to the job 

execution logic [more on which below] to sort out their relative priority. 





Unfortunately, no operating software yet existed capable of supporting the sort of job execution 

scheduling which multiprogramming called for; and so this, too, had to be written. In the resulting 

three-pronged development, David B.G. Edwards managed the hardware teams, R. A. Brooker took 

on compiler development, and David J. Howarth saw to the operating system [citation]. Their work is 

historically noteworthy on two major counts. The first is for including the concept of "system 

supervisor" in the package of functionality provided by a good operating system [further details] ..... 

Key Concept - The System Supervisor, "Jobs", and Job Execution Scheduling: A "System 

Supervisor" is the top level control logic in a hierarchically organised computer operating system. It is 

the "process control module" at the "top" of a pyramid of lesser modular processes. In Atlas's case, 

the idea was that each program's momentary demands would be matched as far as possible against 

the machine's momentary resources; and, where this meant queueing, that would be handled 

automatically by a "contention scheduling" routine. Another important aspect of the System 

Supervisor concept was that it required the programmer to consider not just the logic of his code, but 

the broader package of things needing to be done before that code could be executed. This gave rise 

to the concept of "job", a request to run a program (or, indeed, a series of programs) against a 

precisely identified set of resources such as data, peripheral devices, and CPU time. These resources 

were identified as part of a "job pack", originally a set of punched cards to be read by the Supervisor 

software, but soon yet another computer file. The idea of job packs soon caught on across the 

industry. IBM job packs, for example, were written in a set of conventions known as JCL (= "Job 

Control Language"). The ICL VME operating system went a stage further in the 1980s, allowing job 

packs to be compiled as object code, whereupon they could be treated just like the instructions 

directly provided by the OS. This control language was known as SCL (= "System Control 

Language"). [In 1988, the author wrote the operational SCL routines to control the execution of seven 

linked COBOL programs making up a major stores accounting suite, complete with restart points, 

archive taking, archive pruning, on-the-fly integrity checking, and full audit trail; and the whole thing 

performed as sweet as a nut.] Ed Thelen notes that Howarth's Supervisor is "considered by many to 

be the first recognisable modern operating system" (Thelen, 2003 online). 

Atlas's second claim to fame - and it easily ranks in importance with the invention of ferrite core 

memory - is that the System Supervisor could be used to apportion the available Main Memory 

amongst its 16 simultaneous programs in such a way that they all got the whole cake! The secret of 

this digital conjuring trick lay in notionally dividing Main Memory up into "pages", each the size of a 

convenient block of disk storage, and by keeping count of how often each page was being used. 

Infrequently used pages could then be copied off to disc without the program being aware of the loss, 

so, when running several programs, each would think it had the full range of memory available to it 

and could be programmed accordingly. The cost to the system lay in all the counting and the copying, 

but the saving lay in the ability to pass the space thereby released over to other users. The name 

given to memory which looks like Main Memory but is really on disk was "virtual memory", and the 

name given to the all-important process of copying blocks of it backwards and forwards was 

"paging" ..... 

Key Concept - "Virtual Memory" (VM), "Paging", and "Thrashing": Given that the typical Eckertvon 

Neumann machine had only a small amount of Main Memory, but a much larger amount of 

backing store, and given also that programs typically contain large segments of conditionally used 

code [see the indent on Conditional Control in Part 3 (Section 4)], it occurred to the Atlas design team 

to push low-usage segments of a loaded program out of the one form of memory and into the other. 

Because these segments were known as "pages", the process of "rolling code in and out" of Main 

Memory as demand dictated became known as "paging" (sometimes "demand paging"). Additional 





registers were added to the CPU to keep note of where each program had got to, and "page tables" 

were stored in the operating system area of Main Memory to accumulate the necessary usage 

statistics. "Thrashing" is what happens in a VM system when paging gets overloaded or goes out of 

tune. The point is that rolling programs in and out of Main Memory takes time, so, if you do too much 

of it, the ability to do anything constructive in the in-between-times reduces accordingly. 

The Atlas was officially inaugurated on 7th December 1962, but only three full, and two scaled-down, 

machines were sold, due partly to Ferranti selling off its computer division to ICT in 1963 [see Section 

1.8]. The technology did not go to waste, however, in that it helped shape ICT's successful 1900series. 

A final Manchester University project - the MU5 - ran from 1966 to 1974 as a testbed for ICL's 

VME 2900 mainframe range [which we shall be dealing with in Section 3.3. 

1.3 The IBM Second Generation Machines 

As we saw in Part 4 (Section 1.2), IBM's strategy during the early 1950s had been to apportion its 

efforts between developing simple tabulator-multipliers for its commercial customer base and 

producing large defence computers for the US military. By mid-decade, however, it had started to 

bridge the gap with mid-range products. In 1955 the IBM 608 transistorised calculator [picture] was 

introduced, in 1957 the 7070, and in 1959 the 1401, "the first computer system to reach 10,000 units 

in sales" (author). The IBM 1401 has recently been acclaimed "the Model T of the computer business" 

(Nicholls, 2003 online), because it was the first mass-produced, digital, all-transistorised, business 

computer. It was announced in October 1959, came complete with an Assembler language called 

Autocoder, and could be installed on lease from as little as $2500 per month [author]. It is also 

historically significant within the UK, because it grabbed so much of the market that it forced a series 

of mergers and rationalisations on the British computer industry [see Section 1.8]. For some 1401 

user reminiscences, see the Tom Van Vleck website, and for the basic system details, see the Frank 

da Cruz website. 

The IBM "Stretch" was another cutting edge design concept from the late 1950s, and many of its 

concepts were (and some still are) ahead of their time. The project was fronted by Stephen W. 

Dunwell, ex-codebreaker, design began in 1955, and the product as first delivered in 1960 contained 

169,000 transistors, and offered 96,000 64-bit words of core memory. The development team 

included Gerrit A. Blaauw, Frederick P. Brooks, John Cocke, Erich Bloch, Werner Buchholz, Edgar 

Codd [more on whom in Section 3.1], Robert Bemer ("father of ASCII"), and Harwood Kolsky, and of 

particular importance was an advanced form of pipelining ..... 

Key Concept - "Pipelining" (Continuation): The basic concept of "pipelining" was introduced in Part 

4 (Section 2.3), as a technique "whereby multiple instructions are overlapped in execution" (Patterson 

and Hennessy, 1996, p125). The IBM Stretch designers set new horizons for this concept by 

arranging for the FETCH part of the basic FETCH-and-EXECUTE cycle [reminder] to be up to four 

instructions ahead of the EXECUTEs (Smotherman, 2002 online). They did this by setting the 

instruction length at either 32 or 64 bits depending on the number of operands required, and then 

building into the Control Unit two 64-bit "instruction buffers". Instructions were fetched 64 bits at a time 

from Main Memory, and when one buffer had been processed the next was processed while the first 

was refreshed. In this way, the decoding of instruction could be taking place during the 

execution of instruction , with instructions and already on their way across. There 

was also allowance for a process known as "Memory Operand Prefetch", a technique which 

Smotherman describes as "a novel form of buffering called a 'lookahead' unit". 





Stretch also introduced the term and concept of the "byte" into the computing lexicon. The idea was 

Bob Bemer's (although the word itself seems to have been Buchholz's), and it helped you distinguish 

between bits, and the various clever things you could do with bits if you set your mind to it. To see 

how bytes work, we need to look at the three already established uses for the contents of a computer 

word ..... 

(1) Words as Instructions: Here the word is made over to one or more machine instructions, made 

up, as previously explained [reminder] from op code and operand elements. The byte concept cannot 

be used here, because the number of bits in each of these elements will have been specified at the 

circuit design stage. 

(2) Words as Binary Data: Here, for speed of calculation, the word is made over to a binary number 

in either fixed point pure binary format (eg. [leading zeroes]10111, for decimal 23) or floating point 

format as previously described [see Part 4 (Section 1.3)]. The byte concept cannot be used here 

either, because, again, the numerical field lengths will have been specified at the circuit design stage. 

(3) Words as Alphanumeric Data: Here, formatted ultimately for human consumption, the word is 

treated as a sequence of "bytes", each corresponding to a keyboard character of some sort. With a 

64-bit word and a 7-bit byte, say, each word can contain nine bytes [eg. the word "CALCULATE", the 

decimalised number "000000023", or the mixed string "____£0.35" (note the four leading spaces, 

which, whilst spaces on screen or print-out, are nevertheless 7-bit bytes in the system)]. With a 64-bit 

word and an 8-bit byte, the number of bytes per word reduces to eight, but the size of the character 

set doubles from 128 items to 256 items. 

Stretch was put to market as the IBM 7030 in 1961, and held the "World's fastest computer" title until 

1964. It suffered its fair share of teething troubles due to the sheer number of innovations built into it, 

but it provided IBM with a body of design experience second to none, which they were about to put to 

spectacular commercial effect in the System/360 [see Section 1.6]. Metz (2001/2003 online) therefore 

bestows upon the 7030 the accolade of the "Most Successful Failure in History". 

1.4 The "Stack" Processing Machines 

The 1950s had also seen the invention and increasing popularity of a clever alternative to the one- 

and three-operand instruction sets which had typified the generation zero machines [reminder]. This 

involved feeding only one element at a time to the Control Unit, be that either the op code itself or one 

of its associated operators or operands. The Control Unit would then accumulate these elements in a 

"stack" (in the sense of "stacking things up"), acting upon them where necessary. It would continue to 

do this until it had the full set, whereupon it would write the final answer out to the specified 

destination, and discard the elements it had accumulated, leaving the stack free to start accumulating 

another set. For technical reasons, the most convenient stack structure is "last in, first out" or LIFO, 

and, by analogy with the old-fashioned desktop "in-tray", this way of doing things became known as 

"stack processing". 

The inventor of stack processing was Charles L. Hamblin (1922-1985), an Australian philosopher and 

computer scientist. McBurney (2003 online) explains that Hamblin first learned about computing when 

working as a radar technician during World War Two. He then did his doctorate on the topic of 

information theory before taking a post in philosophy at what is now the University of New South 

Wales. His radar experience then got him involved when the university bought one of English 

Electric's DEUCES in 1956, and he was set to work producing an in-house programming language 





called GEORGE, which used a stack-structured instruction queue and something called "Reverse 

Polish Notation" (Hamblin, 1957, 1962) ..... 

Key Concept - "Stack Processing", "Polish Notation", and "Reverse Polish Notation": An 

instruction "stack" is a constantly changing queue of instructions maintained by the Control Unit to 

cope with instructions which for one reason or another are not yet ready to be acted upon. Stack 

processing requires programmers to learn a curious new way of thinking. Specifically, it adopts the 

reverse of a mathematical notation system known as "Polish notation" (PN) (so named, after the 

Polish mathematician, Jan Lukasiewicz, who invented it in the 1920s). In PN, the brackets which are 

so vitally important to the conventional "BODMAS" system of algebraic expansion are not allowed, 

and great care therefore has to be taken to expand complex algebraic terms in the right sequence. 

Thus in normal arithmetic the expression < 4(a + b) > binds (a + b) together, meaning that 4 has to be 

multiplied by all the terms within the brackets, giving < 4a + 4b >. What Lukasiewicz did was to 

reorganise the expression as < x4+ab >, which we may read by scanning left-to-right as "multiply by 

4 the plussing of items a and b". This gives the same answer WITHOUT USING BRACKETS. What 

Charles Hamblin then did was to show that "Reverse Polish Notation" (RPN) was an excellent way 

of presenting arithmetical instructions to a stack processing logic unit. In RPN, < x4+ab > becomes < 

ab+4x >, which we may read as "take a, take b, and plus it to what you have accumulated so far, 

take 4, and multiply it by what you have accumulated so far". The real advantage comes whenever 

conventional notation calls for nested brackets, because these have to be resolved in matching pairs 

starting with the innermost. This means holding the entire expression (and it might be long and 

complex) in memory and making a number of passes through it, resolving one level of bracketing at a 

time. RPN thus saves a large Control Unit register and lots of time. On the down side, of course, there 

is the intellectual challenge of converting the expression into RPN in the first place, but, once that is 

out of the way, the fetch and execute logic is simplicity itself. Because operators and operands arrive 

one at a time, stack systems have been described as "zero addresses per instruction" systems. 

Stacks can be implemented either in hardware as an array of registers, or in software as a Main 

Memory array under the control of the machine's operating system. 

News of Hamblin's achievement soon made its way back to English Electric, who were so impressed 

with the idea that they used it in their 1960 KDF9, giving it a "hardware stack" capable of holding 16 

48-bit words. Here are the main details ..... 

"This was known as the 'nesting store' or 'nest'. A 'fetch' operation from memory copied the word from 

memory into the top of the nest, pushing all other values down one position. Arithmetic operations 

were carried out on the top few values in the nest, replacing the operands by the results. A typical 

sequence of instructions might look like 

Y0; Y1; +; =Y2 

This would fetch a word from each of locations Y0 and Y1 into the nesting store, add them, and place 

the result in location Y2. This sequence removed all the words that had been loaded, leaving the nest 

in the same state as before the sequence shown." 

Stack processing was also used in the 1961 Burroughs D825 and D830 and the 1963 B5000, as well 

as in the Hewlett-Packard HP9100A calculator. See Jones (2003 online) for more on the Burroughs 

B5000, and the Museum of Hewlett Packard Computing for more on the HP story. 

1.5 "Supercomputers" 





In Part 4 (Section 1.3), we saw how the Remington Corporation's UNIVACs did much to popularise 

business computing in the mid-1950s. Unfortunately, the corporation was still beset by 

interdepartmental and political rivalries, and in 1957 one of ERA's original founders, William C. Norris, 

resigned to found the Control Data Corporation. He took with him Seymour Cray as his Chief 

Engineer and a dozen or so other engineers and programmers, and so carefully had he chosen his 

people that the new corporation's first product, the fully transistorised CDC 1604, was ready only a 

year later. This was then followed by the world's first fully transistorised "supercomputer", the CDC 

6600, in 1964. 

Key Concept - Supercomputers: A supercomputer "is a computer that leads the world in terms of 

processing capacity, particularly speed of calculation, at the time of its introduction" (Wikipedia, 2003). 

The 6600 was a highly compact design, thanks to deliberately short internal cable runs and an integral 

Freon liquid cooling system [the electronics were effectively built inside a refrigerator], and this 

allowed it to achieve 3 mips. It thus "completely outperformed all machines on the market, typically by 

over ten times" (Wikipedia, 2003 online). Lundstrom (1987) describes some of the machine's 

technicalities ..... 

"The [CPU] consisted of ten separate 'functional units', each optimised to do only one particular 

operation - multiply, add, divide, shift, etc. The CPU communicated only with its central memory; it 

had no input/output instructions whatsoever. The CPU operated on a 60-bit word, which is unusually 

long. Included in the 6600 computer and communicating with the CPU's central memory [128k words, 

or about one Megabyte by today's measures] were ten independent 12-bit minicomputers, each 

having its own separate memory as well as access to the CPU's memory. These minicomputers, 

called Peripheral Processing Units (PPUs), provided the input/output instructions to keep the CPU fed. 

Thus a model 6600 consisted of eleven (or twenty, if you counted each functional unit separately) 

discrete programmable computers, all capable of working independently but all capable of 

communicating with each other through the central memory." (Lundstrom, 1987, p111) 

And the machine's principal designer, J.E. Thornton, adds ..... 

"The Central Processor of the Control Data 6600 Computer is based on a high degree of functional 

parallelism. This is provided by the use of many functional units and a number of essential supporting 

properties [.....] The ten functional units are independent of each other and may operate 

simultaneously. In a typical central processor program at least two or three functional units will be in 

operation simultaneously." (Thornton, 1970/2003 online, pp12-13) 

Figure 1 shows how these various processing modules were laid out ..... 

Figure 1 - The "Distributed Computing Architecture" of the Cray 6600 Supercomputer: 

Here we see the ten "Functional Units" (FUs) of the CPU [yellow highlights, right], the ten 

"Peripheral Processing Units" (PPUs) [green highlights, left], and the various elements of 

the Control Unit [red highlights, right], all neatly set out around the machine's Main Memory 

[blue highlight, centre]. When the control system decides that a particular FU is needed, it 

checks with the Scoreboard that that resource is currently free. If it is, the Scoreboard then 

issues the necessary control instructions, telling the FU in question when to start and what to 

do with the results when it has finished. If not, then that instruction is queued. The Scoreboard 





also interlocks the FUs when it is logically impossible to run operations simultaneously. The 

eight-element Instruction Stack permitted up to seven "old" instructions to be retained within 

the CPU, so that short program loops could be managed from within the stack without 

requiring repeated time-consuming FETCHes. 

The 6600 was actually upgraded "well after first deliveries" (Thornton, 1970/2003 online, p17) so that 

two machines could share a common "extended core storage", making the combination, perhaps, 

even more biologically lifelike [Thornton's Figure 8, for example, broadly resembles the bi-hemispheric 

vertebrate brain (op. cit., p18)]. 

Clever though it undoubtedly was, the 6600 lacked the all-round strengths of the latest offering from 

IBM, the System/360 [see next section], and, as a result, secured only a few highly specialist sales 

(eg. nuclear physics, meteorology, and the like). However, one of its lasting benefits was to show how 

instruction sets - which had grown bloated over the years - could be re-simplified, an approach which 

would later become known as "Reduced Instruction Set Computing" (RISC). In 1968, Cray 

designed the CDC 7600 as a replacement for the 6600. This made intensive use of advanced 

pipelining and a lean, mean, instruction set, and, at about 15MIPS, broke all the speed records of its 

day. However, it acquired no great reputation for reliability, and again sold only to those who needed 

processing speed first and foremost, and could afford to pay for it. 





1.6 The IBM System/360 

By the early 1960s, IBM was receiving more and more complaints about how difficult it was for new 

models to run software developed for earlier ones. All too often, potential customers were saying that 

they could afford this or that new piece of hardware, but not if it meant junking all the software they 

had struggled to get running on the older hardware. The company therefore set up a brainstrust in 

November 1961 to look into this problem, and a month later the panel came back with what became 

known as the "Spread Report". Here is the thrust of that report's recommendations ..... 

"The central realisation of the committee, was the need for a fully compatible family of machines. 

Each machine could specialise on particular areas, could offer different levels of performance, and at 

different prices, but the essential quality was that of complete compatibility. Ie. every program written 

for the family of machines could be executed on any one of the machines (obviously yielding to 

peripheral and memory requirements, and at different speeds)." [author] 

The result was one of IBM's all-time winners, namely the 1964 System/360 range of machines. A 

family of seven machine sizes was offered, to appeal to all sizes of organisation, but operating 

procedures and programming languages were standard across all of them (Ganek and Sussenguth, 

1999/2003 online). The development team included Eugene M. ("Gene") Amdahl (1922-1998), later to 

leave IBM to produce the Amdahl range of "IBM-compatible" competitor machines, and the operating 

system was developed by Frederick P. Brooks (1931-). Both Amdahl and Brooks had already 

contributed to the success of the Stretch system five years previously. 

ASIDE: Brooks has since been honoured as the father of modern IT Project Management. It was he 

who first publicly lamented the fact that computer projects could suck in programming hours like the 

proverbial bottomless pit; also of the phrase "the mythical man month" (Brooks, 1975). He was 

particularly critical of the tendency for higher management to throw additional staff at problems at the 

last minute, in the rather naive belief that this would help. It never does. It takes nine months to 

deliver a baby, Brooks explained, no matter how many women are assigned to the task! He 

was subsequently involved in the development of computer graphics and natural language processing. 

Nevertheless, it was Wilkes' concept of microcode which allowed it all to happen. Remembering the 

need for a family of machines, IBM gave the models at the bottom of the range lots of microcoded 

instructions and a cheap and relatively uncomplicated processor, whilst those at the top of the range 

were given less microcode (and hence ran faster), but needed more expensive processors to 

compensate. At the coding level, however, programs were effectively identical. In other words, it 

was finally dawning upon computer designers that in a world of technical and commercial 

compromises it was a machine's "architecture" which determined what it had been optimised for, 

and therefore who was likely to buy it. Thisted (1997/2003 online) explains the issue nicely ..... 

"A computer architecture is a detailed specification of the computational, communication, and data 

storage elements (hardware) of a computer system, how those components interact (machine 

organisation), and how they are controlled (instruction set). The System/360 also precipitated a shift 

from the preoccupation of computer designers with computer arithmetic, which had been the main 

focus since the early 1950s. In the 1970s and 1980s, computer architects focused increasingly on the 

instruction set." (Thisted, 1997/2003 online) 

We should also note that the System/360 followed Bemer and Buchholz's lead [see Section 1.3] and 

standardised on an 8-bit character code known as "Extended Binary Coded Decimal" (or EBCDIC, 





pronounced "ebbsie-dick", for short). This system supports a 256-item character set, using the codes 

00000000 (decimal zero) to 11111111 (decimal 255) inclusive, double the capacity of the 7-bit version 

of the ASCII system [reminder]. For sake of readability, however, each 8-bit byte was sub-divided into 

two 4-bit "nibbles", separately transliterated into hexadecimal. Thus 01001011 (decimal 75) was 

treated as 0100 (hexadecimal/decimal 4) followed by 1011 (hexadecimal B, decimal 11), and shown 

as 4B. 

TECHNICAL ASIDE - HEXADECIMAL: Hexadecimal is the base 16 numbering system, which means 

that each left order integer represents a power of 16 higher than the one to its right. This rather 

inconveniently means that you need 16 different characters per digit column, and so hexadecimal 

takes the decimal digits 0 to 9 inclusive, and extends these by the letters A for decimal 10, B for 

decimal 11, C for decimal 12, D for decimal 13, E for decimal 14, and F for decimal 15. You cannot go 

beyond hexadecimal F, because adding one to F will always "carry one" - thus hexadecimal F 

(decimal 15) plus 1 gives hexadecimal 10 (read this as "one zero", not "ten", because in hexadecimal 

it signifies < one 16 plus no units >), and hexadecimal FFF (decimal 4095) plus 1 gives hexadecimal 

1000 (read this as "one zero zero zero", not "thousand", because in hexadecimal it signifies < one 16 

to the power 3, no 16 squareds, no 16s, and no units >). 

1.7 On Line Transaction Processing and Time-Sharing 

It is important to remember that when the Atlas team invented multiprogramming [see Section 1.2], 

they were not offering access to multiple "online" users. Rather, there was a single central machine 

operator - not necessarily a programmer at all - who sat at the computer's control console typing in 

operating system commands (not programming language). The programmers sat at desks in offices 

and laboratories elsewhere, preparing their programs as punched card packs and submitting them, 

presumably with some form of authorising documentation, to the operator; and the real "end users" of 

the software, that is to say, the people who were paying for it all because they had some pressing 

need for the results it would bring them, may have been elsewhere still. The Cambridge University 

EDSAC, for example, made itself popular across the campus when the Mathematical Laboratory 

started to offer a data processing service to other faculties. 

How much better would it be, therefore, if a system could support a number of terminals in addition to 

the operator, making some of these available for software development, and the rest for live 

departmental applications [giving us, of course, the tripartite distinction between operations, 

development, and end-use which we showed diagrammatically in Part 4 (Figure 1)]. Many minor 

advances were made in this direction during the mid-1950s, but the most famous was "SABRE" 

(Semi-Automatic Business-Related Environment), IBM's real-time air ticketing system for American 

Airlines, and "a model for all point-of-sale transaction systems to come" (Waldrop, 2001, p75). This 

was the birth of the "on-line transaction processing" (OLTP) type of modern computing 

Key Concept - On-Line Processing: Processing is deemed to be "on-line" if and when the decision 

making elements of the machine are free to respond with only a few seconds delay to a particular 

enquiry or update. On-line processing is not available with any form of tabulated card system, 

because it is totally impractical to go directly to a particular card in a particular card set [see the 

paragraphs on "random access" in Section 3.1]; indeed in this respect, if no other, tabulator systems 

were a retrograde step compared to 19th century filing cabinet systems. On-line processing is 

sometime referred to as "on-line transaction processing" because there is a specific and brief 

exchange - the "transaction" - between the user and the machine [for a formal definition, click here]. 

The OLTP module within an operating system is known as the "TP Monitor" [Webopedia definition]. 





IBM's current TP monitor is its Transaction Processing Facility (TPF), first released in 1979. This 

evolved out of IBM's Airline Control Program (ACP), a System/360 project dating from the mid-1960s, 

which was itself heavily influenced, in turn, by the earlier SABRE and SAGE systems. Wilkes (1963) 

describes the OLTP facilities offered by Ferranti and English Electric during the 1960s, and in due 

course these evolved into ICL's Transaction Processing Management System (TPMS). 

SABRE came about because IBM had spent a lot of time assisting MIT in developing the SAGE air 

defence system, and it made good sense to leverage these rare skills. The company therefore 

contracted with American to look into the seat reservation problem in 1957, and by March 1959 a 

specification had been agreed. Detailed development then lasted another three years and cost an 

estimated $30 million. The pilot [no pun intended] version of the system was installed in 1962, running 

on an IBM 7090, fitted with "front-end processors" to handle the data communications processing 

load ..... 

Key Concept - "Front-End Processors" and "Cluster Controllers": A "front-end processor" is a 

small computer designed to extend mainframe input/output channels outwards onto a data 

communications network. A "cluster controller", on the other hand, is a small computer designed to 

extend a data communications network onwards onto the input/output channels of a number of 

remotely located access terminals. As to the software needed to manage all this, see firstly the indent 

on "Network Protocols" below, and then Section 3.2. 

We must not forget that an air ticketing system is an end-user system - it provides a user-friendly (for 

its day) application system to travel agency personnel, who, needless to say, write no code. Back at 

MIT, meanwhile, they had been making an altogether different point, looking at fully-fledged "timesharing", 

and here we again meet the psychologist-in-computing J.C.R. ("Lick") Licklider (1915-1990). 

Now we have already heard [see Part 4 (Section 1.1)] how Licklider had joined Bolt, Beranek, and 

Newman, a firm of Cambridge, MA, acoustics consultants, in 1957. While he was there, he helped 

them expand into software engineering, earning the (unofficial) title of "Cambridge's third university" 

(after Harvard and MIT) into the bargain. While thus engaged, he soon became convinced that it was 

only a matter of time and good design before properly trained operators would be able to hold a 

conversation of sorts with their CPUs. The concept was given the technical thumbs up by IBM's Bob 

Bemer in 1957, and one of the first to start work was the same John McCarthy whom we introduced in 

Part 4 (Section 4.7). The first large time-sharing system was MIT's "Compatible Time-Sharing 

System" (CTSS) in 1961. 

Key Concept - Time-Sharing and Related Concepts: "Time-sharing is an approach to interactive 

computing in which a single computer is used to provide apparently simultaneous interactive generalpurpose 

computing to multiple users by sharing processor time" (Wikipedia, 2003). Time-sharing is 

made possible by the fact that humans type slowly at the best of times, and even more slowly when 

they have to keep stopping to think. So when User A is busy, the odds are that Users B and C are 

momentarily inactive. It was in environments such as that provided by CTSS that programmers were 

first called upon to edit their own programs at their terminals, rather than plotting them out characterby-character 

on coding sheets for punching elsewhere. It is also when the distinction between 

"foreground" and "background" processing emerged. To run a program "in foreground" is to have 

it in constant communication with the initiating user terminal. This has the advantage that output can 

be inspected as it appears, but the disadvantage that it effectively locks out the terminal for the 

duration of the program. Foreground processing is therefore reserved for interactive work, or for short 

programs. All other work is processed "in background", with messages being routed to a job log file, 

rather than to the user terminal. All the user gets to see is a single prompting message at the end of 





run, whereupon s/he can check the job log to see if there were any problems. The distinction is readily 

demonstrated by the fact that readers of this paragraph will be able to print it off in background while 

continuing to read it in foreground. 

There then followed an extraordinary convergence of interests, with civilian systems like SABRE and 

CTSS suddenly needing the sort of technology developed for military command and control systems 

such as SAGE, and the military suddenly needing to know more about human factors. In 1962, this 

earned Licklider a move to the Pentagon's Advanced Research Projects Agency (ARPA) to help 

develop their Information Processing Techniques Office (IPTO). Here he continued his work on 

distributed systems, putting forward a number of detailed proposals to raise what would now be called 

the "connectivity" of the hardware then in use [more on connectivity in Section 3.2]. When Licklider 

left ARPA in 1963, he left the conceptual design to be fleshed out and made to work by his successor, 

Robert Taylor, under the name ARPANET. Taylor chose a young engineer named Larry Roberts to 

head the project, and the first problem to be resolved had to be the compatibility problem, because 

computers from the same manufacturer often could not intercommunicate, and computers from 

different manufacturers never. The solution came in two stages, namely (a) to build a "subnetwork" 

of telephone lines and switching points, and (b) to create communication "protocols" ..... 

Key Concept - "Network Protocols": Network protocols are standard methods of (a) authenticating 

which stations should actually be in a network, (b) identifying which station a message is to be routed 

to, (c) governing when, and at what speeds, stations are allowed to transmit and receive, (d) 

arranging for data compression and decompression, and (e) detecting errors in transmission and 

arranging for their correction. Nowadays, there are many highly technical network protocols in force, 

published by such agencies as the International Standards Organisation, but the Open Systems 

Interconnection (OSI) Reference Model coordinates them all. It is a reasonably non-technical 

overriding guideline, and it recommends a seven-layered analysis for any given communication, with 

the physical channel (the wire, etc.) consigned to the lowest level, and each layer communicating 

logically (but not physically) with the matching decoding layer(s) at other node(s). This type of 

arrangement is known as "peer-to-peer communication" (Gandoff, 1990). [IBM's OSI-compliant 

networking system, SNA, is described in Section 3.2].




Licklider rounded off his personal contribution by authoring a number of influential papers profiling the 

sort of knowledge interrogation software which Internet search engines have since made 

commonplace. 

1.8 The BTM-Ferranti and English Electric Stables 

In Part 4, we introduced the British Tabulating Machine Company (BTM) as "British Hollerith", holders 

of the British punched card licence (signed by Hollerith himself) since 1909 (Humphreys, 1997/2003 

online). Now just as IBM were arch-rivals with the Remington Corporation for the primary cardprocessing 

patents, so, too, were BTM and the Powers-Samas Company arch-rivals as the respective 

British licencees. However, rather than slug it out as IBM and Remington had done, the two British 

licencees merged in 1959 to become International Computers and Tabulators (ICT). Their first joint 

product was the 1962 1MHz, all-transistor, ICT 1301 [picture], complete with magnetic drum backing 

store and programmed (at least in the early versions) in machine code [specimen coding sheet]. In 

1963, a 1301 was the first mainframe to be used by the Metropolitan Police, and a decade or so later 

it was not unknown for scrapped systems to be bought up by television production companies for use 

as scenery in science fiction programs [example]. 

The 1301, however, was soon obsolete, and the Managing Director of the new company, Cecil Mead, 

had the strategic vision of bringing all British computer interests together under one roof. Negotiations 

duly began, and by 1963 ICT had acquired the computing divisions of GEC, EMI, and Ferranti, and, 

consequently, the job of trying to sell "the largest ragbag of incompatible computers it was possible to 

imagine" (Humphreys, 1997/2002 online). The acquisition of the Ferranti interests was a particularly 

good deal, because Ferranti brought with them their brand new FP6000 [courtesy of their Canadian 

subsidiary, Ferranti Packard], a machine with everything good about Pegasus and Atlas in its 

bloodstock. Devonald and Eldridge (1996/2003 online) recall how they were part of the working party 

which examined the Canadian system on behalf of Ferranti UK, and drew up a report identifying 

where still further improvements could be made. In the event, they were not a moment too soon ..... 

"..... in April 1964, the whole economic basis of the industry was transformed by the announcement of 

the IBM System/360 range of third-generation computers. It was estimated that the R & D spend for 

System/360 was of the order of $5 billion. At this point, all the mainframe manufacturers world-wide 

were forced into announcing computer ranges of comparable performance." (Campbell-Kelly, 

1990/2003 online) 

The FP6000 rapidly got the improvements Devonald and Eldridge had suggested, was renamed the 

1900-series, and was announced in September 1964. The 1900 series did most things right, and 

enjoyed considerable success at the heavy end of the British commercial mainframe market, before 

being upgraded in the late 1970s to the 2900-series, running the VME virtual machine operating 

system [more on which in Section 3.3]. 

As for Elliott Automation, their 400-Series machines had, following a strategic alliance with the NCR 

Corporation, actually outsold IBM for a while, and the company was encouraged to experiment with a 

transistorised upgrade. This project was led by the designer of the 405, Andrew St. Johnston, together 

with John Bunt and Roger Cook, and the result was the 800-Series. The first of these, the rangedefining 

Elliott 801 prototype and the experimental 802 did not go into mass production, but around 

250 of the 1962 all-transistor Elliott 803 were produced, three of which are currently in various stages 

of restoration, one at Bletchley Park, spiritual home of British computing [details]. 





Lyons, too, put together a third generation upgrade to their earlier range. This was the LEO III, and it 

came complete with both microprogramming [see Section 1.1] and multiprogramming [see Section 

1.2]. Here is how it was received ..... 

"There was no question that LEO III was a groundbreaking machine, and its later successes 

confirmed John Pinkerton's status as a computer designer of genius. Nonetheless, its introduction to 

the world was fatally hampered by mismanagement. As with LEO II, the design team working on LEO 

III was ludicrously understaffed - Peter Bird quotes a figure of just six people, compared with the 

armies developing new machines at IBM. [As a result] despite the excellence of the product, says 

David Caminer, selling it was still a problem." (Ferry, 2003, p166) 

In November 2001, one of the original LEO systems men, David Caminer, spoke at the IEE's Guildhall 

Conference for Business Leaders, London, on the prospects for business computing as it celebrated 

its 50th birthday and looked forward to its second half century. His main criticism of his former 

employers was that they had not exposed their IT division to the harsh financial realities of computer 

development (he explains that the developers tended to look upon the parent company as their "sugar 

daddy"). This oversight finally caught them out when the LEO 3 project ran short of cash in 1961, and 

in 1963 Lyons sold LEO to English Electric. Then the System/360s started to arrive in numbers, 

another round of rationalisations followed, and by 1967 Elliott Automation and Marconi had followed 

LEO into the English Electric fold. Finally, in July 1968, English Electric and ICT merged to form 

International Computers Ltd (ICL). Suddenly, the future of British computing, to say nothing of ICL's 

34,000 employees, was subject to the strategic steer of a single board of directors. As to why it had all 

gone so wrong, Usselman (1993/2003 online) may have one of the answers ..... 

"Another problem BTM faced was that it stood outside the university research establishment. This was 

true initially of IBM in the United States as well, but after the war that changed under the influence of 

the liberally funded, procurement-driven American military. In the U.S., moreover, universities and 

government had never established very firm connections, so IBM and other corporations faced little 

resistance from entrenched interests. In Britain, however, universities and government had 

established close links by the time of the war, with business drawn into the alliance only through the 

mediating agency of the consulting engineer. After the war, Britain's much smaller defence budget did 

not have the strength to dissolve those traditional bonds. University research remained closely tied to 

government and the military. This skewed efforts away from development and manufacturing.[citation] 

In the specific case of computing, this had the effect of keeping Britain's remarkable code-breaking 

machines and the pioneering computers developed at Manchester University separate from BTM and 

other manufacturers. In 1949, moreover, BTM severed its ties to IBM, thus depriving itself of ready 

access to an alternative source of computer designs." 

1.9 Machine Translation and Semantic Networks, 1959 to 1970 

The period 1959 to 1970 saw few real advances in the world of machine translation, with those who 

believed the technology had a future facing continued (and at times strident) criticism from those who 

did not. The arch-realist Yehoshua Bar-Hillel pronounced judgement on the context issue, for example, 

thus ..... 

"Fully automatic, high quality translation is not a reasonable goal, not even for scientific texts. A 

human translator, in order to arrive at his high quality output, is often obliged to make intelligent use of 

extra-linguistic knowledge which sometimes has to be of considerable breadth and depth. Without this 

knowledge he would often be in no position to resolve semantical ambiguities. At present no way of 





constructing machines with such a knowledge is known, nor of writing programs which will ensure 

intelligent use of this knowledge." (Bar-Hillel, 1960, p135) 

There was also an overdue touch of realism on the funding side of things. In 1964, the US 

government set up the Automatic Language Processing Advisory Committee (ALPAC), to report on 

progress with automatic intelligence gathering from Russian documents, and its 1966 report on the 

long-term prospects for MT was very negative. It concluded that MT was "slower, less accurate, and 

twice as expensive as human translation" (Hutchins, 2003 online), and observed that it would be a lot 

cheaper for the analysts involved to go away and learn Russian the old-fashioned way! 

Bar-Hillel also led the negative press for semantic networks, although here he seems to be hedging 

his bets somewhat. Here are his conclusions re the CLRU's [see Part 4 (Section 4.1)] Lattice 

Theory ..... 

"Now Lattice Theory is the theory of a structure which is so general that one should not be surprised 

to find it embodied in many actual situations. There can also be no doubt that lattice theory [.....] can 

be applied to linguistic investigations though I am not aware of any new insights gained so far by such 

applications. The applications made by the Cambridge group of their lattice-theoretical approach, 

inasmuch as they are valid, are only reformulations in a different symbolism of things that were said 

and done many times before." (Bar-Hillel, 1960, p122) 

So basically it was down to the network-philes to respond to this challenge by demonstrating some 

genuine "new insights", and as the 1960s got under way they set out to do just that. One of the first to 

report was Silvio Ceccato (1914-1997). In two linguistically highly technical papers (Ceccato, 1961, 

1967), Ceccato developed the idea of the "correlational net". Ceccato was concerned with the 

relationships established between mental constructions, be they perceived things (ie. nouns), or done 

things (ie. verbs), or whatever. Such constructions, when combined in some way, require that "the 

mental category of relationship comes about" (Ceccato, 1961, p91), and thought itself is "precisely an 

opening and closing of correlations" (p94). The node-to-node relationships within a semantic network 

are thus more important to thought and language than the mass of at-the-nodes "microknowledge" 

[our term]. This is an important point, and we shall be hearing a lot more about relationships 

and nodes when we get to Section 3.1. 

Another ex-CLRU member, Michael A.K. Halliday, went on to develop "systemic functional 

grammar", a linguistic theory based on lots of programmer-friendly decision trees called "systems" 

[we recommend Graham Wilcock's introduction to this subject], and generally to promote the 

structure-vs-function distinction within linguistics (eg. Halliday, 1970). Halliday also met with 

Berkeley's Sydney M. Lamb, and helped develop the latter's "relational network" (Copeland, 2000) 

[more on which in Section 3.9], and influenced the shape of Winograd's SHRDLU software [see 

Section 1.12]. 

The late 1960s also saw the first publications in a series of now-classical studies in cognitive 

psychology. The lead worker here was W. Ross Quillian, and the major papers are Quillian (1968) 

and Collins and Quillian (1969). What Quillian did was carry out a response time analysis of true-orfalse 

statements of the form , , , etc. The point which emerged was that some of the things we know about canaries (etc.) 

seem to derive NOT from the fact that it is a canary, but from the fact that it is a bird, that is to say, 

from properties at a "superordinate" conceptual node in a multi-layered "conceptual hierarchy". 

The team then drew an explanatory diagram [picture], which identifies both nodal and supranodal 





properties (ie. "inheritance"), and in which there is a broad correlation between knowledge access 

time and distance to travel within the hierarchy, both vertically and horizontally. 

1.10 The Turing Test, 1959 to 1970 

Although the Turing Test dates from 1950, it was not until the early third generation systems that 

academics had access to sufficient computing power to try their luck at it. The best known of the first 

wave efforts was by MIT's Joseph Weizenbaum ..... 

BIOGRAPHICAL ASIDE - JOSEPH WEIZENBAUM: Joseph Weizenbaum (1923-) was born in Berlin 

but became a US citizen in 1952. He trained as a systems engineer at Wayne University in the early 

1950s, and after experience with analog computation was headhunted by General Electric. He joined 

MIT in 1963. 

In 1964, Weizenbaum started to develop a computer program "with which one could 'converse' in 

English" over a teletype link (Weizenbaum, 1976/1984, p2). Remembering that it had been Eliza 

Doolittle's [picture] fate in "My Fair Lady" to perform a range of linguistic party pieces, Weizenbaum 

wittily named this program ELIZA. To get ELIZA to work, the program needed to be primed with a 

"script", "a set of rules rather like those that might be given to an actor who is to use them to improvise 

around a certain theme" (op. cit., p3). For Weizenbaum's first experiment, he turned ELIZA into 

DOCTOR, by giving it a script to allow it to "parody" a Rogerian psychotherapist. To see a sample 

interaction, click here. 

Now Eliza's secret was that "she" was simply rephrasing input statements as questions! Here is the 

how the trick worked ..... 

"The gross procedure of the program is quite simple; the text is read and inspected for the presence 

of a keyword. If such a word is found, the sentence is transformed according to a rule associated with 

the keyword, if not a content-free remark or, under certain circumstances, am earlier transformation is 

retrieved. The text so computed or retrieved is then printed out. [..... For example,] any sentence of 

the form 'I am BLAH' can be transformed to 'How long have you been BLAH', independently of the 

meaning of BLAH." (Weizenbaum, 1966, p37) 

After several years of experience with his software, Weizenbaum concluded that it would never be 

possible to computerise language without first solving the problem of language context. ELIZA had 

little to say about the potential for computer understanding of natural language, and Weizenbaum was 

surprised that anybody would think that it did (although he was justifiably proud that his software was 

able to maintain the illusion of understanding with so little machinery). With much the same sense of 

sadness and surprise, he also noted "how quickly and how very deeply people conversing with 

DOCTOR become emotionally involved with the computer and how unequivocally they 

anthropomorphised it" (op. cit., p6). (And, anecdotally, he was certain that some of his colleagues - 

despite knowing full well that they were conversing with a machine - nonetheless started telling 

DOCTOR their deeper secrets!) 

Another early contender for the Turing Test prize was PARRY, a program produced by a Stanford 

University team led by the psychiatrist Kenneth M. Colby. The clever thing about PARRY was that its 

creators (psychiatrists, remember) had made it ever so slightly paranoid. Its "conversation" was 





therefore full of lifelike but rather cynical observations on the unfairness of life. Here are some of the 

software's typical carefully prepared answers ..... 

 

 

By deliberately playing on the interrogator's emotions in this way, PARRY could be rather convincing 

as to its inner humanity, and some of the shorter exchanges are decidedly humanlike. On the other 

hand, so they should be, because they were originally devised by the programmer and stored as 

entire phrases - no word-by-word sentence building was involved, merely whole-sentence output 

selection. As it happens, PARRY would have been well within its rights to complain, because no 

sooner had its programming team showed that progress could be made, than the Turing Test's basic 

premise started to be challenged, and more stringent tests proposed []. Reader (1969) was one of the first to propose tightening the 

requirements of the Turing Test, and other more recent criticisms are reviewed in Section 3.11. 

And now, for something completely different, why not give the Turin Test a try? 

1.11 Neural Networks, 1959 to 1970 

In Part 4 (Section 4.5), we saw how Rosenblatt's Perceptron had set the early standard for artificial 

neuron studies. Not surprisingly, there were many imitators, and another early pattern recognition 

machine, Oliver Selfridge's (1959) pandemonium, went back to the first principles of perceptual 

theory for its inspiration. Selfridge anticipated Marr's (1982) theory of perceptual stages by identifying 

four successive "layers" of image analysis, each deploying a network of small neural elements to act 

in parallel to analyse some particular feature (a line or edge contour, say) of an incoming retinal image. 

The output from each level of analysis then became the input to the level of analysis immediately 

above. The metaphors of demons and clamour come from Selfridge's description of activated 

elements as "shrieking" for attention from above. Finally, a particular pattern of activation will prompt a 

high level "decision demon" to hazard a guess as to the identity of the external stimulus [Boeree 

(2003 online) talks us through some useful worked examples of this process, if interested]. 

TRE's Albert Uttley was also still active in this area. Having played with mathematical predictions of 

dendrite density and the like [see Part 4 (Section 4.5)], he went on to model the process of neuronal 

maturation in the human infant's brain (Uttley, 1959). He identified two separate, but complementary, 

basic processes, firstly the strengthening of connections which were conditionally relevant to the 

system's current needs, and secondly the active deletion of those which were not. Subsequent 

microanatomical studies have proved him right, for by and large nature takes no chances when 

putting nervous systems together: far more neuroblasts are produced than are needed, and cells 

which fail to migrate or pathfind are simply allowed to die off. Indeed, according to Levitan and 

Kaczmarek (1991:305), "as many as three quarters of the neurons destined for a specific neuronal 

pathway may die during early embryonic development". 

All in all, however, the early perceptrons were intrinsically very simple machines, and, when put to the 

test, did not really work that well. The purse strings gradually tightened, and in 1969 Marvin Minsky 





and Seymour Papert of the Artificial Intelligence Laboratory at MIT published a book entitled 

"Perceptrons" in which they threw serious doubt on how much such devices would ever be able to 

achieve. Funding duly collapsed, research teams were redeployed, and things went quiet for a 

decade or so [to go straight to the story of the rebirth of the perceptron in the guise of the modern 

neural network, jump to Section 3.6]. 

1.12 Machine Chess and Problem Solving, 1959 to 1970 

The 1960s were a period of consolidation for the developers of chess playing software, and in 1966 

Richard Greenblatt's MacHack was blooded in the Massachussetts Amateur Chess Championship, 

where it lost four matches and drew one. It returned in improved form the following year, and became 

the first program to defeat a human champion (Wall, 2003 online). As for machine problem solving in 

its more general form, the thrust was beginning to shift away from attempts to simulate mathematical 

reasoning, and towards the mysteries of natural language processing instead. Thus when the "Advice 

Taker" program was proposed by McCarthy (1959/2003 online), it attempted to solve problems by 

processing natural language statements, that is to say, its behaviour was designed to "be improvable 

merely by making statements to it, telling it about its symbolic environment and what is wanted from it". 

Which yet again brings us back to the science of linguistics, for what this new approach brought with it 

was the need for software capable of "parsing" a sentence ..... 

KEY CONCEPT/SKILL - "PARSING": To "parse" a sentence is "to resolve [it] into its component 

parts of speech and describe them grammatically" (OED). Alternatively, it is an attempt to identify 

"what may be called the structure of a sentence" (Banerji, 1966, p83). 

Unfortunately, linguists have not always agreed amongst themselves how best to go about parsing, 

and it was over ten years before anything really impressive came along. The honour here has to go to 

Terry Winograd, then of MIT's Artificial Intelligence Laboratory, who wrote a parser called "SHRDLU" 

as part of his 1968 to 1970 PhD studies (Winograd, 1970, cited in Weizenbaum, 1976/1984). This 

program engaged its human operator in a textual dialogue, concerning a screen display of apparently 

three-dimensional solid blocks [picture and example dialogue]. The commands and questions were 

analysed for linguistic structure - the parsing - and then applied to the machine's mental model of this 

three-dimensional world. Thus was successfully parsed and 

understood as VERB (IMPERATIVE) rather than, say, , ADJECTIVE 

rather than , ADJECTIVE rather than or , and so on. However, 

the process of relating each word to its "referent" (object or action) in the real world moves beyond 

the syntactic nature of the word to the semantic, and gradually drew Winograd into the world of the 

semantic network, forcing him to build a "cognitive-deductive" ability into his software, as evidenced 

by the following exchange ..... 

CAN A PYRAMID BE SUPPORTED BY A BLOCK? 

YES. 

CAN A PYRAMID SUPPORT A PYRAMID? 

I DON'T KNOW. 





SHRDLU could also cope with basic "pronoun resolution" tasks, and respond with a request for 

clarification when it was unsure ..... 

FIND A BLOCK WHICH IS TALLER THAN THE ONE YOU ARE HOLDING AND PUT 

IT INTO THE BOX. 

BY 'IT', I ASSUME YOU MEAN THE BLOCK WHICH IS TALLER THAN THE ONE I 

AM HOLDING. 

Requests for clarification such as this are commonplace in human verbal interaction, but require 

highly sophisticated psycholinguistic processing, often involving common sense cues or reference to 

earlier sentences. 

The SHRDLU software is available for immediate electronic download, by courtesy of the people at 

www.semaphorecorp.com. Click here, if interested, or here for more on "Project SHRDLU", an 

attempt by afficionados of the software at the University of Missouri at Rolla to port it from its original 

implementation language, MacLisp, to Common Lisp. The story of Edward Feigenbaum's 1965 

DENDRAL system belongs here by project start date, but is deferred to Section 3.5, and there treated 

as an early instance of a new type of reasoning system known as an "expert system". 

1.13 Machine Consciousness, 1959 to 1970 

There is really only one issue to introduce under this heading, and that is the problem of 

"embodiment". This issue was first raised by McCulloch (1965), who, with more than twenty years of 

practical experience in the field under his belt, simply pointed out that it might eventually prove 

impossible to build an artificially conscious computer brain for the simple reason that it would have no 

biological body to go with it. It was not "embodied", and as a result there would simply be too little for 

it to be conscious of. We shall be developing this point further in Section 3.12. 

2 - Microcomputing, 1968 to Date 

The story of the modern microcomputer can be told in many ways, and we are going to begin with the 

stories of four inventors and a "killer app" [definition below], before looking at some of the 

technicalities ..... 

2.1 An Wang and his Calculators 

The first of our inventors is Harvard Computation Laboratory's An Wang, previously introduced as the 

part-inventor of ferrite core memory [reminder]. Not realising what the long-term impact of his 

invention was going to be, Wang was concerned to find that opportunities at Harvard were drying up 

following the Computation Laboratory's spat with IBM [reminder], and in April 1951 he resigned to set 

up on his own "as a sole partnership with his six hundred dollars of savings as capital, no orders, no 

contracts, and no office furniture" (Weiss, 1993, p63). Fortunately, Wang's reputation within the 

industry stood him in good stead, and his company grew slowly but surely through the 1950s. 

However, as core memory was developed at MIT, he got sucked into an unsuccessful patents dispute 

over licensing rights. Wang then did what only the very best geniuses manage to do - he geniused 

again, but this time he was careful to deliver the complete and legally unassailable package. His 

breakthrough came in the early 1960s, when Wang devised circuitry to compute logarithms using 





fewer than 300 transistors. He patented this in 1964, and used it in a desktop calculator named LOCI. 

The machine retailed at $6700, and the marketing edge came from the fact that purchasers got digital 

computing power at a fraction of the hardware cost of a mainframe, and without having to employ any 

professional programming staff. This was followed in 1965 by the Wang 300-series at from around 

$1700, and at a stroke the electromechanical calculator market - with a pedigree going all the way 

back to Pascal and Leibnitz - was doomed. By 1986, Wang Laboratories employed 30,000 staff. 

2.2 The Invention of Integrated Circuitry 

Our second inventor is Robert Noyce, and the invention is the "planar process" of semiconductor 

production. In September 1957 Noyce was one of the eight founders of Fairchild Semiconductor, and 

the new company's first director of R & D. All eight men had previously worked for Shockley 

Transistors, the company founded by William Shockley, co-inventor of the transistor in the late 1940s, 

and were keen to put their knowledge of semiconductors to the commercial test. The critical invention 

came after only a few months ..... 

"During his tenure as head of R & D, Noyce patented an idea for an integrated circuit [..... His] great 

insight was that a complete electronic circuit could be built on a single chip, using specialised 

techniques (called planar processing) recently developed by his colleague Hoerni. Noyce's conception, 

and the subsequent two-year development effort [would] eventually prove to be of monumental 

importance to Semiconductor, and, indeed, to the entire electronics industry." (Berlin, 2001/2003 

online; Jean Hoerni (1924-1997) was the physicist amongst the ex-Shockley men) 

The 1961 "Fairchild chip" [picture] had four transistors on it, and high profile projects such as 

NASA's Apollo Guidance Computer were buying them up at around $1000 apiece [details]. By 1968, 

better fabrication techniques had both slashed the price and pushed the transistor count up to 200 per 

chip, allowing entire systems to be mounted on a single chip, giving the world the "microprocessor". 

Our third inventor is Jack St. Clair Kilby (1923-), one of the "few living men whose insights and 

professional accomplishments have changed the world" (Texas Instruments website). Kilby joined 

Texas Instruments [company history] in 1958, and immediately did for them what Noyce was doing for 

Fairchild. In other words, he "conceived and built the first electronic circuit in which all of the 

components, both active and passive, were fabricated in a single piece of semiconductor material half 

the size of a paper clip. The successful laboratory demonstration of that first simple microchip on 

September 12, 1958, made history" (ibid.). In the event, however, the Noyce-Hoerni technique was to 

prove markedly more cost-effective in production, and Texas Instruments eventually bought that 

method in. 

And our fourth inventor is Gilbert Hyatt, who in 1968 trademarked the name "microcomputer", and 

who then, with an "effective date" of 28th December 1970, filed for a patent for an entire computer on 

a chip. However, due to prolonged litigation, this patent was not granted until 17th July 1990, and then 

reversed on appeal in 1996. The chip had a large central array of logic gates, surrounded by six 

registers, two timing units, a channel control unit, and a "scratchpad memory (SPM)" unit, a 

rudimentary sort of "cache memory" ..... 

Key Concept - "Cache" Memory: A memory "cache" is a memory resource physically situated on 

the CPU chip rather than at a distance away in Main Memory. It is intended to hold high demand 

memory pages without the need for chip-to-chip data transfers, thus saving time. 





What Hyatt did well was to set up a company called Micro Computer, and amongst the venture 

capitalists who bought in were Robert Noyce and a colleague of his named Gordon Moore. What 

Hyatt did not do well was remain friends with Noyce and Moore. He refused in 1971 to sign his patent 

rights over to them, funding was withdrawn, his company ceased trading, and Noyce and Moore went 

on to prosper as the Intel Corporation. Twenty five years later, US law pronounced to the effect that 

Hyatt had tried to patent too general an idea, and that that was not protectable under patent law. 

2.3 The "Killer App" 

As for the "killer app" [this quaint phrase describes a computer application which more or less 

perfectly fills a previously unrecognised commercial need, and sells accordingly], this was without 

doubt the word processor (although the spreadsheet comes a worthy second). The antecedent 

technology was the 1961 IBM "Selectric" (or "golfball") typewriter. This delivered each keystroke via 

an electrically activated spherical typehead, in which the letter to be impressed was chosen by 

determining the angles of azimuth and pitch of the typehead at the time of striking. All these angles 

were set, in turn, by electronic signals generated by the keyboard, and in 1964 the system was 

upgraded to store those electrical signals on a magnetic tape, thus allowing the same document to be 

typed time after time, from memory. Moreover, by pausing the tape, it also allowed errors to be 

detected, and minor corrections/insertions made. For the first time, "typed material could be edited 

without having to retype the whole text" (Kunde, 1986/2003 online). In 1969, IBM replaced the 

magnetic tape with a magnetic card, and in 1971, replaced the card with Al Shugart's recently 

invented "floppy disk". That same year, Wang Labs brought out the Wang 1200 word processing 

system. 

ASIDE: In 1976, the present author did commercial word processing on an Olivetti TES501, a desksized 

electronic typewriter, complete with eight-inch floppy disk, a single line side-scrolling display, 

and a daisy-wheel character printer, retailing for around £6000. Ten years later he could do more, and 

quicker, on an Amstrad PCW [picture] retailing for around £300. 

2.4 The Integrated Circuit Industry 

We have already recorded the birth of the chip in Section 2.2. As for the story of its subsequent 

exploitation, we present this in timeline form, collated from Siewiorek, Bell, and Newell (1982) and the 

sources specifically referenced ..... 

1968 - In July 1968, ex-Fairchild experts Robert Noyce and Gordon Moore set up Intel Corporation 

to develop and exploit DRAM (= "dynamic random access memory") memory chips. The 

commercial motivation here was that ferrite core store was actually technically difficult to 

miniaturise, so that anyone managing to produce a workable solid state flip-flop resource would 

command a massive marketplace. 

1969 - In April 1969, Masatoshi Shima, of Busicom Corporation, discussed with Intel his ideas for 

the chip architecture for a decimal desktop calculator. Intel agreed to produce these, but in 

September 1969 one of their engineers, Marcian E. ("Ted") Hoff counter-proposed with the plans 

for what would become the binary Intel 4004 chip. This was something of a masterstroke, because 

it would not just satisfy the specific Busicom calculator contract, but would also service small 

general purpose computing needs as well. That November, Datapoint Corporation's Victor D. Poor 

proposed an 8-bit programmable microprocessor. Poor offered the design to both Intel and Texas 

Instruments, and the latter took it on (Port, 1996/2003 online). 





1970 - During 1970, Hoff, Shima, Stanley Mazor, and Federico Faggin finalised the 4004 design 

using around 2000 transistors and with parallel wiring. 

1971 - In March 1971, Intel began deliveries of their 4004 to Busicom. In May, Texas Instruments' 

prototype 8-bit microprocessor was demonstrated to Datapoint. In July, Texas Instruments' Gary 

W. Boone produced the prototype of the TMS 1000 microcontroller chip, the first "computer-on-achip" 

(that is to say, a CPU microprocessor - as above - PLUS the supporting RAM, I/O, and 

ROM). The TMS 1000 family went into production in 1974, and was used across TI's calculator 

range. In November, Intel announced the 4004 as heralding "a new era of integrated electronics". 

1972 - In September, Texas Instruments announced that it was entering the calculator market to 

leverage its chip know-how. In November, Intel announced the 8008 chip. 

ASIDE: The Intel lineage went on to define by number the generations of the modern PC. The 

4004 and 8008 were followed by the 8080 in 1974, the 8085 in 1976, and the 8086 in 1978. In that 

seven-year period, processing power increased about a hundred fold, and price decreased by 

about the same factor (from $300 a chip down to $3). The 8086 was followed by the 80186 and 

80286 in 1982, by the 80386 in 1985, by the 80486 in 1989, and by the first of the modern 

Pentiums in 1993. There is thus a direct historical line from the biggest and best of the modern 

"Intel Insides" back to the Bell Labs team who discovered semiconduction in the late 1940s. 

1975 - IBM introduced the IBM 5100. It bombed commercially, and for the next five years the 

company suffered as the home computer market exploded around it. 

These, then, were the specific physical devices which defeated Hyatt in his long-running patents 

dispute. TI's microcomputer patent #4074351 describes the final item as "a one-chip device about 

one-fifth of an inch square, typically with more than 20,000 transistors or related electronic elements, 

and is the first integrated circuit to contain all of the essential functions of a computer: program and 

data memory, arithmetic unit, control, and input-output circuits" (TI website, 2003 online). 

2.5 The PC Software Industry 

A chip, of course, does nothing without some sort of operating software, and the story here begins in 

1972 when William H. ("Bill") Gates and Paul G. Allen, set up the Traf-O-Data company to develop an 

automatic traffic recording system based around the Intel 8008 chip. This was one of many small 

company attempts to put the new technology to work, and in 1974 a lecturer at the US Navy's 

Monterey Postgraduate School, Gary Kildall (1942-1994), produced the first microcomputer operating 

system, CP/M. This was designed for the April 1974 Intel 8080 chip, and - foreseeing the as-yet-nonexistent 

home computer market - intended to provide it with a range of simple user commands. 

Leaving the navy in 1976, Kildall founded Digital Research to market the product, and was soon 

selling copies at $70 a time. In August 1980, Tim Paterson, of Seattle Computer Products, started 

shipments of QDOS as a (just legal) CP/M clone. 

Attention now turned from operating systems to programming languages, and this is where Traf-O- 

Data - now renamed Microsoft - comes in. While Kildall and Paterson had been developing their rival 

operating systems, Gates and Allen had been developing a language called BASIC for the Intel 8086. 

This was a user-friendly interpreted language (that is to say, it executed on an instruction-byinstruction 

basis from the source code), and it first saw the light of day in early 1975, just a few 

months before the first home computer shops started opening. These players and these products then 

proceeded to make a little history. In 1980, IBM approached tiny Microsoft, wanting to commission an 

operating system for a proposed new range of home computers. Microsoft, more interested in BASIC, 





simply recommended CP/M. IBM went away, but their negotiations with Kildall failed. They returned to 

Gates with their chequebook open, and Gates and Allen - reconsidering their options - bought in 

Paterson's QDOS for $50,000, and licensed it straight back out again to IBM for $15,000. To normal 

mortals, of course, this looks like a $35,000 kick in the pants, but not to the visionaries at Microsoft, 

who saw that for every PC they helped IBM to sell there was a decent chance for them to follow up 

with a sale of BASIC! And the rest, as they say, is history. 

3 - Mainframe Computing, 1971 to Date - Fourth and Fifth Generation Technology 

In this section we complete our review of milestone innovations in the history of computer memory, by 

looking at mainframe systems from 1971 to date. Broadly speaking, this divides into the period of the 

"fourth generation" computer (1971 to 1979), in which "large scale integration" (LSI) was replaced, 

in turn, by "very large scale integration" (VLSI), followed by the period of the "fifth generation" 

computer (1980 to date), in which component size would be less and less critical, but processing 

architecture more and more so. Specifically, the fifth generation machines would be departing from 

the Eckert-von Neumann serial processing model in favour of ever more parallel architectures. 

3.1 The Arrival of Database 

We begin by reminding readers of IBM's 1957 invention of the RAMAC, the first commercial hard disk 

drive, a two-ton monstrosity capable of storing 5 megabytes of information (equivalent to less than 

four of today's standard density floppy disks, weighing a few grams and costing pennies). We offer 

this reminder, because, despite its girth, RAMAC was the key to giving computer users "random 

access" to their data, provided only that it could be "keyed" in some way. Given a suitable unique 

key (eg. a National Insurance Number), and using either an "index" or a "hashing algorithm" 

[details], the physical machine address of the desired record - even if one record out of a file of 10 

million similar records - can be obtained; and, using that machine address, the read-write heads on a 

magnetic disk can position themselves above the appropriate track in milliseconds. As a programmer, 

therefore, this enables you to state what you want, and have it arrive in your input record area a 

second or so later. Random access technology thus broke down barriers which had been troubling 

systems designers since the late nineteenth century, namely how to locate one person's data out of a 

census-full, say, or one account holder's details at a bank, etc., etc., etc. 

But "direct-hitting" of this sort was not the only benefit. Conventional (ie. pre-Hollerith) filing systems 

and Hollerith style punched card systems had encouraged single long records, each containing all the 

data relevant to the target entity, for in those days it did not matter if you pulled a person's card or a 

customer's folio to check on only one or two details - the cost lay in locating and retrieving the card or 

folio, not in examining its contents. With electronic data, however, long records meant dragging 

around a lot of bytes when only a subset thereof was actually needed, and so the search began for 

ways of spreading your data out in a predetermined fashion, and of then using data management 

software to get you only the fragments you needed. The result was the first "Database Management 

System", or DBMS ..... 

Key Concept - The Database Management Systems (DBMS): A DBMS is "a software system that 

facilitates (a) the creation and maintenance of a database or databases, and (b) the execution of 

computer programs using the database or databases" (Alliance for Telecommunications Industry 

Solutions). It is an extension [that is to say, you have to buy it separately] to a computer's standard 

operating system, and it allows data to be fragmented, stored, and subsequently retrieved to order, all 

without cross-record confusion. 





The pioneer of database was Charles W. Bachman (1924-). Here is the "once-upon-a-time" aspect of 

the story as told by Hayes (2002/2003 online) ..... 

"In 1961, Charles Bachman at General Electric Co. developed the first successful database 

management system. Bachman's integrated data store (IDS) featured data schemas and logging. But 

it ran only on GE mainframes, could use only a single file for the database, and all generation of data 

tables had to be hand-coded. [//] One customer, B.F. Goodrich Chemical Co., eventually had to 

rewrite the entire system to make it usable, calling the result integrated data management system 

(IDMS). [//] In 1968, IBM rolled out IMS, a hierarchical database for its mainframes. In 1973, Cullinane 

Corp. (later called Cullinet Software Inc.) began selling a much-enhanced version of Goodrich's IDMS 

and was on its way to becoming the largest software company in the world at that time." 

During the 1960s, different users developed the early concepts and applied the early products in 

different ways, seriously impairing the exchange of data between systems, and it was therefore not 

long before some sort of industry-standard approach was being called for. This came in the shape of 

a comprehensive statement of database principles made by the Codasyl Database Task Group in 

1969 (Codasyl, 1969, 1971; ANSI/SPARC, 1976). These advisory reports cover every aspect of the 

interaction between non-technical system users and their highly technical computing hardware, and 

were inspired throughout by the single central axiom that the internal complexities of a database 

should at all times remain totally transparent to the end-user. A DBMS, in other words, should allow 

users to concentrate upon their data rather than upon the tool they are using to view it. 

Another new approach was popularised by an English-American mathematician called Edgar F. 

("Ted") Codd (1923-2003). Codd had joined IBM in 1949, and had served time on the SSEC and 

Stretch teams, before switching to research into methods of data management. Here is Hayes 

(2002/2003 online) again ..... 

"Meanwhile, IBM researcher Edgar F. ('Ted') Codd was looking for a better way to organise databases. 

In 1969, Codd came up with the idea of a relational database, organised entirely in flat tables. IBM put 

more people to work on the project, codenamed System/R, in its San Jose labs. However, IBM's 

commitment to IMS kept System/R from becoming a product until 1980. [//] But at the University of 

California, Berkeley, in 1973, Michael Stonebraker and Eugene Wong used published information on 

System/R to begin work on their own relational database. Their Ingres project would eventually be 

commercialised by Oracle Corp., Ingres Corp. and other Silicon Valley vendors. And in 1976, 

Honeywell Inc. shipped Multics Relational Data Store, the first commercial relational database." 

Key Concept - The "Flat File" or "Table": A "flat file" is a file composed of large, identically 

formatted, data records, which, properly indexed, is ideal for random access storage and retrieval of 

uniquely keyed individual records. At heart, it is the technology of the filing cabinet, made digital; 

brilliant for "read only" or non-volatile files, or the adhoc analysis of "large subset" enquiries, but 

guaranteed to struggle with volatile data and lacking the flexibility of traversal needed for flexible 

enquiry routes on a single record. 

And the ACM ..... 

"While working for IBM in the 1970s, [Codd] created the relational model, the first abstract model for 

database management, which facilitates retrieval, manipulation, and organisation of information from 

computers. It led to commercial products in the 1980s, originally for mainframe systems and later for 





microcomputers. Relational databases are now fundamental to systems ranging from hospital patient 

records to airline flights and schedules." [Citation] 

And IBM ..... 

"In a landmark paper, 'A relational model of data for large shared data banks', Codd proposed 

replacing the hierarchical or navigational structure with simple tables containing rows and columns. 

'Ted's basic idea was that relationships between data items should be based on the item's values, and 

not on separately specified linking or nesting. This notion greatly simplified the specification of queries 

and allowed unprecedented flexibility to exploit existing data sets in new ways,' said Don Chamberlin, 

co-inventor of SQL, the industry-standard language for querying relational databases [.....] Janet 

Pema, general manager of Data Management Solutions for IBM's Software Group, expressed her 

admiration for the inventor of the product for which she is now responsible. She remarked that 'Ted 

Codd will forever be remembered as the father of relational database. His remarkable vision and 

intellectual genius ushered in a whole new realm of innovation that has shaped the world of 

technology today .....'" [Citation] 

So how did everything fit together? Well basically, your database team had to do a number of very 

precise things in a very precise order, as follows ..... 

(1) Carry Out Data Analysis: The first step is to carry out a detailed investigatory study of the 

business (or department) in question, in order to document the data stored and used within it. The 

most important technique here, whether working towards an IDMS or a flat file system, was "Entity- 

Relationship Modelling" (ERM). As its name suggests, an ERM exercise involved recording "the 

entity and relationship types in a graphical form called, Entity-Relationship (ER) diagram" (Chen, 

2002/2003 online), and this invariably invites the application of "Set Theory" whenever the analysis 

reveals one-to-many relationships within your data types ..... 

Key Concept - The One-to-Many Relationship of Entities: A company may have many customers, 

each placing many orders. A warehouse may have many zones, each with many aisles, each with 

many bays, each with many bins. And so on. 

When you have completed your ERM, it will provide you with a "corporate non-technical view" of your 

data, a real world view, in which the organisation's processes and data, having been identified by the 

skills of the business analyst, are set out in a set of diagrams and memoranda known cumulatively as 

a "business model". This provides what is known as a "logical" view of how the organisation 

operates, and one of the most important specific models is a diagram known as a "data model", 

which records what real world objects the organisation is concerned with, how they behave, and what 

their properties are. [For a more practical introduction to the preparation of a data model, see our epaper 

on "Data Modelling".] 

(2) Set Up a "Database Schema": The next step is to convert the data model into an equivalent set 

of declarations and descriptions known collectively as a "database schema". Unlike the data model, 

however, the database schema is now in a form which can be stored within, and manipulated by, the 

DBMS. This is a more technical view of the data than hitherto, and constitutes the first major step in 

bridging the gap between the data as the user knows it and the hardware on which it is eventually to 

be stored. [This is the point at which you finally have to decide between a network system such as 

IDMS, a hierarchical system such as IMS, or one of the proprietary flat file systems.] 





(3) Set Up Database "Subschemas": The third step is to create a "departmental" view of the data. 

This is another technical view, and reflects the fact that no single application program will ever need 

access to all the available data. Each individual end-user - and that includes even the most senior 

executives - only needs access to a fraction of that data, and for him/her to be shown too much is at 

best inefficient, and at worst a breach of system security punishable by civil or criminal law (or both). 

This "need to know" facility is provided by subsets of the schema known as "subschemas", each one 

allowing an individual application program to access only the data it is legitimately concerned with. 

(4) Set Up Database "Storage Schemas": The final step is to create a "machine level" view, and 

allows the data as defined in the schema to be "mapped onto" the particular installation's physical 

storage devices. This is achieved by declaring what is known as a "storage schema" to the DBMS, 

which the DBMS then uses to translate every user-initiated store and retrieve instruction into a set of 

equivalent physical store and retrieve instructions. This is therefore the second major step in 

bridging the gap between the data and the hardware on which it is to be stored. 

We turn now to the internals of the 1973 Cullinane DBMS product, because it was in managing 

physical storage that IDMS really showed how clever it could be. Four major design principles were 

involved, as now reviewed ..... 

The first IDMS design principle was that data should be organised into "records" and computer 

filestore into "pages". The latter become the unit of transfer between the DBMS (and thus the user) 

and the physical hardware. Their size was decided upon by the design team, and the number of 

records which will fit onto each page is therefore a function of page size relative to record size. No 

matter how much data is involved, each record can then be located with total precision and in only a 

few milliseconds by knowing (a) which page it is stored on, and (b) how far down that page. The 

resulting two-component page-line address is known as the "database key" for that record. Room for 

future expansion is provided in advance simply by varying the total amount of filestore available. A 

database might be set up, for example, with its pages only 40% full, to guarantee plenty of room (and 

time) for growth. 

The second IDMS design principle was that each different real world entity type should be 

represented by a different database record type. Each record type is then allowed to occur as many 

times as necessary to do the job. Thus for the record type there could be many million 

"occurrences" of that record in a given database, each with its own unique database key, but each 

laid out internally in exactly the same way (name, sex, age, height, etc). 

The third IDMS design principle was that some data records should be allowed to "own" others. This 

capitalises on the "set" relationship(s) already identified, such that each given set owner can own one 

or more set members. The owner-member arrangement is the network database way of coping with 

the sort of one-to-many relationships which exist between many real world entities. For example, the 

fact that one real life person may own many real life books could be implemented on the database as 

record type owning a set of record type . [It is up to the design team, incidentally, 

whether the records are clustered on the same page as their owner or else more widely 

distributed throughout the remainder of the database, and it creates havoc, incidentally, when they get 

this sort of decision wrong.] 

Key Concept - The Computer Data Network: What Bachman and B.F. Goodrich had created, and 

what the Codasyl Task Force had standardised for general release, was the "network database" 

(a.k.a. "Codasyl database"). Using the entity-relationship analysis approach to interface the results of 





Business Analysis with the DBMS schema they created a network structure capable of random 

access updating and enquiry.




Retrieval Option #5 - Run Currency: This is where any record, immediately after retrieval by any of 

the foregoing methods, is totally and centrally available for interrogation and update. It is the record 

currently being processed. Unlike set currencies, therefore, only one record can be "current of run" 

at a time. The use and value of this facility is also further explored in Part 6 and Part 7. 

Key Concept - The Database Currency: A database currency is a software device invented by 

database systems programmers to help applications programmers "keep their place" at one point in a 

program while a subprocess is sent off to do something important elsewhere. It works by holding in 

memory the key parameters of the superordinate search pattern for the duration of an excursion into 

one or more subordinate search patterns, so that the former can be restored and continued as soon 

as the excursion is over (just like keeping your finger in one page of a book, while you look quickly to 

one or more other pages). The device comes as standard with what are known as "Codasyl" 

databases such as Computer Associates' Integrated Database Management System (IDMS), and is 

actually nothing more than a small address table held in memory and constantly updated. For a 

friendly introduction to database currency technology, click here.




second-by-second updates, the big prints, and the routine small enquiries, whilst the flat file 

systems handled the data management and large enquiries using QueryMaster, ICL's own 

structured query language. Each suite of programs therefore played to its inherent strengths, 

to the ultimate benefit of the company. Flat file or otherwise, databases are important to 

cognitive scientists because they are the computer industry's only implementation of semantic 

networks. As such, they generate several noteworthy metaphors in a number of areas of 

memory theory, not least that of calcium-sensitised medium-term memory. We return to the 

topic in Part 7. >> 

3.2 "Connectivity", 1971 to Date 

We have already seen [see Section 1.7] how the 1960s witnessed major breakthroughs in online 

transaction processing, time-sharing, and campus-wide networking software. By 1971, it was possible 

to link a mainframe via a front-end-processor onto a telecommunications network, and thence either 

(a) via a cluster controller to a nest of remote user workstations, or (b) via a remote front-endprocessor 

to another mainframe. In 1974, IBM capitalised on this body of experience by introducing 

their Systems Network Architecture (SNA). This was a package of the hardware, peripherals, 

system software, networking software, cabling standards, and communication protocols necessary to 

set up a mainframe computing network. The development was guided by, and fully compatible with, 

the Open Systems Interconnection (OSI) Reference Model [details] (albeit it substituted IBM's own 

house terminology whenever it could), and automatically took care of such everyday networking 

problems as line or modem failures and node overloads. Upgraded functionality was later provided to 

cope with the subtly different requirements of microcomputer systems, and the resulting product was 

called Advanced Peer-to-Peer Networking (APPN). [For a thorough introduction to SNA and APPN, 

click here.] 

The OSI Model also helped steer the design process as the demand arose for what is today known as 

"client-server" networking. This is the name given to Internet-type networks in which the processor 

at one of the nodes has been set up as a "server", specifically to service the data requirements at the 

remaining nodes. Client-server is not a product as such, but rather a conceptual "file-sharing 

architecture" model which manufacturers can map their specific products onto, and the main 

controlling protocols are the US Department of Defence's TCP and IP (usually seen together as 

"TCP/IP"). Here are the technicalities ..... 

"Transmission Control Protocol" (TCP): TCP is a "transport-level" protocol [reminder], and "is 

responsible for verifying the correct delivery of data from client to server" [author]. This means taking 

all necessary steps to detect accidental data loss in the network, and, once detected, taking further 

steps to have it retransmitted. 

"Internet Protocol" (IP): IP is a "network level" protocol [reminder], and "is responsible for moving 

packets of data from node to node" [author]. This means taking all necessary steps to determine the 

optimal transmission path through the available intermediate routing stations. 

3.3 The ICL-Fujitsu Experience, 1971 to Date 

Newcomers to transaction processing concepts should refamiliarise themselves with the 

topics of the Virtual Machine Operating System and the TP Monitor, from Sections 1.2 and 1.7 

respectively, before proceeding. 





The ICL 1900s [see Section 1.8] were well-built third generation machines, and thus had a decent 

enough commercial life. Nevertheless, by the late 1960s they were beginning to show their age and 

the company started to consider how they should be replaced. Procter (1998/2003 online) explains 

how plans for the upgrade started to take shape in 1969, when a "jury" was set up to evaluate various 

optional ways forward. They considered four options for what they were already referring to as their 

"new range", namely, (a) to develop the 1900-series, (b) to go for the "Basic Language Machine", a 

concept computer being worked on in-house by a team led by John Iliffe, (c) to buy in Manchester 

University's "Mark V", the MU5, or (d) to go for the "synthetic option", a combination of the others. 

They decided on the latter, and, after five years intensive work, the 2900-series was launched in April 

1974, complete with a highly versatile operating system known as the Virtual Machine Environment 

(VME) [nothing to do with the VME bus] 

Now the 2900s were typical fourth generation systems. They were robust and efficient, and could 

cope with the heavy processing loads presented by transaction processing and database applications, 

and they made good use of the newly arrived "Fourth Generation Languages", or "4GLs" ..... 

Key Concept - Fourth Generation Languages: A 4GL is a proprietary software package designed 

to write 3GL code for a programmer more cost-effectively than s/he could do it her/himself. 4GLs do 

this sort of "code generating" by constantly referring to previously entered "metadata" - data about 

data - contained in a "data repository" or "data dictionary". Programmers using 4GLs are thus 

relieved of the need to become experts in the underlying 3GL. Unfortunately, it is not unknown for the 

benefits of 4GLs to be overstated at point of sale. Yes they work, but the code generated is rarely 

anywhere near as optimised for processing efficiency as expert hand-written code. Accordingly, 4GLs 

should only be used when response time is not a critical issue. 

The 2900s actually reached new heights of sophistication in their VME TP Monitor, TPMS. Here is 

how ICL described the transaction processing problem, and their solution to it ..... 

"Transaction processing operates in its own environment known as a transaction processing service. 

The environment provided is one in which many people can hold simultaneous conversations with 

computer programs about some business they have in common. The computer's store is used to 

maintain the business information on which the users of the service all depend, and it can be 

interrogated directly about that information from a computer terminal and the answers to critical 

questions can be obtained with only seconds delay. Moreover, only a few copies of the relevant 

applications programs are required to support a high volume of simultaneous enquiries from a large 

number of connected terminals. [//] A transaction processing service and its users interact by means 

of message-reply pairs. The user inputs a message or query at his terminal as the first half of the pair. 

This is then processed by a user-written application program. Finally, the service provides an 

appropriate response to that message as the second half of the message-pair and sends a reply to 

the terminal of origin. Typically, the message concerns one of the many transactions that make up the 

daily life of the business, for example the receipt or despatch of an order, an invoice amendment or 

stock update, and frequently it will cause the service to update the associated data files. The 

information in these files will therefore always reflect the overall state of the business, and can be 

used to answer queries or generate reports as and when required, using completely up-to-date 

information." (International Computers Limited, 1987, p1; italics original) 

The way TPMS organised its application software was to bundle together sub-selections of 

applications programs, and to load these as compound object code files known as Application 

Virtual Machines (AVMs), thus ..... 





"The program modules which process the various messages may also be grouped into related sets, 

known as AVM types, which provide a means of controlling the allocation of system resources and of 

optimising performance. Any one AVM type may contain one or many different program modules, and 

there may be many duplicate copies of a particular AVM type concurrently active. This means that a 

number of identical or similar messages may be input from different terminals, and processed 

simultaneously. (International Computers Limited, 1987, p5; italics original) 

The question then arises, of course, as to what controls the moment-to-moment deployment of the 

AVMs, and the answer is "a set of controlling modules" known as a Control Virtual Machine (CVM). 

Here is ICL's description of this TPMS facility ..... 

"The CVM, as its name implies, is in control of the TPMS service. Its main functions can be 

summarised as follows: 1. Control of the terminal network, including (a) connection and disconnection, 

and (b) input of messages and output of replies. 2. Formatting of replies incorporating the required 

template. 3. Routing of messages to the correct application code for processing, in the required 

priority order. 4. Control of privacy on messages according to terminal user. 5. Control of AVM 

concurrency according to the actual service requirements at any time. 6. Statistics collection. 7. 

Control of run-time changes to the service necessitated either (a) by control commands issued by the 

service controller, or (b) by failures within parts of the system; for example, failures in files or 

application code. 8. Logging of messages. 9. Control of service start-up and close-down, including 

any recovery on a restart." (International Computers Limited, 1987, p4) 

But what happens when a user wants to make an enquiry which either (a) cannot be completed within 

the three or four seconds typically allocated to a given message-pair, or else (b) produces results 

which will not fit within the dimensions of the available screen display? Well the answer is to do a 

screen-by-screen display, with each screen showing a subset of the total output. Of course, it takes 

time for the user to do whatever it is s/he wants to do with each screen-load of output, which means, 

in turn, that subtotals etc. and restart pointers such as database keys have to be safely maintained 

from one screen display to the next. This problem was solved by the use of a temporary storage 

facility known as "partial results". This is how ICL describe this facility ..... 

"In the simplest case, a transaction consists of just one message and one reply, in which case it is 

known as a single-phase transaction. However, many transactions comprise more than one 

interaction between the terminal operator and the TP service. Each of these interactions may produce 

intermediate data that is to be used in conjunction with the input to the next phase of the transaction. 

Such transactions are known as multi-phase transactions. Data produced by one phase and saved for 

use in one or more subsequent phases is known as partial results, and is stored [in a system file] 

between phases, along with other recovery data generated to enable the TP service to be restarted 

tidily after a service break." (International Computers Limited, 1987, p5; italics original) 

Key Concept - Partial Results: Partial Results is the name given to a relatively small area of Main 

Memory reserved by a TP Monitor to allow a program to pause and recommence across processing 

phases, thus providing users with an apparently continuous display across what is objectively a 

discontinuous exchange. With a multi-phase enquiry program, Partial Results would typically be used 

to "keep one's place" in the underlying data so that display n+1 could begin where display n left off, 

and with a multi-phase update program (where convention requires that file updates are only ever 

done in the concluding phase), it would be used to carry forward potential updates in short-term 

storage until committal to long-term storage was required.




and it is tempting to speculate that some form of mental partial results might be involved. We 

consider this issue more fully in Part 7. >> 

Two further useful concepts from the world of transaction processing are those of the "success unit" 

and the "rollback unfinished" ..... 

Key Concepts - "Success Units" and "Rollback": A processing success unit is a succession of 

referentially related file or database update operations which - because in some way they belong 

together - cannot sensibly be interrupted by a system failure. For example, if you want to book a 

flight and the system fails after having taken your name and address, but before having taken your 

destination, then those partial updates should be forcibly discarded as soon as the system has been 

recovered, and the transaction begun again in its entirety. What the system does, therefore, is to set 

an "unfinished indicator" immediately before the first partial update, and unset it only after full and 

satisfactory completion. In the event of processing failure during the updates, any updates coded as 

"unfinished" in this way can then be "rolled back", that is to say, reversed out. This form of "rollback 

unfinished" recovery action is a way of maintaining data integrity in an imperfect world. It recognises 

the fact that all systems are bound eventually to fail, and that when they do they may be part-way 

through a number of logically related file updates.




from the CDC 6600, but brought in pipelining with four sets of instruction buffers, and introduced 

"vector processing" ..... 

Key Concept - "Vector Processing": So far as the computer industry is concerned, a "vector" is an 

ordered list in memory, that is to say, one of the data arrays we described in Part 4 (Section 2.3). It 

has a starting address, a number of elements, and a constant "stride" (ie. the address increment for 

each successive element). Once created, vectors can be used to speed up the processing of large 

arrays whenever an instruction needs to be carried out on every element. This calls for a specially 

designed CPU, complete with "vector registers" and an upgraded pipeline. It also requires careful 

software design to play to the strengths of the hardware, specifically because vectoring can only be 

done from the innermost loop of a DO loop (Chiang, 2003 online). The pay-off comes in reductions of 

up to 90% in cycles per element. For detailed worked examples, see the Queen's University Belfast 

webpage. 

Cray died in a road traffic accident in September 1996 [tribute], but his company lives on [see product 

range], and nowadays companies like IBM, Unisys, and Fujitsu always like to have something special 

at the top of their ranges. [For a review of the Cray supercomputer range, see Murray (1997), and for 

a review of the fastest machines currently in use, see Wikipedia.] 

3.5 Expert Systems, "Inference Engines", and Fifth Generation Fever 

By the late 1970s, what with home computing, fourth generation mainframes, and supercomputers, 

the world suddenly found itself with a lot of mips to play with. But what software, apart from arcade 

games, were we going to run on all this hardware? Well in one bold experiment, we were given what 

were rather grandly called "expert systems" ..... 

Key Concept - Expert Systems: "An expert system is a class of computer programs developed by 

researchers in artificial intelligence during the 1970's and applied commercially throughout the 1980's. 

In essence, they are programs made up of a set of rules that analyse information (usually supplied by 

the user of the system) about a specific class of problem, and provide an analysis or recommendation 

of the problem, and, depending on their design, a recommended course of action." (Wikipedia, 2003). 

Alternatively, "an expert system is a computing system which embodies organised knowledge 

concerning some specific area of human expertise [.....] sufficient to be able to do duty as a skilful and 

cost effective consultant" (Michie, 1979). The body of organised knowledge is known as the 

"knowledge base", and the software which interprets and applies that knowledge is known as the 

"inference engine". 

The first recognised expert system was called DENDRAL, and was developed in the period 1965 to 

1975 by a student of Herbert Simons, Edward A. Feigenbaum. DENDRAL was designed to take the 

human expert out of the day-to-day medical decision making loop, and it did this by constant recourse 

to a knowledge base of pre-loaded rules and statements. The idea was that the expert knowledge of 

professors and senior consultants would be "captured" in the first instance by interview, and, once 

codified, would be made available through the machine for use by more junior grades. 

DENDRAL inspired many imitators, including MYCIN, developed between 1972 and 1980 by a 

research team at Stanford University led by Edward Shortliffe. Here is MYCIN's conceptual 

specification ..... 





"MYCIN is an interactive program that diagnoses certain infectious diseases, prescribes antimicrobial 

therapy, and can explain its reasoning in detail. In a controlled test, its performance equalled that of 

specialists. In addition, the MYCIN program incorporated several important AI developments. MYCIN 

extended the notion that the knowledge base should be separate from the inference engine, and its 

rule-based inference engine was built on a backward-chaining, or goal-directed, control strategy. 

Since it was designed as a consultant for physicians, MYCIN was given the ability to explain both its 

line of reasoning and its knowledge. Because of the rapid pace of developments in medicine, the 

knowledge base was designed for easy augmentation. And because medical diagnosis often involves 

a degree of uncertainty, MYCIN's rules incorporated certainty factors to indicate the importance (i.e., 

likelihood and risk) of a conclusion. Although MYCIN was never used routinely by physicians, it has 

substantially influenced other AI research." 

The area was, however, dismissed as marketing hype by many, and was dogged by resistance from 

the field, where there were clearly a lot of latter-day Luddites ..... 

ASIDE: Expert systems became "all the rage" in British Telecom in the early 1980s, permeating down 

from the headquarters concept boys "on evaluation". The author can remember his colleagues being 

for the most part distinctly unimpressed. "They keep asking us why we do the things we do," they 

complained. "But we don't know. We problem-solve most of these things in real time - that's what they 

pay us for." [This is a perfect instance of what Donald Michie would later describe as "the inarticulacy 

of the expert practitioners" (Computer Weekly, 24th January 1991), and is typical of human higher 

cognition. Nor is this weakness necessarily down to poor levels of insight, because it turns out that 

many of the processes of reasoning are actually performed unconsciously - see the Velmans-Gray 

position in Section 3.12.] As a result, not even our project helpdesk got an expert system to help it out. 

Nevertheless, as reflective professionals we felt a certain amount of unease, because higher 

management clearly gave the idea a lot of credence (and it was just possible that they knew 

something we did not). So we resolved to reconsider our position every few years, and apologise if we 

were forced by the unfolding of events ever to change our minds. That was 20 years ago, and no 

apology is yet necessary - the human expert can still run rings around any machine at this sort of 

professionalism-in-practice task. This is not to say that machine expertise is impossible, merely that 

you are going to need a system the size of Cyc [see Section 3.9] to provide it. In the meantime, the 

expert systems on the market simply provide "potted" expertise for use in call centres and by clinical 

assistants. They do a decent enough job, but with every major profession in the grips of an 

information explosion, and every professional struggling to stay abreast of it, expert systems are by 

necessity always out of date. 

What expert systems did do was inspire the Japanese, and in 1980 they declared that the "fifth 

generation" of computing had arrived. The announcement was made by the Japanese Ministry of 

International Trade and Industry (MITI) as an attempt to deliver artificial intelligence based upon "large 

scale parallel processing". A major conference followed in October 1981 in Tokyo, where, in addition 

to expert systems, up-beat proposals were heard for distributed storage, high power DBMSs, and 

inference software to allow human-like knowledge-processing. It all went down rather too well, and in 

Britain, fifth generation fever inspired the creation of the Department of Trade and Industry's "Alvey 

Flagship initiative". Procter (1998/2003 online) describes ICL's involvement in Alvey during the period 

1983 to 1987, and names some of the high performance parallel machines which then followed. 

Yet the Japanese had bitten off far more than they could chew, and project after project failed to 

deliver against the earlier promises. The fifth generation initiative was therefore stood down in the late 

1980s. Scott Callon (1996, online) describes it as having been doomed to failure from the beginning, 





and as having been little more than "a public relations ploy" by MITI. Others have pointed to the overreliance 

on the PROLOG programming language, which was not up to the task. There are then two 

schools of thought about where that left things. On the one hand there are those who believe it put the 

world back in the fourth generation, and on the other there are those who believe it ushered in the 

sixth generation. Either way, a fortune awaits any cognitive scientist who can unravel the joint 

complexities of brain and mind and set the fifth generation going again. For further details, see 

Kahaner (1993/2002 online). Callon (1997) provides an interesting exposé of Japanese bureaucratic 

participation in the hype and the technical failure, if interested. The latest products in the spirit of the 

fifth generation are heavily Internet-oriented, and include "avatars" and "intelligent agents" ..... 

Key Concept - Avatars: In Hindu mythology, an avatar is an incarnation of a God (Wikipedia, 2003 

online), that is to say, a way in which God makes h/self accessible to humans. Thus the God Vishnu 

may manifest himself as a fish, a tortoise, a boar, a man-lion, etc. The word was then adopted by the 

computer industry to refer to a two-dimensional virtual person, a latter-day "talking head", complete 

with a synthetic personality to complement its synthetic voice. 

Key Concept - Intelligent Agents: An agent is a robot implemented entirely in software, and thus 

differs from an avatar in that it is able to do things off-screen, that is to say, within cyberspace itself. 

The idea arose in the early 1990s as a way of searching inadequately indexed databases such as the 

World Wide Web. You launch an agent applet (= small application) from your home terminal and it 

goes off, if necessary for days, to inspect web content site by site, looking for relevant content, but far 

more thoroughly than would be possible using the dozen or so keywords available on browsers like 

Google. 

3.6 Neural Networks, 1971 to Date 

NB: An earlier version of the material in this section appeared in Smith (1996; Chapter 6). It is 

repeated here with minor amendments and supported with hyperlinks. 

The 1969 Minsky-Papert critique [see Section 1.11] brought about a period of soul searching, and 

prompted the development of more powerful methods, which culminated in the modern "neural 

network" (NN) [glossary]. Unlike perceptrons, modern NNs typically have three layers of artificial 

neurons. Now there is an input layer, an output layer, and - sandwiched between these - an "invisible", 

or "hidden", layer. All communication between the input and output layers has to go via the invisible 

layer, giving you two sets of connection weightings to play with, instead of one. These three-layered 

NNs soon proved far more competent than the older two-layered ones. 

Now the beauty of NNs is that each electronic synapse is purpose-built to take care of its own 

weighting. The network, in other words, is free to acquire its knowledge the same way biological 

brains acquire theirs - by learning from experience. In computing terms, NNs are therefore very 

important because they need no programming. NNs are now being put to a growing variety of 

commercial applications, such as telling coin from coin in vending machines (they "recognise" the 

different bounces), checking your credit card spending pattern, and steering robots. They have also 

had a major impact on cognitive theory. Neuroscientists now see NNs as validating the traditional cell 

assembly concept: each weighted connection in an NN is simply the electronic equivalent of biology's 

variable synaptic strength. Indeed, McNaughton and Nadel (1990) rate NNs as such an important 

development of this concept that they term all such networks "Hebb-Marr networks" . Other authors 

prefer the term "matrix memory" to convey the same underlying concept. And the new science even 

has a new name - "Connectionism" [see stand-alone handout]. 





And yet, as with expert systems, even NNs were running out of steam by the end of the 1980s. As 

they were built bigger and bigger and given harder and harder problems, failures started to be 

reported. The genre had come up against a major theoretical and practical barrier. A concise and 

highly illustrative example of the problem is provided by the Medical Research Council's Dennis Norris, 

who describes how a system of three interlinked small NNs was able to solve a problem which had 

been beyond the competence of a single large one. In other words, there exist tasks for which you 

need many separate NNs; and which, moreover, you need to connect up in a very precise fashion. 

Giving you, of course, a network of neural networks, in which the connections within AND 

between each module are both vitally important. 

ASIDE: We should point out that learning by experience only takes place within the modules. The 

connections between the modules do not learn by experience. That aspect of the architecture requires 

a human designer, and attracts surprisingly little research! 

The secret, in other words, was to break the problem down into its logical components. "Instead of 

having to solve one large problem," Norris writes, "[the system then] simply had to solve three far 

smaller problems" (Norris, 1991, p295). The specific problem Norris gave his network was how, given 

any date in a century, to reply with what day of the week it was ..... 

Exercise - What Day of the Week? 

(1) Norris divided the date-day problem into three sub-problems. Can you do it in less, or 

would you prefer to do it in more? Familiarise yourself with this task. What day of the 

week was/will be ..... 

seven days ago 

ten days' time 

49 days ago 

48 days ago 

7000 days' time 

6999 days' time 

11th September 2001 

18th March 2042 

29th February 2080 

Extended Exercise - Modular Cognitive Processing 

(2) Assuming that each sub-problem stage can be dealt with by a single NN, work to the 





Yourdon diagramming format [see our e-paper on "How to Draw Cognitive Diagrams", if 

not familiar with this method], and sketch the resulting higher order network 

architecture. (In other words, state how you propose "strapping" your individual 

processors together into a complete system.) 

(3) Allocate an appropriate name to each separate processing module, and state the 

nature of the information flowing between them. 

"Going modular" in this way did the trick, and two years later Hinton, Plaut, and Shallice (1993) built a 

modular connectionist network capable of rudimentary reading out loud. And - tantalisingly - their 

network of neural networks ended up being about as granular as the transcoding model popularised 

by Ellis and Young (1988). We shall be returning to this point in Part 7. 




Shopping list [courtesy of the British Computer Society's Natural Language Translation Specialist 

Group]. 

However, it is still very easy to catch these products out, for they hate any form of linguistic or 

cognitive subtlety or complexity. Indeed, the standard advice to get the best out of the available MT 

tools is to use simple, grammatical, structures, write 20 words or so per sentence, avoid jargon, and if 

you insist on using more than one clause per sentence take care not to omit the "whos" and "thats" 

which mark the clause junctions (O'Connell, 2001/2003 online). 

3.8 Machine Chess and Problem Solving, 1971 to Date 

Once Greenblatt's MacHack system had shown that chess playing software could defeat a human 

champion [see Section 1.12], system performance gradually improved throughout the 1970s and 

1980s [timeline]. The next major milestone was the 1988 "Deep Thought" system, built at Carnegie 

Mellon University by a team of graduate students including Feng-Hsiung Hsu and Murray Campbell, 

and capable of analysing 750,000 possible moves per second (Powell, 1997/2003 online). An 

upgraded system was beaten by Gary Kasparov in 1989, but came back in 1993 to beat Judit Polgar. 

Not wishing to be outdone, IBM countered in February 1996 with "Deep Blue", developed by a team 

led by C.J. Tan and advised by US chess champion Joel Benjamin. It ran on an IBM 32-node 

RS/6000, and could evaluate a phenomenal 200 million moves per second (Apte et al, op. cit.). Yet 

even this did not stop it losing four-two to Kasparov (although it won the 1997 rematch 3.5-2.5). Apte, 

Morgenstern, and Hong (2000/2003 online) tell the Deep Blue story like this ..... 

"Perhaps the most famous of IBM's game-playing programs is Deep Blue which made headlines 

when it beat Gary Kasparov, thus becoming the first chess-playing program to defeat a reigning world 

champion. Developing a champion-class chess-playing program had long been a challenge problem 

for AI. Game-playing programs have traditionally used a combination of evaluation functions to 

determine how good a particular position is, and effective search techniques to search through a 

space of possible states. The difficulty in developing a champion-level chess-playing program lies in 

the facts that first, the state space is so large (since the branching factor or ratio, the number of states 

that can be reached from a given state of the game, is 30 - 40) and second, the sophisticated 

evaluation of chess positions can be difficult to develop and computationally expensive to perform." 

(p7) 

As for the more general world of machine problem solving, the problem of context was again rearing 

its ugly head, although this time it went by the name of "common sense" knowledge. Programs 

were now getting quite adept at following rules and implications, provided they stayed within the 

immediate problem domain. But more and more lapses of general knowledge were being reported. 

The pivotal paper here was by the father of AI himself, John McCarthy, who pointed out in McCarthy 

(1959/2003 online) that there was invariably far more to a problem than would initially meet the eye. 

There could be thousands of fragments of knowledge - some obvious, but others not so obvious - 

which might somehow prove to be relevant, and without that background general knowledge - the 

common sense - the machine simply did not know enough. In the next section, we look at attempts to 

get around the problem. 

While we are here, however, there is time to introduce the concept of "production systems", 

perhaps the best known theoretical framework for explaining real time human cognition. Here are the 

basic concepts, as taught on the Trinity College (Hartford, CT) website .... 





"A production system is a model of computation that provides pattern-directed search control using a 

set of production rules, a working memory, and a recognise-act cycle. [//] The productions are 

rules of the form C -> A, where the LHS is known as the condition and the RHS is known as the 

action. These rules are interpreted as follows: given condition, C, take action A. The action part can 

be any step in the problem solving process. The condition is the pattern that determines whether the 

rule applies or not [//] Working memory contains a description of the current state of the world in 

the problem-solving process. The description is matched against the conditions of the production rules. 

When a condition matches, its action is performed. Actions are designed to alter the contents of 

working memory. [//] The recognise-act cycle is the control structure. The patterns contained in 

working memory are matched against the conditions of the production rules, which produces a subset 

of rules known as the conflict set, whose conditions match the contents of working memory. One (or 

more) of the rules in the conflict set is selected (conflict resolution) and fired, which means its 

action is performed." 

The production system is thus an eclectic combination of the cybernetic loop [see, for example, our epaper 

on "Cybernetics" (especially Figure 2)], with the "TOTE" control cycle proposed by Miller, 

Galanter, and Pribram (1960), but extended by the concept of working memory imported from 

computer science. It has been suggested that the concept of the production rule derives originally 

from the theories of the Polish logician, Emil Post (eg. Post, 1943), but the modern theory is the work 

of Carnegie Mellon University's John R. Anderson (1947-) (eg. Anderson, 1976, 1983, 1990, 1993). 

Anderson's production system is called ACT* (pronounced "act-star"), and relies on the distinction 

between declarative, procedural, and working memory [definitions], with declarative memory being 

presumed to be "a semantic net linking propositions, images, and sequences by associations". 

Key Concept - "Production Systems" and "Production Rules": "A production system consists of a 

collection of if-then rules that together form an information-processing computer simulation model of 

some cognitive task, or range of tasks" (Young, 2003 online).




(or 'rules') designed to capture a large portion of what we normally consider consensus knowledge 

about the world. For example, Cyc knows that trees are usually indoors, that once people die they 

stop buying things, and that glasses of liquid should be carried rightside-up." [Citation] 

The system is today managed by Cycorp, Inc, of Austin, TX, who describe themselves as the world's 

leading supplier of "formalised common sense", and predict great things for the future [as do we]. For 

more about Cyc and its people, click here, or here, or here. 

There are also a number of network offerings in the Richens - Masterman - Halliday - Ceccato 

(psycho)linguistic tradition [see Section 1.9]. For example, the link from Halliday's "systems" to 

Sydney M. Lamb's "relational networks" is explicit ..... 

"A symposium at Rice University in 1984 featured among others, papers by Lamb and Halliday and 

their co-workers, and focussed on a comparison of systemic analyses with various cognitive analyses 

of a common oral text captured on video [.....] Halliday's functional work has influenced Lamb's 

theoretical work in a number of important ways, and vice-versa. Lamb's relational work notation took 

important cues from Halliday's systemic diagrams ....." (Copeland, 2000) 

Then there is the work of Surrey University's Ian J. Thompson on "layered cognitive networks". 

Thompson begins by summarising the recent history of "semantic nets", thus ..... 

"Semantic nets [various citations] are an attempt to represent the meanings of sentences by means of 

a formal network structure. Various forms of these structures are possible [citations], but typically 

objects are represented by nodes in a network, their relations by arcs between the nodes, and 

inferences involving them by production rules which manipulate the network." (Thompson, 1990/2003 

online) 

It is, however, difficult to build nets capable of loosely applying prior knowledge. After all, Thompson 

explains, we immediately recognise a four-leafed clover, despite the fact that there can be no preexisting 

node for it. He goes on to discuss how a layered net architecture might assist ..... 

"The ability to recognise new instances of a specific concept means that the concept-node cannot be 

activated by purely historic links, and means that some essential kind of rule-based operation will 

have to be built into the system. Once this is done, I argue that both the symbol and the processing 

features of traditional symbolic systems can be incorporated within connectionist networks. [//] The 

architecture proposed to handle both connectionist links and pattern-directed rules involves layers of 

distinct networks, so that the relations within a layer are given explicitly by the links of the graph, 

whereas the relations between layers have a functional or rule-based interpretation. Specific types of 

semantic contents will be proposed for the distinct layers, guided to some extent by Piagetian theories 

of development." 




And finally under this heading, we must re-introduce John F. Sowa [previously mentioned in Part 4 

(Section 4.2)], who has capitalised on his experience turning data models into databases by serving 

on the advisory panel during the drafting of the American National Standards Institute (ANSI) standard 

for "Conceptual Graph Interchange Form" (CGIF). This is an attempt to specify "the syntax and 

semantics of conceptual graphs (CGs) and the representation as machine-readable character strings 

in [CGIF]" [Source]. To conform to this standard, an IT system must be able to read in a sequential 

description of a conceptual network, use those data to establish the physical network within its own 

filestore [no mean feat, in fact, as any database programmer will confirm], and then be able to convert 

that network, duly updated if necessary, back out into a sequential description again, for onward 

transmission. Here is how he sees the network content translating 

into CGIF syntax ..... 

[Go *x] (Agnt ?x [Person: John]) (Dest ?x [City: Boston]) (Inst ?x [Bus]) 

3.10 Robotics, 1971 to Date 

When we introduced the science of robotics in Part 4 (Section 4.6), we saw how the concept of the 

robot emerged from antiquity, firstly into science fiction, then into remote controlled weapon 

technology, and then into guided missile technology and modern military robotics. Nowadays, 

however, the science is mature enough to support "pure" research as well as applied, and probably 

the single most influential figure in modern robotics is Rodney A. Brooks, Director of the MIT Artificial 

Intelligence Laboratory and Fujitsu Professor of Computer Science. Having joined MIT in 1984, his 

first headline-grabbing development was of a six-legged insect walking robot called Genghis, where 

the design problem was how to synchronise six simple limbs into one overarching system of directed 

locomotion. The solution was to strap together 57 separate processors, 48 working at reflex level 

(eight per leg!), four more working to deliver level-platform coordination, and five more (and only five) 

dedicated to "central control" (Brooks, 1993, p359). 

Brooks used this experience to draw a broader point ..... 

"This exercise in synthetic neuroethology has successfully demonstrated [that] higher-level 

behaviours (such as following people) can be integrated into a system that controls lower level 

behaviours such as leg lifting and force balancing, in a completely seamless way. There is no need to 

postulate qualitatively different sorts of structures for different levels of behaviours and no need to 

postulate unique forms of network interconnect to integrate high-level behaviours. [//] Coherent 

macro behaviours can arise from many independent micro behaviours [and] there is no need 

to postulate a central repository for sensor fusion to feed into." (Brooks, 1993, pp362-363; bold 

emphasis added) 

Other MIT projects have since focussed on different areas of biological cybernetics and/or 

cognition ..... 

Coco: Coco [picture] is a quadruped robot with "gorilla-like" proportions, and articulated arms, legs, 

neck, and eyes. It is being used for research into postural and gaze adjustment during locomotion and 

visual inspection of the world. 

Cog: Cog is an attempt to coordinate robotic eyes, head, and hands, and to use the resulting 

exploratory subsystem to discover for itself things about its world. 





Kismet: Kismet [pictures] is the robot with the highly mobile eyes and eyebrows, just like "Johnny 

Five" [picture] in the movie "Short Circuit".




"Most people have the intuition that these machines may be doing something clever, but not clever 

enough. There's also doubt that the machines are doing it the 'right way'. We, after all, are not digital 

computers. The only trouble is that those who know what kind of 'hardware' we are - the anatomists 

and physiologists, especially those who study the brain - have absolutely no idea how our mind works 

either. So our intuitive conviction that computers work the wrong way is certainly not based on any 

knowledge of what the 'right' way is. The candidate must be able to do, in the real world of objects and 

people, everything that real people can do, in a way that is indistinguishable (to a person) from the 

way real people do." (Harnad, 1991, pp43-44) 

Then there is the "Total Total Turing Test" (TTTT). This, writes Harnad, calls "for Turing 

indistinguishability right down to the neurons and molecules [but] my own guess, though, is that [the] 

TTT already narrows down the degrees of freedom sufficiently" (Ibid., p53). The TTTT was soon 

followed by Bringsjord's (1994) TTTT*, which insists on there being a structural equivalence of 

machine and human at flowchart level, and Schweitzer's (1998) "Truly Total Turing Test" (TRTTT), 

which points out weaknesses with Harnad's TTT, namely that we are being asked to make 

judgements about a species - intelligent machines - of which we have no real prior experience. 

Computers are "toy world" entities, he argues, not real world, and his proposed TRTTT therefore 

looks for long term evidence of machines accumulating achievements of their own, comparable to 

human achievements. Machines now need to invent languages and board games, Schweitzer 

suggests, not just use them. So all in all, it is perhaps fortunate that Turing himself is no longer with us, 

for, being a stutterer, he might have taken all this t-t-testing personally! [For thorough reviews of 50 

years of Turing Testing, we recommend Van Gulick (1988) and Saygin, Cicekli, and Akman (2000).] 

3.12 Machine Consciousness Revisited 

"The question of whether computers can think is like the question of whether submarines can swim." 

(Edsger Dijkstra) 

The various forms of the Turing Test are now merely part of a newer, much larger, science - 

consciousness studies. The last two decades have seen consciousness become a legitimate topic for 

scientific investigation, and so much interest has this generated that the science has recently been 

described as "the race for consciousness" (Taylor, 1999). Molecular biologists and quantum physicists 

now vie with neurologists, linguists, and cognitive psychologists for the next critical discovery, while 

philosophers alternately baffle and inspire them all. Unfortunately, all the old problems still remain. 

The issue of embodiment [see Section 1.13], for example, has grown in importance, not just because 

it poses an explanatory challenge in itself, but also [see Section 3.10] because body language 

modulates consciousness much of the time. Lakoff and Johnson's (1999) "Philosophy in the Flesh" is 

perhaps the widest read source on the subject. Here is how the authors state the problem ..... 

"Any reasoning you do using a concept requires that the neural structures of the brain carry out that 

reasoning. Accordingly, the architecture of your brain's neural networks determines what concepts 

you have and hence the kind of reasoning you can do. We have inherited from the Western 

philosophical tradition a theory of faculty psychology, in which we have a 'faculty' of reason that is 

separate from and independent of what we do with our bodies. In particular, reason is seen as 

independent of perception and bodily movement. In the Western tradition, this autonomous capacity 

of reason is regarded as what makes us essentially human, distinguishing us from all other animals. 

The evidence from cognitive science shows that classical faculty psychology is wrong. There is no 

such fully autonomous faculty of reason separate from and independent of bodily capacities such as 

perception and movement. The evidence supports, instead, an evolutionary view, in which reason 





uses and grows out of such bodily capacities. These findings [.....] are profoundly disquieting in two 

respects. First, they tell us that human reason is a form of animal reason, a reason inextricably tied to 

our bodies and the peculiarities of our brains. Second, these results tell us that our bodies, brains, and 

interactions with our environment provide the mostly unconscious basis for our everyday metaphysics, 

that is, our sense of what is real." (Lakoff and Johnson, 1999, pp16-17) 

Nowhere are the effects of embodiment more clearly to be seen, the argument then runs, than in the 

pervasiveness of embodied metaphor in everyday language ..... 

"Our subjective mental life is enormous in scope and richness. We make subjective judgements about 

such abstract things as importance, similarity, difficulty, and morality, and we have subjective 

experiences of desire, affection, intimacy, and achievement. Yet, as rich as these experiences are, 

much of the way we conceptualise them, reason about them, and visualise them comes from other 

domains of experience. These other domains are mostly sensorimotor domains [citation], as when we 

conceptualise understanding an idea (subjective experience) in terms of grasping an object 

(sensorimotor experience) and failing to understand an idea as having it go right by us or over our 

heads. The cognitive mechanism for such conceptualisations is conceptual metaphor, which allows us 

to use the physical logic of grasping to reason about understanding. [//] Metaphor allows conventional 

mental imagery from sensorimotor domains to be used for domains of subjective experience. For 

example, we may form an image of something going by us or over our heads (sensorimotor 

experience) when we fail to understand (subjective experience). A gesture tracing the path of 

something going past us or over our heads can indicate vividly a failure to understand. [//] Conceptual 

metaphor is pervasive in both thought and language. It is hard to think if a common subjective 

experience that is not conventionally conceptualised in terms of metaphor." (Ibid., p45) 

To make matters worse, new problems continue to be raised. For example, the 1990s had opened 

with a most insightful observation as to what the true sequence of language processing might be by 

the University of London's Max Velmans. Velmans (1991) began by reviewing data from the selective 

attention literature [see, for example, our e-précis of Cherry (1953)], the general thrust of which was 

(a) that there had to exist a degree of "preconscious analysis" of incoming messages, and (b) that, 

although involuntary, this nevertheless presents a considerable extra workload to the cognitive system. 

The fascinating but inevitable consequence of preconscious analysis is that we must become aware 

of what we are saying at about the same time as our listeners become aware of it! Thus ..... 

"In assessing whether the planning of what to say is conscious, it is hence instructive to examine what 

one experiences during a hesitation phrase (where we have good reason to infer such planning to be 

taking place). This simple thought experiment reveals that during a hesitation pause one might 

experience a certain sense of effort (perhaps the effort to put something in an appropriate way), but 

no more is revealed of conceptual or semantic planning in hesitation pauses that is revealed of 

syntactic planning in breathing pauses. The fact that a process demands effort does not ensure 

that it is conscious. Indeed, there is a sense in which one is only aware of what one wants to 

say after one has said it!" (Velmans, 1991, pp663-664; italics original; bold emphasis added) 

This line of argument was then taken up by Gray (1995/2003 online), who incorporated it into his 

"comparator system" theory of consciousness, thus ..... 

"..... the contents of consciousness consist of the outputs of a comparator system [refs] that has the 

general function of predicting, on a moment-by-moment basis, the next perceived state of the world, 

comparing this to the actual next perceived state of the world, and determining whether the predicted 





and actual states match or do not. The hypothesis states, therefore, that the contents of primary 

awareness consist of subjective qualities whose neural and computational equivalents have been 

processed by the comparator system, and determined by that system to be familiar or novel." 

Anatomically, Gray places this system as follows ..... 

"..... the heart of the comparator function is attributed to the subicular area [helpful diagram]. This is 

postulated (1) to receive elaborated descriptions of the perceptual world from the entorhinal cortex 

[helpful diagram], itself the recipient of input from all cortical areas; (2) to receive predictions from, and 

initiate generation of the next prediction in the Papez circuit [helpful diagram; and (3) to interface with 

motor programming systems. Second, the prefrontal cortex is allotted the role of providing the 

comparator system with information concerning the current motor program (via its projections to the 

entorhinal and cingulate cortices, the latter forming part of the Papez circuit). Third, the 

monoaminergic [useful definition] pathways which ascend from the mesencephalon to innervate the 

[septal area, entorhinal cortex, dentate gyrus, hippocampus, and subicular area] are charged with 

alerting the whole system under conditions of threat and diverting its activities to deal with the threat; 

in the absence of threat, the information-processing activities of the system can be put to other, 

nonemotional purposes ....." 

Of course, the fact that consciousness studies is still a comparatively young science, means that 

articles are still debating how we are actually going to recognise machine consciousness when we 

eventually see it. For example, Aleksander and Dunmall (2003) have recently proposed a number of 

tests for "minimal consciousness". They define "being conscious" as follows ..... 

"Being conscious is defined by 'having a private sense: of an "out there" world, of a self, of 

contemplative planning and of the determination of whether, when and how to act'." (Aleksander and 

Dunmall, 2003, p8) 

Aleksander and Dunmall then identify three basic types of test, namely behavioural, introspective, and 

"tests based on a knowledge of mechanism and function" (p9). The first type can be immediately 

discounted, they argue, because the behaviours of conscious and non-conscious systems are often 

identical. Nor are introspective data any safer, because they lack third party objectivity. The real 

question, therefore, "is what mechanism does the conscious agent need to possess for it to 

have a sensation of its own presence" (p9). They then propose five axioms, as follows (where A is 

"an agent in a sensorily-accessible world S") ..... 

"Axiom 1 (Depiction): A has perceptual states that depict parts of S. 

Axiom 2 (Imagination): A has internal imaginational states that recall parts of S or fabricate S-like 

sensations. 

Axiom 3 (Attention): A is capable of selecting which parts of S to depict or what to imagine. 

Axiom 4 (Planning): A has means of control over imaginational state sequences to plan actions. 

Axiom 5 (Emotion): A has additional affective states that evaluate planned actions and determine the 

ensuing action." (op. cit., pp9-10) 





The authors then use these five axioms to derive specific hypotheses, and plead for close cooperation 

between neuroscience and computer science, for the simple reason that "hypotheses in neurology 

can be tested by computation" (p17). 

In another recent paper, Cotterill (2003) tells us about "CyberChild", a detailed simulation of the neural 

systems involved in some of the most basic biological systems of the human infant, namely voice 

activation, limb activation, stomach state, and bladder control. Critically, "the simulated child has its 

own drives" (p33), so that the system can be left to its own devices in deciding when to initiate this or 

that behaviour. Its creators thus become observers of system behaviour, in the same way that the 

ethologists made a hard science out of observing animal behaviour. As to the all-critical underlying 

mechanisms, Cotterill has argued in a number of papers since 1995 that consciousness and a 

cybernetic phenomenon known as "efference copy" are intimately related, thus ..... 

"..... we have just been emphasising the importance of sequences of muscular movements, so we 

must ask what might be involved in the appropriation of new context-specific reflexes, that is to say 

reflexes which are galvanised into action only when triggered by the correct sequence of elements in 

the environmental feedback. [Such] acquisition makes surprisingly large demands on a nervous 

system [and] is possibly seen only in mammals (though perhaps also in the birds). In fact, we will 

argue that it actually requires consciousness, which thus becomes the raison d'etre of the 

phenomenon." (Cotterill, 2001, p9; italics original, but bold added) 

"internal feedback made possible by the efference copy routes [and] the premotor and supplementary 

motor regions [of] the cerebral cortex [are] the key sources of that feedback." (p32) 

Key Concept - "Efference Copy" and "Reafference": These terms were introduced by Von Holst 

and Mittelstaedt (1950) to describe a clever way of coping with the potentially excessive feedback 

found in most biological systems. The problem is that motor activity - "efference" - does not just 

induce movement, but also affects what is picked up by the senses. As soon as you start moving, 

your proprioceptors will tell you about limb position and balance, your cutaneous receptors will tell you 

about changes in touch, pain, temperature, and pressure, your homeostatic systems will signal 

requests for blood pressure and blood glucose maintenance, and your special senses (eyes and ears) 

will detect the changing visual and auditory shape of the world. The senses, in short, are involved 

every bit as much in motor activity as are the motor pathways. What efference copy systems do, 

therefore, is subtract what you expect your senses to tell you next from what they actually tell you next. 

This gives zero if things are going to plan, but a non-zero error signal if they are not. This comparison 

is achieved by momentarily storing an image of the main motor output - the "efference copy" - and 

by then monitoring what is subsequently received back from the senses - the "reafference". The 

principal benefit, of course, comes when the two flows totally cancel each other out, because this 

leaves the higher controller free to get on with more important things. It is a cybernetic trick which 

deploys a large short term memory resource with a view to simplifying subsequent processing [to see 

these information flows shown graphically, go to our e-paper on "Cybernetics" and take a look at 

Figure 2]. Every now and then, however, the system encounters some sort of external obstacle, or 

"perturbation". This causes the reafference not to match the efference copy, and this, in turn, causes 

the higher controller to be interrupted with requests for corrective action. And because the sensors in 

an efference copy system thereby become capable of confirming for themselves that the effectors are 

working to plan, this is a highly efficient way of reducing unnecessary network traffic. Here are the 

formal definitions: "[Efference copy is] basically a copy of the motor output [and] in some way 

represents the expected pattern of sensory messages that would be produced in the absence of 

external interference with the action of the effectors. [Reafference is] the message returned to the 





nervous system, in consequence of the issue of the command." (Roberts, 1978:141.)




Other workers in this area are the Australian researchers Graeme Halford, Bill Wilson, and Steven 

Phillips, who have published a number of papers promoting the importance of relational systems to 

higher cognitive functions [see, for example, Halford, Wilson, and Phillips (2003 preprint online). 

But still the philosophical problems loom large, and we will close with the philosopher David J. 

Chalmers, then at the University of California, Santa Cruz, getting to the heart of the first-person 

problem. Chalmers reviewed progress in neuroscience and identified his now famous "hard 

problem", as follows ..... 

"Researchers use the word 'consciousness' in many different ways. To clarify the issues, we first have 

to separate the problems [and] for this purpose, I found it useful to distinguish between the 'easy 

problems' and the 'hard problem' of consciousness. [The] easy problems of consciousness include the 

following: How can a human subject discriminate sensory stimuli and react to them appropriately? 

How does the brain integrate information from many different sources and use this information to 

control behaviour? How is it that subjects can verbalise their internal states? [these questions] all 

concern the objective mechanisms of the cognitive system. Consequently, we have every reason to 

expect that continued work in cognitive psychology and neuroscience will answer them. The hard 

problem, in contrast, is the question of how physical processes in the brain give rise to subjective 

experience. This puzzle involves the inner aspect of thought and perception: the way things feel for 

the subject. When we see, for example, we experience visual sensations, such as that of vivid blue. 

Or think of the ineffable sound of a distant oboe, the agony of intense pain, the sparkle of happiness 

or the meditative quality of a moment lost in thought. All are part of what I am calling consciousness 

[and] it is these phenomena that pose the real mystery of the mind. Remarkably, subjective 

experience seems to emerge from a physical process. But we have no idea how or why this is." 

(Chalmers, 1995, pp62-64) 

4 - Still to Come 

That concludes our review of the history of computing technology. We have moved slowly and (we 

hope) surely from the groundwork inventions of the 18th and 19th centuries [see Part 1] through the 

heydey of the analog computer to the emergence of the digital alternative [see Part 2], and thence to 

the number-crunching pioneers who cracked codes, programmed air defence systems, and designed 

thermonuclear devices [see Part 3]. This then set the scene for a progressive walk through the 

concepts and inventions which have made modern computing what it is today, pausing regularly to 

highlight this or that clever use of computer memory, and searching all the time for potentially fruitful 

explanatory metaphors to assist those struggling to explain "the go" of biological information 

processing. In Part 6 we shall be looking in greater detail at the various ways computer memory can 

be used, and we do this for two products in particular, namely (a) the COBOL programming language, 

and (b) the IDMS DBMS. And finally, in Part 7 we undertake a comparative review of how well the full 

richness of the subtypes of computer memory has been incorporated into psychological theory. 

Part 6 - Memory Subtypes in Computing 

1 - Programming as "Structured" Problem Solving 

Although our narrative sequence thus far has been driven primarily by advances in computing 

hardware, our official objective throughout has been to highlight the software innovations which 

accompanied them, especially where they involved an innovative use of electronic memory. Hence 

the various "Key Concept" paragraphs dotted around Parts 1 to 5, and hence our repeated 





observation that no matter how sophisticated the machinery in question the basic software problem 

has always been the same - how to deploy the available electronic memory to best advantage, given 

the often conflicting demands of the computation and the capabilities of the processor [see, for 

example, the story of buffer storage in Part 4 (Section 1.3)]. Our task is now to collate and categorise 

all those key concepts, but before we do that we need (a) to say a few words about the nature of 

"structure" in computer programming, what it is and where it comes from, and (b) to take an 

introductory look at the COBOL programming language. 

1.1 Systems Analysis, Programming, and Programmers 

In Part 4 (Section 3.1), we explained how the roles of systems analyst and programmer call for 

significantly different sets of skills and types of mind. Metaphorically speaking, it is the analyst's job to 

tease each new problem from its lair, and only then - when it is out in the open - does it become the 

programmer's job to move in for the kill. Given the right people, the resulting object code is then 

anything between ruthlessly efficient and downright elegant; cut corners, however, and the whole 

thing soon degenerates instead into a dog's breakfast. So where exactly does the analyst's work start, 

and when should they best hand over the results of their preliminary investigations for coding? Let us 

look in a little more detail at what the two jobs involve ..... 

Scenario: Imagine that you are a rich inventor, who has just developed a new form of digital 

display. You wish to use your new technology in a bedside alarm clock, so you sketch out the 

sort of display you have decided to provide, and head off to see your IT Department. Here is 

what you have in mind ..... 

MON | SEP 08 03 | 09:23 am 

Now the point is that before any analysis or programming has been done, many of the most important 

design decisions have already been taken. In other words, you - the system's "sponsor" - have 

already grossly overspecified your requirement, which is unfortunate, because your sketched design 

suffers several potentially serious difficulties. For example ..... 

The XXX abbreviations for Day and Month are seen commonly enough, but what does the 

research base actually say? For example, might two- or four-letter alternatives be objectively more 

effective at getting the required message across? Or might the Day sit better at the right of the 

display line instead of the left? And is Day going to be set manually by the user (with all the 

associated risk of error), or is it going to be computed from the Date, using the sort of Day-Date 

algorithm detailed in Part 5 (Section 3.6)? And would it not have been an additional selling point if 

Time Zone had been included? 

The 99 format for Date is both harsh on the eye and confusing to the mind. It would probably be 

more user friendly as 99XX (that is to say, 08 would become _8th), even though this would mean 

having to fit a longer display. 

The 99 format for Year might be more user friendly as 9999 (ie. 03 would become 2003). 

Who says that two 12-hour clock sweeps are better than one 24-hour sweep? Or that one long 

display line is better than three short ones, say, set one above the other? And so on. 

You have straightjacketed your creatives, in other words ["micromanaged" is the current buzzword]. In 

fact, it would normally be the system analyst's job, taking due specialist advice, to devise a display 





which was simultaneously ergonomically sound, commercially promising, and technically feasible. 

This display would then need to be formally approved by your intellectual property, product design, 

branding, and marketing people, and only when those individual approvals were forthcoming would 

the idea be released for development. There are therefore several occasions when a vivid and 

unambiguous form of documenting the proposed processing would be needed, and preferably one 

which was equally accessible to non-technical and technical staff. One of the tools available to do this 

is the "program flowchart", and we included a tutorial on this particular method in Section 1 of our epaper 

on "How to Draw Cognitive Diagrams". Here is how the program flowchart for the present 

scenario might look ..... 

Figure 1 - The Digital Clock Display Program Flowchart: Here we see the flow of decision 

making required to advance (from left to right) the , , , , 

, , and display registers on the sort of 2x12-hour sweep digital 

clock display shown above. We have presumed that this routine will in practice only be called after 

the user has set the various display elements to desired starting values, however we have not 

shown the detailed processing necessary to do this, preferring to collapse it instead into the dotted 

pink panel [top, centre]. The dotted green panel [top, centre] is then an optional set of validating 

tests intended to ensure that the pre-set starting values have not been corrupted by the transfer of 

control. Purists often claim that this is not necessary, because "nothing can go wrong"; 

pragmatists do it anyway, for safety's sake, because accidental range errors can cause havoc to 

the meticulously structured branching and looping which is to follow [specifically, we do not want to 

increment until it gets to 60, only to be given that field already preset to 61]. There is 

then an unconditional operation [topmost yellow box], where any process-internal 

fields - that is to say, fields not already set by the prior processing - are set to their own starting 

values. The captions down the right-hand side of the diagram show the main phases of the 

processing, but annotation such as this is not normally included. 

The process then begins in earnest. The intention, of course, is that each separate display register 

should advance to its logical limit (ie. the 59th second, the 23rd hour, etc.), and then "carry" in the 

same way that each advancing nine carries in a decimal display. We have presumed that the 

entire system is driven ultimately by an electronic oscillator which pulses to a TIMER PIN precisely 

once per second. The underlying electronics need not concern us, for we may refer to the 

condition as TIMER PIN ON or TIMER PIN OFF. If we then wait on each timing pulse, we can use 

it to drive the register directly. This, of course, gives us a problem every 60 

seconds, whereupon we need to carry one to the display and set back 

to zero. And whenever we advance , we need to check for carry over to the 

, and so on for the indicator every 12 hours, the every 24 hours, the 

every 30 or so days, and the every 12 months [not all months have the same 

number of days in them, of course, and February has a leap year problem]. Note that for the hour 

after noon or midnight, the displays as , not . Finally, we need to convert each 

advancing to its equivalent day of the week, and display that answer in the field. 

However, this caption is already overlong, so we have decided to implement date-day conversion 

as a subroutine [dotted green panel, lower left], and leave it to someone else to design! 









One of the strengths of program flowcharts such as the one shown above, is that it is possible to 

generate machine code more or less directly from the diagram. For example, any sequentially 

"interpreted" programming language would simply follow the diagram down the page substituting its 

own syntax for all the operations, tests, and branches identified therein. In the table below, we show 

what the resulting code might look like, written in syntax similar to that used by Microsoft's BASIC 

programming language, an interpreted language in which each instruction is automatically selected 

sequentially from the top, unless and until that selection sequence is overridden by an explicit "GO 

TO" instruction of the form seen on Lines 20, 30, etc., whereupon control jumps instead to the 

instruction thereby specified ..... 

Key Concept - "GO TOs": A "GO TO" is a specific jumping instruction designed to allow 

programmers to override their default execution sequence. This enables them to prepare their code in 

logically discrete chunks, despite the tight physical packing of the instructions. These chunks can then 

be GO TO'd in and out of when needed. GO TOs are particularly useful when controlled by an "IF ..... 

THEN ....." condition test (eg. as shown on Line 20 below), allowing condition-specific blocks of 

instructions to be selected or ignored as appropriate. As we are about to learn in Section 1.2, GO TOs 

came under heavy criticism in the 1960s, and were largely abandoned in favour of the much more 

human-friendly "PERFORM" statement. 

Key Concept - "Iterations" and "Loops": GO TOs are also useful for simple repetitions, or 

"iterations", of blocks of code (eg. as shown in Lines 20-30 below). These are commonly known as 

"loops", because control repeatedly loops back to the beginning of the specified block. 

Instruction Comment 

NB: The GREEN instructions establish important 

processing loops, and will be discussed further in Section 

3.5 below. LT = LESS THAN; GT = GREATER THAN 

10 SECONDS = 0 INITIAL PROCESSING: This instruction sets the 

display register to zero. All other display 

registers will already have been set to their desired 

starting values by a preceding routine. 

20 IF TIMER PIN ON THEN GO TO LINE 40 AWAIT NEW SECOND: This instruction repeatedly does 

nothing, waiting for the TIMER PIN ON signal to occur. 

Since this happens precisely once a second, this is the 

mechanism by which the timer mechanism communicates 

with and actuates the display software. 

30 GO TO LINE 20 This is the "ELSE" element of Line 20, that is to say, you 

only get this far if the TIMER PIN ON test is failed. The 

GO TO LINE 20 then serves to loop back to the preceding 

instruction, so that the TIMER PIN status can be resampled. 

This will happen many thousands, if not millions, 

of times a second, depending on the speed of the 

processor. 

40 SECONDS = SECONDS + 1 NEW SECOND PROCESSING: You only get this far when 

a new second has just been signalled. This instruction 

adds 1 to whatever the count currently 





50 IF SECONDS = 60 THEN GO TO LINE 

70 

contains [we are presuming that the TIMER PIN sets itself 

back to OFF, once sampled]. 

If has now advanced to 60, then control is 

taken down to Line 70. A cautious programmer might 

replace the analyst's "equals 60" test with the more 

defensive "GT 59", because this is better able to cope with 

an accidental corruption of the value in question. 


only get this far if is in the range 1 to 59 

inclusive, and no "minutes carry" is required. This 

instruction takes us back to our TIMER PIN sampling 

process. 

70 SECONDS = 0; MINUTES = MINUTES + 

1 

80 IF MINUTES = 60 THEN GO TO LINE 

100 

NEW MINUTE PROCESSING: You only get this far when 

a new minute has just been detected. This instruction 

adds 1 to whatever the count currently 

contains, and sets the register back to zero. 

If has now advanced to 60, then control 

drops through to Line 100. Again, a cautious programmer 

might then replace the analyst's "equals 60" test with the 

more defensive "GT 59" 


only get this far if is in the range 1 to 59 

inclusive, and no "hours carry" is required. 

100 MINUTES = 0; HOURS = HOURS + 1 NEW HOUR PROCESSING: You only get this far when a 

new hour has just been detected. This instruction adds 1 

to whatever the count currently contains, and 

sets the register back to zero. 

AND SO ON 

The resulting sequence of one-offs and iterations, conditionals and compulsories, GO TOs and 

returns, routines and subroutines, is known as the "program structure" ..... 

Key Concept - A Program's "Structure": A program's "structure" determines the sequence of 

execution of each machine instruction. The default structure is simple sequential execution, but this 

can be creatively expanded by conditional branches and loops where appropriate. But beware - just 

as "ready - fire - aim" is a notably ineffective sequence of instructions to a firing party [think about it], 

so, too, does the slightest mis-sequencing of machine instructions prejudice a calculation. Indeed, it 

only takes one rogue instruction to wreak total and immediate havoc. Structuring therefore helps to 

ensure (a) that only logically related sets of instructions are executed, and (b) that they are executed 

when and only when necessary.




Useful though the program flowchart is, there exists a diagramming format which is typically a whole 

lot easier on both eye and brain. We refer to the format known as the "program structure diagram". 

Here is Figure 1's substantive logic expressed in this alternative set of conventions ..... 

Figure 2 - The Digital Clock Display Structure Diagram: Here we see exactly the same 

solution as was proposed in Figure 1, but drawn differently. The rules for this type of diagram are 

that each box represents a related cluster of instructions, but that the fine detail of those 

instructions should be excluded because it confuses both eye and mind. Instead, the box is 

given a title ["Process Control", "Initial Process", "Main Process", etc.] which succinctly states its 

contribution to the whole. Execution passes downwards and left-to-right in turn, beginning at the 

top, and the result is a processing "tree" which methodically advances the point of control 

through a given problem until it has been resolved. In so doing, some blocks of instructions are 

executed once, some a known number of times, some only under a particular condition, and 

some until a particular end state is reached. The repeating blocks are conventionally shown with 

an asterisk in their top right corner, accompanied by a concise textual caption [eg. the "UNTIL 

RESET", top centre]. The conditional blocks are linked into the tree by a dotted line, again 

captioned so as to indicate when they are to be invoked [eg. the "SECONDS = 60" condition 

which controls when the NEW MINUTE PROCESS is to run]. One of the strengths of program 

structure diagrams such as this, is that it is possible to generate high level source code (that is to 

say, code ready for compilation rather than interpretation) more or less directly from the diagram. 

We show this in the column of text to the right of the diagram, and we shall be going into greater 

detail on how this is done in Section 2.4 below. 





1.2 Structured Programming 

In Part 4 (Section 3.2), we explained how assembled and compiled programming languages emerged 

in the early 1950s to help relieve the monotony and inefficiency of entering machine code instructions 

the hard way. In fact, the idea goes back to about 1942, when the German engineer Konrad Zuse 

began devising the Plankalkül programming language to go with his Z4 computer. Zuse described his 

computer programs as Rechenplans, the German word for "plans for calculation", and believed that 

writing them was as much part of owning a computer as collating packs of Jacquard cards was part of 

owning a loom. Zuse's Plankalkül is nowadays commonly accepted as being the first complete 

programming language [for a more technical introduction, complete with detailed examples, see 

Bauer and Wössner (1972/2002 online)]. Other early languages were ..... 

Cambridge University: Maurice Wilkes' EDSAC team were hot on Zuse's heels (although they 

knew nothing of him at the time), and are usually credited with the invention of "assembly code", 

the generic name for software which translates human-readable mnemonics into machine 

instructions. Wilkes (1956) claims "an assembly subroutine" for the EDSAC in 1950, and the 

approach was fully documented a year later in Wilkes, Wheeler, and Gill's (1951) "The Preparation 

of Programs for an Electronic Digital Computer". 

Eckert-Mauchly: In July 1949, the Eckert-Mauchly Computer Corporation's John Mauchly 

authorised work on a language called Short-Code, for the BINAC and UNIVAC projects. The 

actual development work was then carried out by William F. Schmitt, Albert B. Tonik, and J.R. 

Logan. 

MIT: Jack T. Gilmore and Charles Adams wrote an assembly program for the Whirlwind, using 

mnemonic codes and allowing decimal input. The assembly process then substituted one or more 

machine instructions for the mnemonic, and turned the decimals into binary. 

Manchester University: Between 1951 and 1952, R.A. ("Tony") Brooker and Alick Glennie 

developed AUTOCODE for the Manchester Mark 1. 

However, perhaps the best remembered of all the pioneer programmers was US Navy Lieutenant 

(later Rear Admiral) Grace Murray Hopper (1906-1992). This Yale mathematician joined the US Navy 

in 1943, and - despite the fact that "she did not know the difference between a relay and a basket of 

tomatoes" (Schneider and Schneider, 1998) - was assigned to ballistics computation duties. She 

learned quickly, and the quality of her work soon took her to Howard Aiken's computer development 

unit at Harvard, where she helped prepare mathematical formulae for the Harvards Mark I and II [she 

also found the first software "bug" - story and picture]. She then moved to the Eckert-Mauchly 

Computer Corporation in 1949 to help out on the BINAC and UNIVAC projects, and began developing 

early "compiling routines" such as A-0. This ran for the first time in 1952, and is described by Sammet 

(1992/2003 online) as being "incredibly primitive by today's standards". Sammet ranks the 1955-1958 

follow-up product far more highly. This was B-0, later renamed Flow-Matic, a compiled language 

which allowed programmers to write in a simple form of English. Here is how Hopper herself 

described the achievement a few years later ..... 

"It was determined that the only common symbology used by the various installations was the English 

language and it was therefore decided to use a selected English vocabulary as a pseudo-code [note 

this word]. It was possible to isolate and define 30 verbs 





ADD CLOSE-OUT COMPARE COUNT DIVIDE EXECUTE FILL HALT IGNORE 

INPUT INSERT JUMP MOVE MULTIPLY NUMERIC-TEST OVERLAY PRINT-OUT 

READ-ITEM REPLACE REWIND SELECT SELECT-LEAST SET STOP SUBTRACT 

SWITCH TEST TRANSFER TYPE-IN WRITE-ITEM 

which as a start could make possible definition of data-processing problems in a common manner. 

Thus a sentence could be written 

(19) COMPARE INV-ON-HAND WITH INV-LIMIT; IF GREATER GO TO OPERATION 

29; IF EQUAL GO TO OPERATION 23; IF LESS GO TO OPERATION 23. 

While 30 verbs could be distinguished, no such list of nouns could be prepared. It became clear that 

each installation must be permitted to define its own nouns, thus describing its own data. It was 

determined that these definitions must include descriptions of (1) the data as a file, (2) the data as 

items or records of sets of words, and (3) the data as fields as sets of characters." (Hopper, 1959, 

pp171-172) 

[To see a specimen Flow-Matic program, click here; the distinction between file, record, and field 

remains fundamental within the industry to this day.] 

Since 1954, meanwhile, the American mathematician John Backus (1924-) had been conducting trials 

with what was to become in 1957 the first commercially successful higher order programming 

language, FORTRAN. While working on the IBM704, Backus, too, had grown concerned by how 

inefficient machine code programming actually was. Mistakes were particularly common when 

improvements were needed to pre-existing programs (a process known as "software maintenance"), 

simply because the structure of the original solution was usually far from transparent. Programmers 

routinely took days making improvements at one point in the program, only to find that they had 

inadvertently precipitated failures elsewhere. What was needed was a way to keep programs 

"intellectually manageable". 

ASIDE: This will all be depressingly familiar to readers who have ever had to maintain software [those 

who have not had this pleasure will gain some idea of the severity of the problem by now trying to 

convert the Figure 1 flowchart to offer a single 24-hour sweep rather than two 12-hour sweeps]. Nor is 

maintenance programming any easier if the original code is your own, because the act of 

programming is fundamentally an act of linguistic output and your memory for what you have written 

soon reduces to a garbled gist - presumably the result of the sort of forgetting studied by Bartlett 

(1932) [detail]. To this day, therefore, it is often quicker to write a new program than it is to repair an 

old one, even if you wrote that old one yourself. 

Even more concerned with the need to manage the process of computer programming was the muchhonoured 

Dutchman, Edsger W. Dijkstra (1930-2002), originally of Eindhoven University of 

Technology, and later of the University of Texas at Austin. His focus, too, was on the fallibility of 

human cognition. Consider ..... 

"..... our intellectual powers are rather geared to master static relations and [our] powers to visualise 

processes evolving in time are relatively poorly developed. For that reason we should do (as wise 

programmers aware of our limitations) our utmost to shorten the conceptual gap between the static 

program and the dynamic process, to make the correspondence between the program (spread out in 

text space) and the process (spread out in time) as trivial as possible." (Dijkstra, 1968, p147) 





ASIDE: Dijkstra's "conceptual gap" is precisely the same explanatory problem as was made famous 

within psychology by Lashley's (1951) paper "The problem of serial order in behaviour". Lashley was 

concerned with the technical problem of converting such things as thoughts, images, or intentions out 

of some initially timeless physical memory trace - a structural "engram" of some sort - into a timesequenced 

succession of behaviours. His explanation was - and the explanation of choice still is - that 

the motor engram is capable (a) of being located as a unit whenever its particular piece of behaviour 

is called for, and then (b) of being reactivated as a succession of subunits. This sort of motor engram 

is better known as a "motor schema", and its reactivation as "motor programming".




Language"), the project was coordinated by the US Department of Defence, and the first working 

version of the product was available in December 1959. For fuller histories and overviews of the 

COBOL programming language, click here, or here, or here. 

Nigh on half a century later, COBOL remains quantitatively the most successful programming 

language ever, thus ..... 

"Cobol has underpinned much of the financial sector's IT infrastructure since its inception in 1959, and 

it is still going strong. According to industry estimates, there are currently more than 200 billion lines of 

Cobol code used in today's business applications, with several billion lines of new application code 

added annually." (Archbell, 2000) [For a longer discussion of the reasons for this success, click here 

or here.] 

..... and, by virtue of COBOL's approximation to English, its code makes excellent pseudocode ..... 

Key Concept - "Pseudocode": Pseudocode is code which is not yet code because it is still on the 

coding sheet. It is "sketchbook" code, if you like; code which is still being considered by the relatively 

forgiving minds of the humans in the loop, and which has yet to be subjected to the full rigours of the 

compilation process. Nevertheless, it is code which approximates to English and which can 

therefore adequately convey at a glance the essence of the processing solution being 

proposed. This makes pseudocode a very powerful way of linking the conceptualising and 

problem solving capabilities of the human mind to the number crunching capabilities of the 

logic circuitry. 

COBOL's approximation to English also means that once your mind has formed some idea of an 

appropriate processing sequence (a pseudocode representation of the problem solving structure), you 

immediately have the skeleton of your source code [see the paragraph structure inset into Figure 2]. 

In the remainder of this section we present what is effectively a short course on "COBOL 

Pseudocode", and we do this because we are going to need that pseudocode in earnest to get the 

most out of the various worked examples yet to come. However, readers eager for the cognitive 

science should feel free to jump straight to Section 3, and refer back to the technicalities as and when 

necessary. 

2.1 The COBOL Program Divisions 

To create an executable COBOL program, you have to provide the compiler with three preparatory 

blocks of definitions and declarations, and one further block of logical instructions. This is done under 

the following four headings ..... 

1. Identification Division: The first few statements in a COBOL program address basic 

requirements such as the program name, its author (and author history), the date it was first 

written (and its amendment history), and the like. This commands no further explanation at this 

juncture, because it contributes nothing to the pseudocode facility. 

2. Environment Division: The next few statements serve primarily to describe the file(s) which 

is/are going to be read from, or written to, by the program. We say more on this in Section 2.2. 

3. Data Division: There then follows what can end up as a long and tortuous set of data declaration 

statements. These are the "nouns" talked about by Grace Hopper in Section 1.2 above, and 

they are vitally important to effective programming because they force you to define the 





data you wish to process at a very early stage, allocating it byte by byte (and sometimes bit 

by bit) to the physical storage resource provided in Main Memory. We say more on this in 

Section 2.3. 

4. Procedure Division: Finally, we come to the programming proper, that is to say, to the operations 

you wish to have carried out on said data, and which you therefore want the compiler to convert to 

substantive machine code. This is dealt with in Section 2.4. 

2.2 The COBOL Environment Division 

Non-programmers should refamiliarise themselves with the topics of Batch vs Online 

Processing from Part 2 (Section 1), Online Transaction Processing from Part 5 (Section 1.7), 

and Job Control Language from Part 5 (Section 1.2), before proceeding. 

Early experience soon persuaded computer programmers to distinguish carefully between 

compilation-time and run-time considerations. The most cost-effective programs were those which 

could be compiled once and then executed repeatedly on no end of different input and output data 

files. Thus a monthly accounting program might run on January's data at the beginning of February, 

on February's at the beginning of March, and so on - yes, it would cost you a lot of secondary storage 

(initially card or paper tape, but later magnetic drums, tapes, or disks) to keep your data safe (for 

many years in the case of accounting or legal data), but you would only ever need a single copy of 

the object code [at least until the need for routine repairs or enhancements intervened]. 

This arrangement was managed by having one set of filenames reserved for use by the operating 

system in its day-to-day management of the physical filestore, and a different, much simpler, set of 

filenames for use by the programmer. The former were called the "physical filenames", because 

they referred to data which actually existed somewhere on tangible storage media, and the latter were 

called the "logical filenames" because they only ever had to make sense to the person actively 

doing the problem solving. All that then remained to do at run-time was to "assign" each of the file(s) 

containing the specific data you wanted to process to the "selected" logical filenames by which they 

would be known for the duration of that processing. 

ASIDE: By definition, both input files and output files being "extended" (that is to say, added to rather 

than being created from scratch) are pre-existing files, and are accordingly already known by name to 

the operating system. Any appropriately structured file can therefore be assigned by its external 

filename to the simpler local filename. Less obviously, empty output files are also pre-existing files, 

being typically created by the job pack immediately before execution of the program which is to write 

to them. In fact, it was the need to keep re-creating and re-assigning your data files each time a 

program was to run which drove the development of the Job Control Languages described in Part 5 

(Section 1.2). 

Turning now to COBOL, this sort of run-time "binding" is controlled by the Input-Output Section, File- 

Control Subsection, and the basic syntax is . 





2.3 The COBOL Data Division 

Early experience also persuaded programmers of the need to deploy their computer's available Main 

Memory with the utmost forethought and precision. In COBOL, this is done in the "Data Division", 

the third of the four program divisions. The key facility under this heading is the "Picture Clause" ..... 

Key Concept - The "Picture Clause": A COBOL Picture Clause is a specific allocation of a number 

of bytes of Main Memory to a particular type of data, under one or more unique names, and optionally 

pre-set to a required value. It is the mechanism by which the programmer controls the initial 

build of the Record and Data Areas, and was presented to CODASYL by Bob Bemer, who had 

developed the idea on the 1957 IBM COMTRAN language. Data arrays can be set up using an 

OCCURS N TIMES extension to the basic clause, and the optional field pre-setting is done using a 

VALUE IS "....." extension [various examples below]. 

The following data types are recognised by COBOL ..... 

PIC A: The PIC A data type allocates a specified number of bytes to "alphabetical" characters, that 

is to say, to the 26 letters of the alphabet, plus space, plus the commonest punctuation marks, on a 

one-byte-per-character basis. The number of bytes to be allocated can be determined either by the 

number of As stated [so PIC AAA will allocate a three-byte field] OR by bracketing that requirement 

numerically [so PIC A(16) will allocate a 16-byte field]. Data in a PIC A field is automatically left 

justified during storage and display [so PIC A(16) VALUE IS "HI THERE" will allocate a 16-byte field 

containing "HI_THERE________"]. 

PIC X: The PIC X data type allocates a specified number of bytes to "alphanumeric" characters, that 

is to say, to the 26 letters of the alphabet, the ten numerals, plus space, plus the remainder of the 

available character set, on a one-byte-per-character basis. Again, the number of bytes to be allocated 

is determined by the number of Xs stated [so PIC XXX will allocate a three-byte field and PIC X(16) 

will allocate a 16-byte field]. Data in a PIC X field is also automatically left justified during storage and 

display. 

PIC 9 DISPLAY: The PIC 9 DISPLAY data type allocates a specified number of bytes to "decimal 

numeric" characters, that is to say, the ten decimal numerals on a one-byte-per-digit basis. It also 

allows declaration of the decimal point, using an inset "V" (although no decimal point is stored as 

such). Thus PIC 999V99 will allocate a five byte field, in which the two lowest order digits are 

processed as decimal fractions. This form of representation is intended for human consumption: it is 

non-binary, and so should not be used for calculation purposes. Data in a PIC 9 DISPLAY field is 

automatically right justified during storage and display. 

PIC 9 COMPUTATIONAL: The PIC 9 COMPUTATIONAL data type allocates an appropriate number 

of bytes to "binary numeric" data. 

ASIDE: A single 8-bit byte can store the binary number 11111111 (decimal 255), although if you want 

signed fields this will effectively steal the highest order bit, reducing the limit to 127. Two bytes can 

cope with 1111111111111111 (decimal 65535; 32767 if signed), and so on. The inset on floating point 

arithmetic in Part 4 (Section 1.3) will give some idea how this resource is used. 

There are a number of subtypes to the PIC 9 COMPUTATIONAL declaration, but these need not 

concern us at the pseudocode stage. Data in a PIC 9 COMPUTATIONAL field cannot be directly 

displayed because it is in binary [not entirely true - it can be displayed, but it screens as gibberish in 





the same way that your word processor can quite happily open, but then make no sense of, a digital 

photograph]. If numerical display is needed, then the binary data needs to be moved to a suitable 

DISPLAY field beforehand. 




05 IP-FAMILY-NAME PIC X(20). 

03 IP-CUSTOMER-DETAILS PIC X(52). 

The second block of data declarations is called the "Working-Storage Section" ..... 

The Working-Storage Section: In this section, the programmer's scratchpad storage 

requirements are defined down to field level. This allows the compiler to earmark Main Memory 

as scratchpad memory, thus allowing programmers to manipulate each and any intended 

fragment of their data by name. Typical working storage applications are for constants, counts, 

tabular data arrays, loop control, and the dissection and manipulation of fragments of input or 

output data, and these are further discussed in Section 3.3. Note how the field name prefix is 

now WS- instead of IP-, in an attempt to make the naming scheme more programmer-friendly. 

Note also how the IP-CUSTOMER-DETAILS field has now been "opened up" into the two 

separate subfields of WS-CUSTOMER-DETAILS. The motivation for this is that there is no point 

naming something until it is needed, and on this occasion the presumption would therefore be 

that WS-CUSTOMER-PIN is going to needed in this program, but that the field named WS-NOT- 

NEEDED-IN-THIS-PROGRAM would contain data inserted by, and of relevance to, other 

programs, but not this one. 

WORKING-STORAGE SECTION. 

01 WS-CONSTANTS. 

03 WS-CONSTANT-TEXTS. 

05 WS-DUMP-AID PIC A(27) VALUE IS " WORKING-STORAGE 

STARTS HERE". 

05 WS-ABORT-TEXT. 

07 WS-ABORT-TEXT-HEADER PIC A(20) VALUE 

IS "ABORT WITH ERROR NO:". 

07 WS-ABORT-TEXT-NUMBER PIC 9(5). 

01 WS-COUNTS. 

03 WS-RECORDS-READ PIC 9(3) VALUE IS ZERO. 

03 WS-RECORDS-WRITTEN PIC 9(3) VALUE IS ZERO. 

01 WS-ARRAYS. 

03 WS-MONTHS PIC X(3) OCCURS 12 TIMES. 

03 WS-DAYS PIC X(3) OCCURS 7 TIMES. 

01 WS-LOOPS. 

03 WS-UNTIL PIC 9(3) COMP. 

01 WS-CUSTOMER-RECORD. 

03 WS-RECORD-TYPE PIC 9(2). 

03 WS-CUSTOMER-NAME PIC X(26). 

03 WS-CUSTOMER-DETAILS. 

05 WS-CUSTOMER-PIN PIC 9(4). 

05 WS-NOT-NEEDED-IN-THIS-PROGRAM PIC X(48). 

Note how the field naming in both the File Section and the Working-Storage Section is hierarchical, 

with the Picture Clause added only at the lowest level. This hierarchical structuring is important, 

because it allows categorical as well as atomic reference to your data. In fact, nearly 100 





separate hierarchical levels are supported, although normally only the first half dozen are ever used. 

The rule is that MOVEs will be executed at and below the specified hierarchical level. Thus if you 

, this is a Level 01 move [see the 

original declaration lines above], and so every one of the 80 constituent bytes is moved ..... 

ASIDE: We have arranged for the receiving field on this occasion to be exactly the right size. Had it 

been larger, the leftmost 80 bytes of the receiving field would have been overwritten (and the 

remainder set to spaces), and had it been smaller, the rightmost end of the incoming field would have 

been "truncated" (ie. snipped off and lost). Carelessness in field sizing is a major source of bugs 

early in program development. 

..... however, if you then follow this with , then only the 20 

bytes specifically referred to by this name are affected. It is even possible to move bits around within 

the bytes, although the mechanisms by which this is achieved need not concern us at the pseudocode 

stage. In other words, no matter how big your Main Memory, the programmer can retrieve, 

examine, and if necessary amend every single bit of it, by name, or by any of its higher order 

names. 

The third block of data declarations is called the "Screen Section", and is needed when preformatted 

input/output screens are required. Whenever this happens, the "templates" - that is to say, the 

invariable portions thereof - also need to be specified in advance. This section will therefore contain 

as many screen definitions as the system specification has asked for, each with lots of Picture 

Clauses with pre-set VALUE IS elements. 

The fourth block of data declarations is called the "Linkage Section", and is needed when a call-andreturn 

relationship exists between two or more programs. Whenever this happens, the calling program 

will usually need to pass data across to the called program when making the call, and receive back 

some results of the computation upon the return of control. This exchange of data is done by linking 

the object modules in such a way that they have a number of data fields in common. These commonly 

addressable data fields need to be separately identified to the compiler and this is done in the Linkage 

Section provided. 

For a simple example of what a Data Division might look on paper, click here, for good examples of 

Working-Storage Picture Clauses see Colin Wheeler's "COBOL Bible", and for a full tutorial, we 

recommend Michael Coughlan's pages [menu] at the University of Limerick [check it out]. 

2.4 The COBOL Procedure Division 

With the environmental information in place and the necessary data declarations made, attention can 

now turn to the logic of the program. In COBOL this is traditionally expressed as a sequence of 

paragraphs of detailed source code, which are "performed" in the sequence already decided upon at 

the analysis and design stage. The key facility under this heading is the "PERFORM" statement ..... 

Key Concept - The COBOL "PERFORM" Statement: The COBOL PERFORM statement is the 

solution to Dijkstra's complaint about GO TOs [see Section 1.1]. What it does is to allow one or more 

instructions to be declared as a paragraph, named as a paragraph, and thereafter executed as often 

as necessary as a unit. The paragraph, in other words, is "performed" when called by name, and, 

when completed, passes control back to the calling paragraph. What happens, of course, is that the 

compiler simply replaces each PERFORM with two GO TOs, one at the top of the paragraph and 





another at the bottom, on a call-and-return basis. However, it does this with 100% accuracy, whereas 

human GO TO programmers get mightily confused mightily quickly. 

Paragraphs can also be "nested", that is to say, you can PERFORM a paragraph which itself 

PERFORMs one or more lesser paragraphs, which themselves PERFORM still other paragraphs, and 

so on. This is what gave Figure 2 its layered depth, and does much to turn a two-dimensionality in 

space into what will ultimately be executed as a linearity in time - Section 1's Lashley-Dijkstra 

problem, of course. 

Armed with this vocabulary, it remains only to control how often, and in what precise circumstances, 

each PERFORM is to be PERFORMed. Now the concepts of "iterations", "conditionals", and "loop 

control" were introduced in the worked example in Section 1.1 above, and examples of them were 

given in Section 2.4. In fact the GO TOs highlighted therein created a nest of such loops - the 

innermost loop repeatedly checks the TIMER PIN while the value is OFF, the next loop repeatedly 

adds while building up towards a complete MINUTE, the next loops MINUTES waiting 

on a complete HOUR, and so on. However, there are a number of minor variations to loop control, as 

follows ..... 

Key Concept - DO WHILE and DO UNTIL Loops: The approach to loop control used by BASIC-style 

interpreters supports two forms of DO loop. In the DO WHILE form, a test expression is stated and the 

body of the loop is repeated until that test is no longer satisfied [for example, ]. The DO UNTIL form is similar, save that the test is now for an end condition to be passed 

rather than failed [for example, ] (Ware, 2002/2003 online). 

Key Concept - FOR NEXT Loops: Another BASIC-style variant of loop control takes the form . This 

repeats the nested instructions, incrementing {counter} by STEP (or default 1 if omitted) each time. 

Key Concept - The PERFORM N TIMES Loop: This is probably the simplest COBOL repetition, and 

repeats the specified paragraph the specified number of times. The N can either be a pre-set integer 

[as in ], or else a variable [as in ]. 

Key Concept - The PERFORM UNTIL Loop: This is the COBOL equivalent of the DO UNTIL loop 

described above, and is commonly used for processing each record from a file [as in ]. 

Key Concept - The PERFORM VARYING Loop: This is the COBOL equivalent of the FOR NEXT 

loop described above, and takes the form . It is often used to loop a process through all the 

entries in a data array indexed by [see under Data Arrays and Indexing in Section 3.3 

below]. 

Once the skeletal PERFORM structure has been established, it remains only to "flesh out" each 

paragraph with the logically appropriate detailed instructions. These are selected from a fairly short 

vocabulary, in which the following instructions are the most common ..... 

ACCEPT and DISPLAY: These two instructions take data from, or send it to, named terminal devices 

[examples]. They are often used in pairs interactively in the form




name} NOW:"> followed by an , thus prompting the user to enter 

the specified data item for storage in the specified field. 

OPEN and CLOSE: The OPEN instruction prepares the specified file (as previously identified in the 

SELECT-ASSIGN and FD statements) for active use [the downside of which is that the operating 

system now has to manage the filestore very carefully to avoid accidentally corrupting the data, 

especially on multi-user systems], and the CLOSE instruction signals the operating system that those 

files are finished with and can be re-catalogued (complete with new file size, placement, and lastamended 

date) and de-protected. 

READ and WRITE: These two instructions read/write records in/out of their allocated record areas, 

that is to say, they momentarily open the data bus for communication between the Record Area and 

the device concerned [more on this in Section 3.2 below]. Attempts to READ beyond the last record in 

a file generate an AT END Boolean, which can be tested as part of primary loop control [more on this 

in Section 3.3 below]. 

MOVE: This instruction takes the form , and copies the 

contents of the first fieldname to the space available in the second. It is commonly the most heavily 

used instruction of them all. 

ADD: These instructions take the form , and execute the named 

arithmetical operation on the given operand string. 

SUBTRACT: These instructions take the form , and 

execute the specified arithmetical operation on the given operand string. 

MULTIPLY: These instructions take the form , and execute 

the specified arithmetical operation on the given operand string. 

DIVIDE: These instructions take the form , and execute the 

specified arithmetical operation on the given operand string. 

COMPUTE: This instruction takes the form . 

2.5 The Story So Far 

So to recap, a single sheet of structure diagram [as per Figure 2 body] can be used to give a static 

visuospatial representation of what will ultimately be a time-sequenced solution to our original real 

world problem. This visuospatial structure can then be "peeled off" the two-dimensional sheet from top 

left to bottom right, and mapped onto a nested linear paragraph structure [as per Figure 2 indent], 

which can then be fleshed out with any missing detail before being compiled into raw machine code. 

The machine code then executes one instruction at a time [save as pipelined or parallel processed] 

under the FETCH-and-EXECUTE logic of the CPU provided. Moreover, since the systems analyst's 

original solution was effectively an exercise of human "right-hemisphere" problem solving skill, we 

may look upon structured programming as opening up a direct channel of communication and 





opportunity between the full creative richness of the human mind and the logic gates of the CPU; 

between human ingenuity in all its glory, and binary in its rasping simplicity. The translation is 

achieved in discrete steps, of course, but if you had the time and inclination every single one of those 

steps could nonetheless be traced with total accuracy. The real world can thus routinely - and with 

full audit trail - be reduced to binary and the Explanatory Gap can be duly closed. 

Reductionism, in other words, suddenly becomes a viable option! 

ASIDE - THE EXPLANATORY GAP: The Explanatory Gap is the long-standing philosophical gulf 

between explanations of human behaviour [nowadays especially consciousness] couched in 

sociocultural and/or psychological language, and explanations based on the underlying physiological, 

chemical, and even sub-atomic processes. It is the problem of explaining the macroscopic in terms of 

the microscopic, and it has yet to be adequately resolved. In Smith (1998b), we blamed the 

explanatory gap on the fact that "we are notoriously bad at seeing how wholes can ever become 

greater than the sums of their parts" (p215): we know that wholes routinely are greater than the sums 

of their parts, of course, but our explanations at one level do not map readily onto explanations at 

another. Yet compilers do precisely this, routinely reducing sourcecode wholes into object code parts. 

The Explanatory Gap, if anything, is a compiler gap. 

For a full Procedure Division tutorial, we recommend Michael Coughlan's pages at the University of 

Limerick. 

3 - The Subtypes of Volatile Electronic Memory 

In this section, we take the various types of computer STM previously identified, remind ourselves of 

where they sit physically within the hardware, and then describe how they work in practice. We do this 

under nine organising headings - the "memory subtypes" of our title - as follows. The Remarks 

column identifies the major areas of similarity between biological and non-biological systems, and 

may, on occasions, come close to stating the obvious ..... 

STM Subtype Section Remarks 

STM in the FETCH-and- 

EXECUTE Cycle 

STM for Input and Output 

Purposes 

3.1 Science is currently unable to explain the ins-and-outs 

of biological data processing at the level of the 

underlying electronics. Certainly, it EXECUTEs 

instructions of some sort, but whether this requires 

activation in situ or a physical FETCH is not known. 

3.2 The brain spends most of its time and effort converting 

input (sensory) data into output data (behaviour). 

However ..... 

STM for Scratchpad Purposes 3.3 ..... less than one part in ten million of the input stream 

is ever stored long term (Frank, 1963). The rest, of 

necessity, must either be reduced in flight or else 

scratch-padded momentarily, and then discarded. 

STM for Multiprogramming 

Purposes 

3.4 The brain is in some important respects a 

Multiprogramming system. 

STM for Transaction 3.5 The brain is in some important respects a Transaction 





Processing Applications Processing system. 

STM for Database Applications 3.6 The brain is in some important respects a Database 

system. 

STM for Distributed Processing 

Purposes 

STM for Real-Time Processing 

Purposes 

STM for "Object-Oriented" 

Processing Purposes 

3.7 The brain is in some important respects a Distributed 

Processing system. 

3.8 The brain is in some important respects a Real-Time 

Processing system. 

3.9 The brain is in some important respects an Object- 

Oriented system. 

So let us begin by donkey-tailing these various memory subtypes onto our standard hardware 

diagram. For simplicity's sake, we shall follow the context provided by the layout of the typical Eckertvon 

Neumann machine - the computer as it stood in 1950 - and simply add in whatever needs adding 

in; there would be little advantage to be gained by overlaying a more recent architecture because the 

principles remain the same. Here, then, is the last of the diagrams used in Part 3 (Section 6 subfile), 

with additional highlighting to show the distribution of short- and long-term memory resources ..... 

Figure 3 - STM and LTM Resources in a Typical General Purpose Computer: Here is 

the basic modular architecture of a typical computer [reminder], rendered feint, and then 

overlain with additional detail. We have made the operating system's share of Main Memory 

more visible [yellow underpanel, top left], allowed for optional extension software packages 

[mauve underpanel, top right], and then surrounded the whole thing with starred captions 

showing where the main subtypes of electronic STM may be found. The system supervisor 

resources specifically identified are the Stack Handler, the Paging Tables, the Interrupt 

Handler, Block Buffering, and the Semaphores. The two most important optional extensions 

to the system software are the DBMS (and within that the Currency Tables), and the TP 

Monitor (and within that the Partial Results). There are also two bold blue captions, one to 

show where the main body of LTM is located [bottom left], and the other to show the LTM 

read-only memory used to hold the microcode [left, as an adjunct to the Control Unit]. Note 

how peripheral these LTM resources are to the all-important FETCH-and-EXECUTE and 

INPUT-OUTPUT cycles of STM processing. In other words, for computers as well as 

brains, if you want to know the "go" of a given system, then there is no better learning 

experience than to accompany STM on its journey through that system, carefully 

observing (a) where it comes from in the first instance, (b) how it circulates within the 

hardware, (c) how it interacts with and is transformed by the logic gates, and (d) 

where it then ends up. 





3.1 STM in the FETCH-and-EXECUTE Cycle 

The key concepts under this heading are Control Registers and the FETCH-and-EXECUTE Cycle. 

We first introduced registers in Part 1 (Section 1) as the name given to the "tens carry" cogwheel 

displays used on the 17th century mechanical calculators, and we then discussed their 

metamorphosis into electronic components in Part 3 (Section 2), where we defined them in general 

terms as storage locations closely and permanently attached to the CPU. Two registers in particular 

were highlighted in our e-paper on "The Eckert-von Neumann Machine". These were the Instruction 

Register and the Program Counter, and what these combined mechanisms do is drive the basic 

FETCH-and-EXECUTE computing cycle. The former contains the instruction currently being 

processed, and the latter contains the address of the next program instruction to be obeyed. Both 

these STM elements require updating after every instruction, and should either of them fail the 

computational integrity of the entire system is immediately and fatally compromised. 





We also need to consider the machine's instruction queuing philosophy. As explained in Part 5 

(Section 1.4), most modern processors are designed to operate according to the stack principle. This 

means that a single queue of cleverly intermixed op codes and operands is maintained at the Control 

Unit, and then acted upon as time permits. This has the advantage that as you develop more and 

more powerful instructions you merely add to the length of the stack, not to the complexity of the 

electronics [costing you only processing time, not cash]. It also makes it easier to introduce 

"recursion" [literally "re-running"] into your programming toolbox, and that brings even greater 

savings. Here are some definitions of this important, but unfortunately quite obscure, concept ..... 

"In mathematics, recursion is the name given to the technique of defining a function or process in 

terms of itself" (Barron, 1968, p1). 

ASIDE: Never one to ignore a strong historical link, we must mention that our old friend, Christopher 

Strachey [see Part 4 (Section 2.3)], also played a part in the development of recursive programming, 

via a 1966 paper co-authored with the same David Barron mentioned above. See Gordon (2000/2003 

online) for more on this link. 

"[Recursion is] a technique of describing something partly in terms of itself" (Rohl, 1984, p1). 

Recursion allows you to simplify programming by dividing a problem into "subproblems of the same 

type" (Wikipedia, 2003 online). 

Barron (1968) suggests that the best known example of mathematical recursion is the factorial 

expression. Thus we know that ..... 

Factorial 6 = 6 x 5 x 4 x 3 x 2 x 1 

which is the same thing as ..... 

6 (Factorial 5) 

and working to this pattern we may recursively define factorial n by using the factorial function on both 

sides of the equation, as follows ..... 

Factorial n = n (Factorial (n-1)) 

And of course one of the few true pleasures of programming is when the problem solving algorithm at 

the heart of your program reduces to an elegant one-liner such as this. 

When implemented on a computer, recursion requires that a single block of instructions is there to be 

repeated; and in this respect it is superficially similar to the PERFORM UNTILs and DO WHILEs of 

conventionally structured code. Recursion is more than a simple program loop, however, because 

each pass through the loop is in some way progressive, taking you one step closer to a given logical 

objective. Simple looping is mere "iteration" (= repetition), and merely achieves another record 

written or another second counted off on your clock display. Recursion is "similar to a loop because it 

repeats the same code, but it requires passing in the looping variable and being more careful" (Alegre, 

2003 online), and it is the requirement to nest the looping variable in this way which makes stackbased 

systems the routine choice for recursive programming. This is because the recursions can 

simply be stored in the stack until the innermost condition is met, whereupon the whole function can 





be resolved using the characteristic last-in-first-out quality of the stack. Here is how Barron (1968) 

explains the item handling sequence ..... 

"..... for each call of the subroutine there must be a different set of working registers and a different 

place to store the return address; on entry to the subroutine a new set of working registers must be 

allocated, and on exit, before transferring control to the return address, the environment (working 

registers, etc.) must be restored to the status existing at the call of the subroutine. These operations 

are carried out automatically in 'built in' recursive systems, but [otherwise] have to be explicitly 

programmed." (Barron, 1968, p34) 

"Almost all recursive programming systems are based on the idea of the stack (sometimes called a 

push-down store or nesting store). [.....] A push-down store is a store that operates on the last-in-firstout 

principle. Whenever an item is placed in such a store, we speak of it going to the head of the store, 

pushing down all the items already there. Whenever an item is taken from the store it is taken from 

the head, and all the other items pop up. Thus it is always the item most recently added which is 

removed first. The term stack is usually applied to such a store when, in addition to accessing the item 

at the top, items in the interior may be consulted. More precisely, a stack is a store which works on 

the push-down principle as far as adding or removing items is concerned, and in which items not at 

the head can be accessed by quoting their position relative to one of a small number of pointers." 

(Barron, 1968, p35; italics original) 

In fact, it is the stack pointer which really makes the stack system so easy to use, because all it ever 

does is point to the next free cell in the stack. Everything else can then be calculated relative to this. 

Key Concept - The Stack Pointer: The stack pointer is a CPU register containing the address, S, of 

the first unused slot in the run of volatile memory declared as the stack. It thus serves to identify the 

notional head of the stack (which, by definition, will always be at storage position S-1), and it also 

allows the stack length to be managed logically rather than physically, that is to say, the contents of 

storage register position S before a push-down are totally irrelevant, because they are about to be 

overwritten. As the head of the stack is processed, its contents are left in situ, safe in the knowledge 

that they can do no harm as long as the stack pointer has been simultaneously decremented by one. 

Other applications of recursive techniques are ..... 

(1) Algebraic Analysis: Following the example of factorial n above, mathematicians regularly reduce 

long algebraic expressions to recursive functions. 

(2) Elegant Programming: Similarly, programmers have a repertoire of recursive functions for such 

otherwise complex tasks as sorting. 

(3) Syntax Analysis: Linguists with a computational bent also use recursive approaches to the 

parsing of sentence structures. 

(4) Machine Problem-Solving: As already explained in Part 4 (Section 4.7), Newell, Shaw, and 

Simon's (1957) General Problem Solver (GPS) was driven by a recursive algorithm capable of scoring 

and re-scoring an internally maintained stack of possible problem solving options in its search for the 

best. In other words, recursive techniques are not just there for master-mathematicians to show how 

clever they are. They have also been used in artificial intelligence. Barron, for example, summarises 

Newell, Shaw, and Simon's General Problem Solver as follows ..... 





"[GPS] endeavours to discover a suitable attack on a problem by trying a variety of methods and 

assessing their relative success. Broadly, given a goal to be achieved, GPS breaks it down into 

subgoals and attempts first to achieve these. The process of achieving a subgoal may involve further 

subdivision, and so we see the essentially recursive nature of the system - the subprocesses are 

identical with the main process of which they form part." (Barron, 1968, p32; italics original; bold 

emphasis added) 

To summarise, recursive programming buys you short sweet algorithms at the (low) combined cost of 

(a) making Main Memory available for the stack, (b) incorporating the necessary stack handling logic 

into the operating system, and (c) making register(s) available to the CPU to hold the stack pointer(s). 

In Part 7, we shall consider whether biological cognition uses directly or metaphorically cognate 

systems, and, if so, what neural mechanisms might be involved. 

3.2 STM for Input and Output Purposes 

The key concepts under this heading are record areas and (the various forms of) buffering, as 

introduced in Part 3 (Section 6 subfile) and Part 4 (Section 1.3) respectively. Now we have already 

seen [Section 2.3 above] how the COBOL File Section sets aside areas of Main Memory to hold one 

record for every nominated input and output file. This is where input records are stored while being 

acted upon and future output records are constructed field by field until ready to be written out to their 

destination device. However, at least two variations on the buffering principle need to be considered, 

namely "device buffering" and "block buffering" ..... 

Device Buffering: This is where data can be momentarily accumulated within a peripheral device, 

awaiting onward transmission. As previously explained, this design feature is forced upon the 

designers by the inevitable difference between storing and retrieval speed and onward transmission 

speed. 

Block Buffering: This is where a conveniently-sized "block" of contiguous input or output records is 

held as a unit within the operating system's share of Main Memory, thus allowing the operating system 

to "read ahead" and "write behind" the program's actual requirements. When the application program 

needs a record from a file, the operating system will get the block containing it, and if that block 

contains n records the next n-1 program reads can be serviced without any further physical reads. 

The program simply reads from the buffer as though it was the file, but at a fraction of the normal 

delay. Double buffering, etc., sacrifices yet more Main Memory to gain an even bigger reading ahead 

or writing behind advantage. 

Device buffering is quite commonly seen in cognitive science, in such areas as perception [eg. the 

"recognition buffer" in Sperling's (1967) model of text perception], biological motor programming [eg. 

the "motor program buffer" in Sternberg, Knoll, Monsell, and Wright's (1988) model of motor 

subprogram retrieval], and language processing [eg. the "phonological input buffer" and the two 

output buffers in Kay, Lesser, and Coltheart's (1992) PALPA transcoding model], and in Part 7 we 

shall be looking for neuroanatomical evidence for the location of the structures involved. Block 

buffering appears to lack similar appeal. 

3.3 STM for Scratchpad Purposes 

All complex data processing creates intermediate results, and therefore all systems need to provide 

somewhere to store them. The issue is easy to demonstrate ..... 





The Nature of Intermediate Results: Use the empty box below to multiply 1437 by 469 ..... 

We make the answer 673,953 and used the "traditional long multiplication" method [there are 

others - see Biggs (1994/2003 online)]. This method generated three separate vertically 

aligned subproduct lines, one for each of the significant digits in the short multiplicand, and the 

individual multiplications were supported by nine subscripted "carry digits". These three 

subproducts were then added downwards to give the final total product (generating three 

further carry digits, which we handled mentally. The point of this exercise is that every one 

of the nine subscripted carry digits, the three separate subproducts, and the three 

further carry digits generated during the final addition are discarded afterwards; and 

although they were wholly intermediate to the calculation at hand, they were far from 

negligible in terms of resources used. 

Perry (1962a,b) called this type of STM "scratch-pad memory" because it is the electronic equivalent 

of scrap paper for doing complex calculations by hand, but in fact the need for scratchpad storage had 

been there from the very beginning. For example, the store in Babbage's Analytical Engine catered 

explicitly for intermediate results, as did Atanasoff and Berry's ABC [reminder], and Zuse's Plankalkül 

allocated a specific data type "Z" for the purpose. Here, from Wilkes (1956), is perhaps the earliest 

detailed example available ..... 

Babbage's Solution to Simultaneous Equations: Babbage, it seems, kept few 

programming notes, but Wilkes (1956) tells how an Italian military engineer Luigi Federico 

Menabrea (1809-1896) met Babbage in 1840 and was fully briefed on the latter's 

programming methods. Menabrea faithfully recorded these informal tutorials, and his 

explanations of what Babbage taught him have survived. Here, from Menabrea (1842), and 

enhanced to show intermediate results in red and the final answer in green, is how the 

Analytical Engine would go about solving a simultaneous equation of the general form ..... 

ax + by = c 

a'x + b'y = c' 

The solution required 14 registers, numbered V0 to V14, the first six being set to the six 

known values a to c and a' to c'. Their use in computing the first of the unknowns, x, is shown 

in the following table. A similar set of instructions solves the same equations for y. [Menabrea 

(1842, cited in Wilkes, 1956; Table 1.1)] 

Step Operation Stored In 

1 V2 x V4 V8 

2 V5 x V1 V9 

3 V4 x V0 V10 

4 V1 x V3 V11 





5 V8 - V9 V12 

6 V10 - V11 V13 

7 V12 / V13 V14 (= x) 

Using the syntax set out in Section 2.4, the same effect would be achieved in COBOL by a 

combination of DISPLAYs and ACCEPTs to prompt the user to input variables a to c', followed by the 

appropriate sequence of MULTIPLYs, SUBTRACTs, and DIVIDEs, followed by one final DISPLAY of 

the solutions for x and y. 

However, there is a lot more to more to scratchpad storage than immediate results. Here are some of 

the most significant other uses ..... 

Constants: A constant is a data field whose contents are set once and then used repeatedly. This 

might be as a numerical operand in calculations, such as a current interest or tax rate, or pi, or any 

other algebraic constant. Alternatively, it might be as a textual element in a repeating display, for an 

example of which, see the VALUE IS element of the WS-DUMP-AID field in Section 2.3. 

Counts: A count is a numeric data field used to accumulate useful data over major processing 

phases. It is common practice, for example, to count how many records have been read from an input 

file for reconciliation purposes, a simple task requiring the declaration of a suitably sized Working- 

Storage field, initialising it to zero, and then incrementing it by one for every successful pass through 

the READ paragraph. [The "right" answer would need to have been previously stored either on a fileend 

trailer record or somewhere in the job control environment, and if the actual and the expected 

counts did NOT match, then the run would need to be aborted for investigation.] 

Loop Control: We have already seen (a) how file processing typically processes every record 

available, until the AT END condition is reached, (b) how the main process loops conditionally through 

short sequences of instructions, and (c) how recursive algorithms allow complex processes to be 

reduced to "subproblems of the same type". Working Storage assists the various looping processes 

by providing the necessary control fields and counts. Consider the field WS-LOOP in our Section 2.3 

example. 

Key Concept - "Flag" Bytes in Loop Control: A "flag" is a small Working-Storage field, usually only 

one byte long, and often set either to "Y" or "N". Flags are commonly used in loop control as the 

tests described in Section 2.4 above. 

Data Arrays and Indexing: This is also a convenient point at which to remind ourselves about "Index 

Registers". These were introduced in Part 4 (Section 2.3), where they were described as a trick for 

retrieving a single entry from a long table of entries. 

Again we must not forget that the Operating System is itself a program, and that it will therefore have 

Working-Storage resources of its own. Nor, if it comes to that, is Working-Storage the only scratchpad 

resource actually available. As explained in Part 5 (Section 1.1), the use of microcode requires 

scratchpad support from the registers directly available to the CPU. The key concept here is the 

"Accumulator Register", as introduced in our e-paper on "The General Purpose Computer" (see 

Figure 2, caption step 11). Unlike the two FETCH-and-EXECUTE registers discussed above, 





accumulators are entirely arithmetical registers, that is to say, they are used by the Arithmetic/Logic 

Unit for storing the intermediate results of complex single calculations such as DIVIDEs and 

MULTIPLYs. What we have, therefore, is an important distinction between "user scratchpad" 

resources and "system scratchpad" resources. The former is the Working-Storage resource 

controlled by the individual application programmer, and the latter is the CPU-resource controlled by 

the system programmer. 

CRITICAL DISTINCTION - GENERAL REGISTERS VS SCRATCHPAD STORAGE: The point about 

intermediate results is that some live longer than others. Some are intermediate only within the 

execution of a single complex instruction - a particular DIVIDE, or MULTIPLY, or COMPUTE 

statement, for example. These resources can be freed up immediately after that statement has been 

executed. Other results are intermediate within the broader context of the program as a whole. These 

resources cannot be freed up, for example, until a particular record has been output, or (as would be 

the case with end-to-end closing totals and reconciliations, for example) until the very last record has 

been processed. 

In Part 7, we shall (a) be exploring how the working-storage concept made a major breakthrough into 

cognitive theory as "working memory", (b) looking for evidence of biological general registers, and (c) 

considering whether biological cognition might rely on directly or metaphorically cognate systems, and, 

if so, what neural mechanisms might be involved. 

3.4 STM for Multiprogramming Purposes 

The key concepts here are multiprogramming itself, virtual memory, and the System Supervisor, 

as introduced in Part 5 (Section 1.2), and we should begin by reminding ourselves that the 

development of multiprogramming was one of computing's quantum leaps back in the late-1950s. 

Taking the Manchester University Atlas as typical of the leading edge hardware available, then its 

System Supervisor was equally typical of leading edge operating software. The critical design feature 

was the ability to conjure effectively unlimited Main Memory out of thin air, by surreptitiously paging all 

non-active Main Memory out onto drum or disc random access backing store. For the cost of the 

paging software and the page tables to keep track of where everything was, the system was suddenly 

able to support a much higher number of concurrent programs. For even greater efficiency, the 

operating system could also cope with a queue of jobs awaiting execution, and gave its console 

operators the power to "tweak" the processing workmix here and there in an ongoing attempt to match 

the overall availability of system resources against the overall demands of all the jobs in the job queue. 

The name subsequently given to this aspect of system supervision was "execution scheduling" ..... 

Key Concept - Execution Scheduling: An "execution scheduler" is a module within a 

multiprogramming operating system which manages the job queue. It submits the jobs in priority order, 

monitors their progress, resolves any contention scheduling problems, and varies how many jobs are 

allowed to be executing simultaneously. It also allows specific jobs to be "expressed" or suspended at 

will. The ICL 2900/3900 systems described in Part 5 (Section 3.3) mounted separate Job and TP 

Execution Schedulers for batch and TP, with TP normally getting the highest priority call on resources. 

In Part 7, we shall be considering whether some sort of biological paging and execution scheduling 

mechanisms might underlie our ability to "multitask" a number of cognitive objectives 

simultaneously. If so, then it may or may not turn out to be relevant that biology already has a 

tried and tested mechanism for medium-term memory sensitisation, in the form of calciummodulated 

"second messenger" neurotransmission. 





3.5 STM for Transaction Processing Applications 

The key concepts here are transaction processing itself, as introduced in Part 5 (Section 3.3), and, 

within that, partial results. The raison d'etre for the partial results facility in transaction processing is 

that it allows large applications to proceed in stages, often separated by many seconds. The physical 

requirement, however, is simplicity itself - just a small area of Main Memory under the control of the 

TP Monitor, which is written to at the end of one pass through a multiphase application, and re-read 

by the same application-user combination at the beginning of the following pass. In Part 7, we shall be 

considering whether time-extensive biological cognition resorts to some sort of partial results facility, 

and, if so, what neural mechanisms might be involved. Again, it may or may not turn out to be 

relevant that biology already has a tried and tested mechanism for medium-term memory 

sensitisation, in the form of calcium-modulated "second messenger" synaptic sensitisation. 

3.6 STM for Database Applications 

The key concept here is that of database currencies, as introduced in Part 5 (Section 3.1) (and 

explicitly located at the top of Figure 3 above). The essence of the currency concept is that the DBMS 

can instantly relocate the "current" record - that is to say, the record last accessed in a given set or of 

a given type. It does this by maintaining what is known as a "run time currency indicator" for every 

set and record type that it knows about, and every time it accesses a record it copies that record's 

database key into the appropriate "current of set" and "current of record type" currency 

indicator(s). The device comes as standard with what are known as "Codasyl" databases such as 

Computer Associates' Integrated Database Management System (IDMS), and is actually nothing 

more than a small address table held in memory and constantly updated. As to how this works in 

practice, see our e-paper on "Database Navigation and the IDMS Semantic Net". The importance of 

currency mechanisms to cognitive science lies in the fact that what they do is uncannily 

similar to what calcium-modulated synaptic sensitisation does in biological memory systems. 

We have previously argued this in Smith (1997d) and Smith (1998b), and we shall be 

microscopically exploring the issue in Part 7. 

3.7 STM for Distributed Processing Purposes 

The key concepts here are those which support intermodular communication, as introduced in our epaper 

on "The Relevance of Shannonian Communication Theory to Biological Communication" [see 

Section 5 thereof; especially Figure 7]. Indeed, the true value of 21st century computing lies squarely 

in its "connectivity", and, without exaggeration, almost the entire electronics industry is currently 

working on networking developments of some sort or other, and a sizeable proportion of the software 

industry is in there alongside them. 

The first of our specific concepts is called the "semaphore", after the military signalling system 

popularised during the Napoleonic age [as already mentioned in Part 1 (Section 4)]. Here is how 

Raineault (2001/2003 online) summarises its electronic descendents ..... 

"Introduced by Edgar [sic] Dijkstra in the mid-1960s, the semaphore is a system-level abstraction 

used for interprocess synchronisation. The semaphore provides two atomic operations, wait (P) and 

signal (V), which are invoked to manipulate a nonnegative integer in the semaphore data structure. 

The wait operation checks the value of the integer and either decrements it if it's positive or blocks the 

calling task. The signal operation, in turn, checks for tasks blocked on the semaphore and either 

unblocks a task waiting for the semaphore or increments the semaphore if no tasks are waiting. A 

binary semaphore, which has counter values limited to 0 and 1, can be used effectively by an 

application to guard critical systems. (Raineault, 2001/2003 online, p15). 





Before saying any more about semaphores, we need for a moment to consider the physical nature of 

the modern computer. Even with the most modern micro-fabrication techniques, the majority of 

computers end up with the electronics chip-mounted onto printed circuit boards, the circuit boards 

slotted into a larger chassis, and the chassis equipped with the necessary communications sockets 

(or "ports"). A system of internal wiring (the "loom", or "bus") then connects separate mounting 

boards to each other and/or to the communications sockets as appropriate. The connections between 

the electronics components and the circuit board, and between the circuit board and the wiring loom, 

are called "pins" and "pinouts", respectively. Software modules written specifically to initiate output 

to, or interpret input (or feedback) from, pinouts, are known generically as "device drivers" (or just 

"drivers" for short). 

Now if semaphores are memory abstractions as Dijkstra says, and pins are physical things, then the 

art clearly lies in getting the two things to work together, and the classic solution for half a century has 

been for the CPU in question (a) to monitor the processing state of an associated module by wiring 

the latter to a pin it can itself directly access, (b) to monitor said pin [the way we monitored the TIMER 

PIN in Section 1.1 above], and (c) to schedule its own processing according to what that monitoring 

reveals. The signal pins are known generically within electronics as "busy pins", and the timing 

instructions are of the nature . The semaphores - one per unit 

being monitored - then simply echo that pin status into the software, where it can be tested. To 

maximise processing speed it is usual to maintain the semaphores at bit level rather than at byte level, 

and to provide them as a class of purpose-built CPU registers called "status registers". Heidenstrom 

(1998/2003 online) shows several nice tables relating bit values within the status registers to the 

numbered pins on the communication ports, if interested. 

Key Concept - Semaphores and Busy Pins: A semaphore is a status register bit, addressable in 

the inward direction by the local CPU, and directly connected in the outward direction to a 

communications pin of some sort. This allows the local Control Unit to monitor the processing state of 

a remote module with which it is for the time being associated. Semaphores are typically used to 

synchronise the execution of logically related software in distributed processing systems. 

Thus far, we have been concerned with a single CPU within a distributed processing architecture. 

However, as soon as we consider arrangements of more than one CPU we encounter a whole cluster 

of new key concepts at once. Rather than be constantly interrupting our core argument, therefore, we 

strongly recommend pre-reading our e-paper on "The Relevance of Shannonian Communication 

Theory to Biological Communication". As to what the associated modules might be, the detail 

depends on the individual model of computer and/or the particular network architecture involved, but 

here are the usual options ..... 

ONE LOCATION MODULARITY 

CPU to Coprocessor [eg. a mathematics or graphics chip, case-internal and connected via bus] 

CPU to Internal Peripheral [eg. communications card or disk drive, case-internal and connected via bus] 

CPU to External Device [eg. printer, zip drive, etc., case-external and connected via port and cable] 

TWO LOCATION MODULARITY 

CPU to Hierarchically Subordinate Remote CPU [eg. local server, via port and complex network] 

CPU to Hierarchically Equal Remote CPU [eg. e-mail correspondent on own PC, via port and complex 

network] 





Fortunately, there is really only one problem, regardless of the architecture, and that is how to keep all 

the nodes properly synchronised. Less fortunately, perhaps, this is not just a matter of providing 

sufficient semaphores and busy pins. Instead, it calls for sophisticated networking protocols (for when 

things are working well), and equally sophisticated exception handling mechanisms (for when they are 

not). 

Key Concept - Exception Handling: Exception handling is the systematic (ie. pre-programmed) 

response to an error condition. In a stand-alone program, such errors can arise on just about any 

single program instruction, although they are especially common in file handling, data exceptions, and 

large computations. In a networked program, they can arise on any instruction in any of the 

associated processors as well, including those making up the carrying data network. Overall, the 

biggest single risk to any complex system is when accident or breakdown at one point creates a 

situation which had not - due to corner-cutting, ignorance, or laziness - been catered for elsewhere. 

Burns and Wellings (1990) describe how exception handling uses the sort of interrupts previously 

introduced in Part 4 (Section 1.3). In fact, they carefully distinguish between I/O Interrupts (the line 

speed type), and "exception handling", the ability of cooperating modules to react to problems 

elsewhere in the processing network. For IO Interrupts, they explain ..... 

"..... the role of interrupts in controlling input/output is an important one. They allow input/output to be 

performed asynchronously [glossary] and so avoid the 'busy waiting' or constant status checking that 

is necessary if a purely status-controlled mechanism is used. In order to support interrupt-driven input 

and output, the following mechanisms are required [.....] When an interrupt occurs, the current 

processor state must be preserved and the appropriate service routine activated. Once the interrupt 

has been serviced, the original process is resumed and execution continues. Alternatively, a new 

process may be selected by the scheduler as a consequence of the interrupt. [.....] Devices differ in 

the way they must be controlled; consequently, they will require different interrupt-handling routines." 

(Burns and Wellings, 1990, pp434-435) 

Now the reason we are bothering with all this detail is that the similarity between distributed 

processing in the computer world and the parallel distributed processing approach to cognitive theory 

is more than just superficial - it could very well be that biological processing networks share the 

need for busy pins and semaphores. Here is how Philip Johnson-Laird, Stuart Professor of 

Psychology at Princeton University, puts it ..... 

"But parallel computation has its dangers too. One processor may be waiting for data from a second 

before it can begin to compute, but the second processor may itself be waiting for data from the first. 

The two processors will thus be locked in a 'deadly embrace' from which neither can escape. Any 

simple nervous system with a 'wired in' program that behaved in this way would soon be eliminated by 

natural selection. Higher organisms, however, can develop new programs - they can learn - and 

therefore there must be mechanisms, other than those of direct selective pressure, to deal with 

pathological configurations that may arise between the processors. A sensible design is to promote 

one processor to monitor the operations of others and to override them in the event of 

deadlocks and other pathological states of affairs. If this design feature is replicated on a large 

scale, the resulting architecture is an hierarchical system of parallel processors: a high-level 

processor that monitors lower level processors, which in turn monitor the processors at a still lower 

level, and so on down to the lowest level of processors governing sensory and motor interactions with 

the world. A hierarchical organisation of the nervous system has indeed been urged by 





neuroscientists from Hughlings Jackson to H.J. Jerison [citation], and Simon (1969) has argued 

independently that it is an essential feature of intelligent organisms. [.....] In a simple hierarchical 

computational device, the highest level of processing could consist of an operating system." 

(Johnson-Laird, 1988, pp361-362; bold emphasis added)




biology, they are designed to enable a motor hierarchy of some sort, and this constrains their design 

in three very important ways. Firstly, users find themselves sitting [functionally always, and possibly 

physically into the bargain] at the top of a complex command and control structure - they are pilots of 

aircraft, say, or the duty controllers in nuclear power stations, and so on. Secondly, the higher 

processes communicate relatively few guiding instructions and rely on relatively sparse feedback. 

Instead, they leave the bulk of the dataflow to the lower system to administer, via a host of low level, 

heavy traffic, automatic control loops and servosystems. 

ASIDE: It is not always appropriate for cognitive modellers to draw flowlines "to scale" in an attempt to 

emphasise the relative flow of information at any one point. Nevertheless, Smith (1993) and Smith 

(2003 online; Figure 2) both show the low level information flows with heavy flowlines, and Frank 

(1963) solves the same problem a different way by annotating bits per second measures onto his 

flowlines. 

And thirdly, this raises exceptionally high demands for accuracy and reliability on the part of any 

intermodular systems components. 

So it turns out that the central issue for real-time systems designers is actually the same as it was in 

Section 3.7 for the designers of distributed systems - it is the inherent difficulty of managing the 

necessary modularity. Thus ..... 

"The software which controls the operations of the [typical real-time] system can be written in modules 

which reflect the physical nature of the environment. Usually there will be a module which contains the 

algorithms necessary for physically controlling the devices, a module responsible for recording the 

system's state changes, a module to retrieve and display those changes, and a module to interact 

with the operator." (Burns and Wellings, 1990, p6) 

And it is in putting all these modules together that the key concepts we have encountered so far start 

to fall into place - concepts such as buffers, nodes, interrupts, busy pins, semaphores, and the like. In 

Part 7, we shall be looking for evidence of biological real-time processing, and considering whether 

biological cognition might rely on directly or metaphorically cognate systems, and, if so, what neural 

mechanisms might be involved. Again, similarities with the seven-layered network structures 

currently used throughout non-biological telecommunications [reminder] will need to be 

microscopically explored. 

3.9 STM for "Object-Oriented" Processing Purposes 

We turn finally to the difference between conventional and what is known as "object-oriented" 

computing. Khoshafian and Abnous (1990) introduce this issue as follows ..... 

"..... in the late 1950s, one problem found when developing large FORTRAN programs was that 

variable names would conflict in different parts of a program. [.....] The designers of the language 

ALGOL decided to provide barriers to separate variable names within program segments. This gave 

birth to the Begin ..... End blocks in ALGOL 60 [Citation]. Since the variable names appearing within a 

block are known only to that block, their use will not conflict with the use of the same variable name in 

other blocks of the program. This was a first attempt at providing protection or encapsulation within a 

programming language. Block structures are now widely used in a variety of languages. [//] In the 

early 1960s, the designers of the language SIMULA-67 [Citation] took the block concept one step 

further, and introduced the concept of an object [thus laying] the foundation of object-oriented 

languages and some of the object-oriented terminology."(Khoshafian and Abnous, 1990, p11) 





"Using conventional techniques, the code generated for a real-world problem consists of first encoding 

the problem and then transforming the problem into terms of a von Neumann computer language. 

Object-oriented disciplines and techniques handle the transformation automatically, so the bulk of the 

code just encodes the problem and the transformation is minimised. In fact, when compared to more 

conventional (procedural) styles of programming, code reductions ranging from 40% to an order of 

magnitude have been reported. [Therefore] the object-oriented concepts and tools are enabling 

technologies that allow real-world problems to be expressed easily and naturally [and] provide better 

methodologies to construct complex software systems out of modularised reusable software units." 

(Khoshafian and Abnous, 1990, pp7-8) 

Within the computer world, therefore, the ideal object is an "encapsulated" (= physically delineated) 

run of object code within what is otherwise a conventional program, which has been deliberately set 

up as such by an object-oriented compiler from an equally encapsulated run of source code. The 

result is a machine instantiation of a real world object, and the fact that it remains encapsulated at 

object code level gives it a powerful practical appeal as a means of delivering "re-usable software". 

Indeed, object orientation "can be loosely described as the software modelling and development 

(engineering) disciplines that make it easy to construct complex systems from individual components" 

(Khoshafian and Abnous, 1990, p6; italics original). 

But that is not all. Gorlen, Orlow, and Plexico (1990) summarise the benefits of the object-oriented 

approach as follows ..... 

"When doing object-oriented programming, a programmer specifies what to do with an object rather 

than focussing on the conventional procedural aspects of how something gets done. Simply stated an 

object comprises the data elements or the data structure needed to describe the object, together with 

the set of permissible operations on the data." (Gorlen, Orlow, and Plexico, 1990, p2; italics original) 

Needless to say, successful object-orientation needs to begin at the early analysis stage with a search 

for the real world objects the system is going to be dealing with. We have already described this 

process in Part 4 (Section 4.2) and Part 5 (Section 3.1), and emphasised the pivotal role of the data 

model in software development. The process then continues into the detailed design stage, looking for 

hierarchies within these real world objects, so that "classes" of objects may eventually be declared to 

the compiler, so that attributes are not needlessly duplicated. This is what provides an object-oriented 

system with what is known as "inheritance". Here is a formal definition ..... 

"Inheritance simplifies the task of creating a new class that is similar to an existing class by enabling a 

programmer to express just the differences between the new class and the existing class, rather than 

requiring the new class to be written from the beginning" (Gorlen, Orlow, and Plexico, 1990, p101). 

ASIDE: In fact, the process of data modelling has always involved abstraction of this sort, and in the 

early 1980s we personally carried out detailed design abstraction for an IDMS network database 

system to be implemented in conventional COBOL. This was perfectly straightforward, given that the 

Entity-Relationship Diagram is quintessentially a model of objects and hierarchically inherited 

attributes, and is designed to be implemented in a variety of ways. Object-oriented products need, 

therefore, to be approached with caution, for it is sound design which delivers truly reusable software, 

not this or that breed of compiler. What does make the object-oriented paradigm interesting is the 

encapsulation it offers ..... 





Yet again, however, the central issue for object-oriented systems designers is actually the same as it 

was in Section 3.7, namely the inherent problems of modularity. Only now it is called encapsulation, 

and encapsulation is a very important issue ..... 

"[Encapsulation] is a good programming practice because it enforces the separation between the 

specification and the implementation of abstract data types ....." (Gorlen, Orlow, and Plexico, 1990, 

p21). 

"The design of a large embedded system cannot be undertaken in one exercise. It must be structured 

in some way [and] two complementary approaches are often used: decomposition and abstraction. 

Decomposition, as the name suggests, involves the systematic breakdown of the complex system into 

smaller and smaller parts until components are isolated that can be understood and engineered by 

individuals or small groups. [.....] Abstraction [allows] a simplified view of the system and of the objects 

contained within it to be taken, which, nevertheless, still contains its essential properties and features. 

The needs of abstraction dictate that [program] subcomponents should have well defined roles, and 

clear and unambiguous inter-connections and interfaces." (Burns and Wellings, 1990, pp18-19) 

The guru of modularity in cognitive science is Rutgers University's Jerry Fodor, who first raised the 

topic in his 1983 book "The Modularity of Mind", and who went on to define a cognitive module as an 

"'informationally encapsulated' cognitive facility" (Fodor, 1987:25). We should also mention University 

College, London's Richard Cooper, who is working on an object-oriented language called COGENT 

for cognitive modelling (Cooper undated/2003 online), and who points out that functional modularity in 

the brain achieves exactly the sort of encapsulation which prompted the object-oriented movement in 

the first place. Thus ..... 

"[OOP] offers the possibility of directly addressing, within a sound computational framework, the 

functional modularity implicit in box/arrow diagrams. Specifically, within an object-oriented paradigm, 

boxes might be directly modelled as objects (of various classes), with arrows being directly modelled 

as communication channels between those objects." (Cooper undated/2003 online) 




construct is still nevertheless important. It has a role in the construction of processes themselves and, 

moreover, it can be used to define the interface to a process [where] the process is defined within the 

'body' of the object." (Burns and Wellings, 1990, p19)

Short-Term Memory Subtypes in Computing and Artificial Intelligence

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?