# Can we express the instructions to the Analytical Engine in terms of assembler or machine code?

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

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?

• 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. May 25, 2018 at 16:41

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 numeric value. You can see it consists primarily of several vertical rods with gears spaced out along them. Each gear holds a digit, or perhaps two, I can't recall. The digit is represented by the current angle of the gear, so the number 2 might be represented by turning the gear 72 degrees, and the number 5 would be 180 degrees.

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 early 8-bit microprocessors to perform math in "binary coded decimal", often with two decimal digits stored as 4-bit values in a single byte (the "packed" format). Thus, to represent the same numbers as the engine, you would need 20 bytes. Typical BASIC interpreters of the era, like those found in the Commodore line, used 9-byte formats, so the Engine offered much more precision.

The original plan was that this ALU would be connected to a store consisting of another 1,000 such vertical rods, also holding one 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.

At the bottom right, within the machine, you can see a large gear facing the front. This is the main power input, connected to a common driveshaft. This is the equivalent to the clock signal in a modern processor. The speed of the machine is basically how fast you turn that shaft, which is limited at the top end by how quickly the bits can move without breaking or stripping teeth off the gears.

That driveshaft is connected to both the vertical shafts of the accumulator, as well as the large shaft running horizontally along the bottom front of the machine. Along the shaft at the bottom you can see a number of odd bumpy-shaped disks arranged at right angles to the vertical rods. 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. Depending on the holes in the associated punch cards, these disks will be rotated to a particular position, connecting or disconnecting the rest of the system from the main driveshaft. The driveshaft then continues turning and will manipulate those bits of the machine that are still connected.

So, for instance, let's say you want to add the value on one of the rods in the 1,000-word 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 by rotating those control disks so the accumulator's gears were disconnected, while at the same time causing the gears under the selected memory location to connect. 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 in the accumulator might have already held a value, so presto, you've added the value 1 to that digit in the accumulator.

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 accumulator'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 a similar pin the disk below it and spins it one location. This had been used for years in previous mechanical calculators. 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 stored the result back out to another register.

Connected to the other side of the store was an output system consisting of a printer and a bell. I believe the series of horizontal rectangular rods about half way up the machine are used for this connection. One of the instructions connected the store to the printer instead of the accumulator, so you could print the value. 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... May 25, 2018 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. May 25, 2018 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." May 28, 2018 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. May 28, 2018 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"? May 28, 2018 at 19:00

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

Yes, we can, and there is an online emulator doing just that. You can type in 'cards' in symbolic form for execution.

This page describes Babbage's card structure; cards were 'operation', 'number', or 'variable' cards, which correspond to concepts in modern machine languages, though which in the Engine were presented in different readers.

The representation in the emulator is not an exact match for Babbage's plans - for example, the three separate card types are combined into one stream, with a punching to indicate card type.

The 'operation' cards would clearly map to the instruction set of a compute: add, subtract, multiple, divide. Certain cards types branch backward and forward in the instruction reader (remember, this is not a stored-program computer). The 'variable' cards have the nature of instructions: load, load-and-clear, store.

So the answer to the question is in the affirmative, because it's been done. The links merely provide the evidence that it's been done.