IBM 650 Drum Timing: How Program Placement Cut Rotational Waiting

On the IBM 650, program placement was part of performance engineering. IBM dates the machine’s announcement to 1953; the timing contract discussed here comes from the June 1955 operation manual and a 1958 programming guide. The machine stored both data and instructions on a rotating magnetic drum, and an instruction named the location of the next instruction to execute. That made it possible to arrange a program around the drum’s timing. Poor placement did not normally make the arithmetic wrong: IBM’s documented interlocks protected machine timing. It did make the processor wait for words to rotate back under the read heads.

The 650 is often described as a magnetic-drum computer, but the useful historical detail is what that storage choice meant to a programmer. This article focuses on the original Type 650’s address layout, the period “5-10” placement heuristic, and IBM’s Symbolic Optimum Assembly Program (SOAP). It does not treat every 650 configuration or later peripheral option as identical.

A word was an address on a moving surface

The 1955 IBM operation manual describes Type 650 machines with 10,000- or 20,000-digit storage capacities. Each stored number occupied ten decimal digits and a sign. For the 20,000-digit, 2,000-word configuration, IBM’s brochure diagrams 40 bands with 50 address positions in each band. These were logical positions selected by the recording heads, not separate physical slots cut into the drum.

The drum rotated at 12,500 revolutions per minute. One revolution therefore took 4.8 milliseconds. With 50 word positions around a band, one word-time was 1/50 of a revolution, or 0.096 milliseconds. A four-digit drum address identified a word position; the machine had to wait for the corresponding point on the moving surface to reach its head before reading it. The words were addressable, but access did not have equal latency: rotational position was part of the cost of a read.

Model boundaries matter. The manual’s 10,000-digit and 20,000-digit capacities are distinct configurations. When the 1955 manual discusses 40 equivalent angular positions, it explicitly assumes the 2,000-word machine. The timing calculations below use that configuration; they should not be generalized into a claim that every delivered 650 had the same address capacity or attached devices.

Each instruction named its successor

An ordinary 650 instruction was a ten-digit word plus a sign position, containing an operation code, a data address, and a next-instruction address. IBM’s 1955 brochure illustrates an add instruction that reads data from one drum location and names another location for the next instruction. The stored program was therefore not simply a list that the processor always fetched from consecutive addresses. The programmer selected where the next step lived.

That field created a performance opportunity. While an operation processed its data, the drum continued to rotate. If the next instruction’s address arrived at the read head at the moment the machine was ready for it, execution could continue without an avoidable rotation. The same placement problem applied to the data address: its word needed to arrive when the operation requested it. An instruction sequence could be logically correct yet inefficient because its data and successor addresses missed those timing windows.

The IBM manual’s sequence chart breaks down the word-times used by different operations. It notes that operation durations vary, so the ideal positions depend on the instruction and on the data location, not just on source-code order. In the 2,000-word arrangement, addresses separated by 50 occupy equivalent angular positions on successive bands. For timing purposes, the programmer could choose among those equivalent positions without changing when the word passed the head.

Waiting was a performance cost, not a timing hazard

IBM’s operation manual makes an important distinction: interlocks inside the machine prevented a program from violating required timing conditions and producing an erroneous result. Programmers still had to consider drum layout to reduce nonproductive waiting and searching. A simple program stored in consecutive locations could force the machine to wait for the next word to rotate into position; a data access could add another wait.

This distinction changes how to describe “slow memory.” The 650 did not ask each application programmer to race a free-running drum by guessing when a read would occur. Hardware coordination protected correctness. The programmer’s job was to improve throughput by placing data and instructions where the documented operation sequence could use them efficiently. An unscheduled address was a performance penalty, not evidence that the machine had executed an instruction out of order or corrupted its arithmetic.

The 5-10 rule was a starting point

Richard V. Andree’s 1958 programming guide presents a simple rule for beginners. When possible, put an instruction’s data five positions later around its band, then put the next instruction five positions beyond that data address. For a shift instruction, the guide instead recommends placing the next instruction ten positions after the shift instruction when possible. The rule is often called the “5-10 rule”; it is a heuristic, not a specification that every instruction consumes the same time.

For example, if a suitable instruction is stored at 0201, a first placement might put its data at 0206 and its successor at 0211. These addresses are five positions apart in the same band. That layout aims to let the data arrive after the instruction is decoded and the successor arrive after the operation has progressed far enough to need it. The sequence chart remains authoritative for the operation being scheduled: multiplication, division, shifting, input, and output have different timing paths.

Andree cautions that the 5-10 rule does not produce an optimum program. It is a convenient approximation for common operations. A carefully optimized sequence requires accounting for the timing steps of each operation and the addresses it reads or writes. His guide reports that the rule could substantially reduce run time on many programs, while excluding programs requiring a great deal of card reading or punching from that comparison. That is a period author’s estimate, not a universal benchmark for every 650 installation or workload.

SOAP made address assignment a program

Hand placing every instruction and data word could consume substantial programmer time. The 650’s SOAP assembler moved some of this work into software. Andree describes IBM’s Symbolic Optimum Assembly Program as accepting an ordered program whose addresses could be omitted, then producing machine-language instructions placed for drum timing. Its output included the load-card form used to put the resulting program on the drum.

SOAP did not change the 650’s instruction set or make the drum behave like semiconductor RAM. It automated a machine-specific placement problem. A programmer still chose the operations and their logical order; the assembler assigned physical drum locations with operation timing in view. This was an early example of a programming tool adapting layout to the latency model of its target machine, not a modern optimizing compiler with a general-purpose cost model.

The primary IBM operation manual shows why this mattered: it devotes a section to optimum programming and supplies a sequence chart for the timing of arithmetic, shifts, branches, and card operations. The contemporary guide then explains a practical approximation and a symbolic assembler. Read together, the documents show both the hardware rule and the software response rather than leaving “optimize the drum” as a vague slogan.

A specific design lesson, not a universal origin story

The Type 650 demonstrates how a storage device can shape an instruction format and programming practice. Because the medium moved past fixed heads, memory location affected how soon the next operation could proceed. The 650 exposed some of that latency directly through address placement while using interlocks to preserve correctness. SOAP reduced the manual work of arranging a fast sequence.

This is a comparison, not a claim that the IBM 650 directly caused modern cache-aware compilation or instruction scheduling. The documents establish a concrete local history: a rotating main memory, explicit instruction and data addresses, timing-aware placement, and an assembler designed for the machine. They do not establish a continuous line of influence into later processors. The useful takeaway is narrower: an architecture’s performance contract includes the time it takes for data to arrive, and software tools often emerge to manage costs that hardware cannot remove.

Related:

Sources: