9

On a recent trip to the London Science Museum I saw Babbage’s Analytical Engine.

enter image description here

enter image description here

Apparently this had an ALU (or equivalent). I can build an ALU out of logic gates but I can’t conceptualise how to do it with gears. I’m trying to map across the concepts.

I get that the Analytical Engine is not completely understood - and we only have pieces of it, and we're still going through the notes. But should be able to infer enough from the few gears we have as to what sort of instructions it would take.

My question is: Can we express the instructions to the Analytical Engine in terms of assembler or machine code?

  • 1
    If you want to understand how an ALU can work with gears, I suggest looking at the stepped drum which is central to Leibniz' mechanical calculator. If you've ever seen Leibniz' calculator in action (maybe there are youtube videos), the principle becomes very obvious. – dirkt May 25 '18 at 16:41
8

Yes. In fact, it is a very simple system in machine language terms.

The key to understanding the system is to look at the physical construction of the part you saw. This is what we would today would call the accumulator. It holds a single mathematical value. You can see it consists primarily of several vertical rods with gears spaced out along them. Each gear holds a digit in it's angle compared to the rod, I can't recall if each disk represented one or two digits?

In a modern machine we would express this as a number of bits, "this processor is a 64-bit design". In the case of the analytical engine, it used decimals, not bits, and had 40 digits. For comparison, it was common on 8-bit machines to perform math in "binary coded decimal", often with two decimal digits stored as 4-bit values in a single byte. Thus, to represent the same numbers as the engine, you would need 10 bytes. Typical BASIC interpreters of the era, like those found in the Commodore line, used 9-byte formats, so pretty close!

The original plan was that this ALU would be connected to a store consisting of another 1,000 such vertical rods, also holding 1 40-digit number each. So in modern terms, this is a 160-bit processor (40 digits / 2 digits per byte * 8 bits per byte), with 1,000 words of main memory.

Along the bottom you can see a number of odd bumpy-shaped disks arranged at right angles to the vertical rods, along a large shaft. These take the place of the clock drivers in a modern processor. As the shaft turns, the arms resting on top of the disks are raised and lowered, which connects and disconnects gearing under the vertical shafts. This is identical in purpose to the diode network that controls the operation of the functional units in early microprocessors.

Note that the shaft is driven by the large gear you can see on the right end. This connects it to the main driveshaft, which connects to most of the parts. The speed of the machine is basically how fast you turn that shaft.

So, for instance, let's say you want to add the value on one of the rods in the store to the value in the accumulator. The Engine did this in steps, it was a "fetch/execute/store" design.

In the first step, a card would be read that had holes that turned off the accumulator, and caused the right memory location to become active. So this is similar to what we would do today with a LOAD 500, although in a modern processor the memory would be physically copied to a register, whereas in the Engine the store location sort of was a register (early core-based machines worked the same way).

So that card would basically cause that location, 500, to be connected to the main drive shaft, while disconnecting everyone else. It would also cause that shaft to come into contact with a set of gears that were (going to be) connected to the accumulator. It's been over a decade so this is IIRC, but I think the horizontal rods you see in the image are those connections. In any event, there are gears on the bottom of each of the digit disks that connect to the transmission system, and then from that system to each of the digits in the accumulator.

Now you do the execute, in this case an ADD. This is a card that re-connects the drive shaft to the accumulator, spins that set of disks on the front, and then makes both the store and accumulator shafts start turning. They turn until the store shaft has made one complete spin, but the digits stop turning when they get to zero, so in that complete spin a disk that was originally set to 1, which is 36 degrees, causes the same disk in the accumulator to spin the same amount. But that disk might have already held a value, so presto, you've added.

The brilliance of the design was twofold. One was that it carried out the math in parallel across all the disks. In comparison, if you've seen a typical mechanical calculator using disks you'll note you have to turn each digit's disk individually, so that would be a serial math unit compared to this parallel unit. But the other trick, originally developed on the calculating engine, was what to do about carries...

Consider if the ALU's first digit (the top one IIRC) was 9 and you add 1. This has to make the next digit go up by one as well. This is easy, you have a pin on the bottom of the disk that hits the disk below it and spins it one location. Ahh, but consider what has to happen when the ALU holds 9999999.... that top gear has to spin all the ones under it! The amount of force goes way up, and that is a Bad Thing for a machine with thousands of spinning parts. The design had a way to solve this, I seem to recall it used a separate set of carry bits that were added at the end of the cycle?

The language is very simple, and in modern terms would be considered a RISC design - or more accurately, a load/store design. The punch cards that fed the machine would connect to similar operational rods like the ones on the disks, to form the instructions. These were very simple, they consisted of a load, store, add, sub, mul, div, and in theory, sqrt. So using a bastardized modern assembler, you might do something like...

READ 10, 500 ;put "10" into location 500
READ 5, 501  ;put "5" into 501
LOAD 500     ;load the value in 500 into the accumulator
ADD 501      ;add the value from 501
STORE 502    ;write the result to location 502

And now you've added 10 and 5 to make 15, and then wrote that to the printer.

Connected to the other side of the store was an output system consisting of a printer and a bell. It could be instructed to output the value in any one of the store's vertical shafts. When the program was complete, you told it to ring the bell.

All of these, with the exception of the direct output, map directly onto any simple assembler. It had only one register and 1000 words of memory, making it very similar to many early machines like FERUT.

  • I find it interesting that many early computers used very large registers. Forty decimal digits would be 20 bytes in BCD, which is much larger than the five-byte values used on Commodore Basic (which were good for about nine decimal digits of precision). I'd guess that's because the concept of floating-point wasn't invented? I don't know how Babbage wanted to handle the carry chain, but the Curta Calculator has a very nice approach both for that and for the potential problem of a wheel overshooting its target. The point in the cycle where a drive gear engages a counting wheel will vary... – supercat May 25 '18 at 21:45
  • ...depending upon the value to be added, but at a fixed point in the cycle the counting wheel will engage a mechanism that will either advance or not based upon whether the previous digit had a carry. – supercat May 25 '18 at 21:48
  • The OP asked, "Can we express the instructions...in terms of assembler...?" Based on your description, the cards for the analytical engine sound like they would have contained something more like horizontal microcode rather than typical "machine code." – Solomon Slow May 28 '18 at 18:50
  • No, the cards did not drive the process, only started it. The multiply, for instance, required multiple steps that were all started by a single card, while add did different steps started by an almost identical card. The microcode is on those wheels, not the cards. – Maury Markowitz May 28 '18 at 18:54
  • OK, but in microcode, it's typical to have this single bit in the instruction gate the ALU output onto that internal bus, and this other bit gate the register file output onto this other bus, etc., and it's typical for the machine to perform exactly one microinstruction for every clock cycle. Very different from a higher level instruction set in which different "op codes" specify different sequences of operations that may require varying numbers of clock cycles to complete. Which one would you say sounds more like the Analytical Engine "programming language"? – Solomon Slow May 28 '18 at 19:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.