# Did Babbage's Analytical Engine lack indirect addressing?

As I understand it the analytical engine could only refer to memory by variable cards that had the explicit address printed on them, see https://www.fourmilab.ch/babbage/cards.html. For instance the only way to load the value at memory location 5 into the "ALU" was by the machine reading a card that said "L005".

However, when reading about the algorithm for computing Bernoulli numbers with the analytical engine, Note G at https://www.fourmilab.ch/babbage/sketch.html it is sort of implied that there is some way to refer to succesively higher memory locations within a loop.

The only exception to a perfect identity in all the processes and columns used, for every repetition of Operations (13…23), is, that Operation 21 always requires one of its factors from a new column, and Operation 24 always puts its result on a new column. But as these variations follow the same law at each repetition (Operation 21 always requiring its factor from a column one in advance of that which it used the previous time, and Operation 24 always putting its result on the column one in advance of that which received the previous result), they are easily provided for in arranging the recurring group (or cycle) of Variable-cards.

So something along the lines of,

``````for (int i = 0; i < n; i++) {
...
B[i] = ...
}
``````

But how would this be possible without some form of indirect addressing?

The key, I think, is that what we think of today as "arithmetic instructions" were in the Analytical Engine broken down into parts. To add two numbers, the sequence is

``````  +      // operation card: set mill for addition
L 001  // variable card: load column 001 to first mill input
L 002  // variable card: load column 002 to second mill input,
//    and operate mill
S 003  // variable card: store mill output in column 3
``````

For the Bernouilli number calculations, it is stated that for increasing 'n', the number of operation cards is fixed (for n>2) at 25, but each unit increase in 'n' requires 33 more variable cards.

This means that although we're looping over operations and are repeating the same operation cards, we are not repeating the same variable cards.

Recall there are 3 separate card readers. We therefore (I surmise) execute a 'goto' on the operation-card reader, to loop back to the beginning of the operation-cards for this section of the computation.

Variable cards are handled differently. If you believe the variable-card reader cannot be stepped backwards (no 'goto' for this reader) then the whole batch of variable cards are repeated, with the variable cards for operation 21 specifying different columns each time.

If the variable-card reader does have 'goto', then we can avoid total repetition in a more complicated manner. We want to loop the variable-card reader back to the right card for operation 13 on the coding sheet. On the other hand, before we execute operation 21, we need to jump to to the right variable card for this iteration; that'a a variable-size goto. That can be done by executing a 'step the variable-card reader once' operation a number of times corresponding to the total number of steps needed'

For the uncertainty here, see this page on the accuracy of the emulator; look for the 'loop the loop' section.

To answer the actual question :-)

Yes, the Analytical Engine lacked indirect addressing, and also lacked address modification (indexing), either of which would be useful in computations involving sequences of numbers.

Nevertheless, creative programming techniques could work around this lack by taking advantage of the unique features of the instruction set.

• On second reading, perhaps that's what you were trying to say, that there needs to be extra variable cards for each successive number calculated. This would make the program huge very quickly though with a series of complicated jumps in the code. And the program would be specific to a particular n. The comment "they are easily provided for in arranging the recurring group (or cycle) of Variable-cards" is what confused me into thinking that the program was general and could handle any n with the same number of cards. Commented Mar 6, 2020 at 16:39
• Yes, that's what I mean. When you set the value of 'n' on its number card, you have to add the appropriate variable cards to the deck. One might wonder whether, had the A.E. been built and used, this limitation would have proven to be sufficiently annoying that indirect addressing would have been invented (say, a form of address card that said "use the value from column N as the column number for the current operation ingress or egress"). I have no idea what that would mean mechanically.
– dave
Commented Mar 6, 2020 at 17:32
• Can I add 'Analytical Engine programming' to my resume now?
– dave
Commented Mar 6, 2020 at 17:36
• @nadder It's always important to keep in mid that such a solution might seam clumsy to today's readers, it still would solve each job in an unprecedented speed - and, equally important, without procedural error. We're today lulled by ever growing numbers of speed, but the step between no calculator and a calculator is a fundamental, while between a 1401 and any of today's super computer it's just gradual. Commented Mar 6, 2020 at 17:55
• @another-dave Well, if you actually prepare the whole card stack for computing B7 I would definitely say so :) Commented Mar 6, 2020 at 17:55