Xrfgtjtk

The IBM 650 seems to be a load-store machine. One advantage of a load-store machine is that the instruction can be shorter because there's less pressure to pack more information into it. But the IBM 650 has two addresses in each instruction: the operand, and the address of the next instruction.

Of course, after every instruction, the next one needs to be read from somewhere else. That's true of all stored-program computers. It's just that the obvious way to do that is to implement some kind of counter which implicitly gets incremented after each instruction, and then also may be used by the hardware as a pointer to fetch the next one. Then, if ever that value needs to be modified, well that's what jmp is for.

The ... "interesting" approach of the IBM 650 means that jmp is basically replaced by no-op, and every instruction incurs the cost of specifying the address of the next instruction.

What is the use of this? Maybe they expected users to modify the next instruction field to allow for Real Goofy control flow (structured programming hadn't been invented yet, nor had GOTO Considered Harmful been written)? Or was the logic to increment and dereference a program counter not feasible for some reason?

Very simple: Because there was room for an address and it improves performance a lot. Or as the manual puts it:

It is important, however, for the programmer to realize that the simplest method of programming (using sequential drum location for succeeding instructions) causes the machine to waste a large amount of time waiting and searching.

To start with, the 650 is not a load store architecture, as that would imply multiple registers, but an accumulator machine. Further, it might be useful to keep in mind that it's still in between a punch card computer and a computer as we know it today. We tend to always look at it as a CPU with a memory stored program, as now canonical, but its operation relies as much on the plug-board programming it had in addition.

Back to the question:

The 650's main storage was a drum with 50 words of 10 digits (plus sign) per track (band) and 20, 40 or 80 tracks. An instruction consisted of a two digit opcode and a 4 digit operand address. Of course they could have left the remaining 4 digits unused, or use it to encode the address of a second operand, making it a two operand machine, except that would have required a more complicated and expensive logic.

Using them to store the follow-up address improves things on several levels:

• First it saves on the need of a separate incrementer for the program counter: only a load circuit is needed.




• This in turn also implements jump instructions without any further effort.




• On the software side, it allows many strategies to use this chaining for simplifying code and/or creating logic otherwise hard to implement.




• And last but certainly not least, it did offer a great way to improve performance to the max, as the instructions could be spread out in a way to have the next always ready when the current one is done.

The last point is (as always) quite obvious when doing the math (*1). The drum rotated at 12,500 rpm; that's about 4.8 ms per turn, or 9.6 µs per word. Each instruction can, as usual, be described by the time it takes. For simplicity this can be done in word time (which equals 9.6 µs). Even the most simple instruction like an add will take 3 word times. So if we assume just the instruction timing (for simplicity), then the machine won't be ready to read a follow-up instruction until the fourth word thereafter. Placing the next instruction in a consecutive location would therefore add a whole rotation before it could be read and executed. That's 4,800 µs compared to zero when spacing the two sequential instructions three words apart, making it like 16 times slower than it could be.

Now, if it were that simple, they could have just put in a skew of 3 on the hardware level when addressing words as instructions (*2,3), but it isn't. Not only do instruction timings range from 3 to 17 word times (*4), but access also depends on the place the data is stored. Almost every instruction addresses some data (which the first address is meant for). Since data are stored on the same drum, and all heads are aligned, it means that an instruction has first to wait for the according data to come by, then execute and then fetch the next instruction. So there are two access timings (waits) to be incorporated into each instruction layout, plus its execution time (*5).

Optimum program structure means staggering instructions and data in a way around the drum that minimizes wait times for the data cell to come around and the next instruction to follow. And we are not talking a few percentage plus or minus, but up to 50 fold slower - as it may degrade a single word access to a whole drum turn.

In fact, a case can be made, that including the address of the next instruction is exactly the same case as for including the data address, as both are random access operations within the same framing of a memory access. Thus both should have the same freedom of determination within the program context.

Reducing that to an implied next address as of the following word is a simplification that's only free in a system with zero (or next to zero) access time.

*1 . In fact, the manual spends a whole section on what it calls "Optimum Programming".

*2 - And adding an incrementer for the PC.

*3 - But then again, this skew would also screw the access of the very same words as data ... not cool.

*4 - Plus exceptions like Table Lookup with its very own timing issues.

*5 - It gets even more complex due the fact that the accumulator adheres to drum timing, so execution time also relies on the instruction in question residing on an even or odd address. Also instruction search and data search can be in parallel if the circumstances are right.

If your primary memory is not random access, in the sense that at any instant some addressed words will take longer than others to be read, then you can potentially improve performance by having each instruction specify where the next instruction is located. The programmer is then coerced to figuring out where that next instruction ought to be.

This applies to any rotating memory, whether it's a drum surface or pulses in a mercury tank. The cost, as pointed out, was relatively low.

Instruction bits to some extent were not in short supply in those days, since memories were very small and expensive, so a memory address didn't need many bits.

Much programmer effort was spent on 'optimal programming', though Wilkes refused to countenance such a scheme for the EDSAC, rightly perceiving that this was just a temporary need until better memory technology arrived.

Yes, it WAS due to the fact that with a rotating drum memory, you wanted the next instruction to be at a location that was just about to come under the read/write heads rather than in the next sequential location, where it could take a full revolution of the drum to be able to read the instruction.

All was not lost for the programmer, however. The 650 came with the Symbolic Optimizing Assembly Program (SOAP) which arranged the instructions to the best advantage for you.