From Ed Nather's hacker-epic "The Story of Mel" (using the original paragraph-formatting to save space in this question):
The firm manufactured the LGP-30, a small, cheap (by the standards of the day) drum-memory computer, and had just started to manufacture the RPC-4000, a much-improved, bigger, better, faster — drum-memory computer.
[...]
Perhaps my greatest shock came when I found an innocent loop that had no test in it. No test. None. Common sense said it had to be a closed loop, where the program would circle, forever, endlessly. Program control passed right through it, however, and safely out the other side. It took me two weeks to figure it out.The RPC-4000 computer had a really modern facility called an index register. It allowed the programmer to write a program loop that used an indexed instruction inside; each time through, the number in the index register was added to the address of that instruction, so it would refer to the next datum in a series. He had only to increment the index register each time through. Mel never used it.
Instead, he would pull the instruction into a machine register, add one to its address, and store it back. He would then execute the modified instruction right from the register. The loop was written so this additional execution time was taken into account -- just as this instruction finished, the next one was right under the drum's read head, ready to go. But the loop had no test in it.
The vital clue came when I noticed the index register bit, the bit that lay between the address and the operation code in the instruction word, was turned on-- yet Mel never used the index register, leaving it zero all the time. When the light went on it nearly blinded me.
He had located the data he was working on near the top of memory -- the largest locations the instructions could address -- so, after the last datum was handled, incrementing the instruction address would make it overflow. The carry would add one to the operation code, changing it to the next one in the instruction set: a jump instruction. Sure enough, the next program instruction was in address location zero, and the program went happily on its way.
A programmer's manual for the Royal Precision LGP-30 computer is available here. It does not seem to have an "index register"; it does have what it calls a "counter register" but that's just a traditional "program counter"/"instruction pointer." Which also means that the LGP-30 definitely did not have the "every instruction followed by a GO TO" feature that Ed Nather attributes to its successor the RPC-4000. The lack of an "index register" is also indicated by how the LGP-30 manual uses instruction modification to do load-from-consecutive-indices in a loop, in this section of the manual.
The Internet Archive has an RPC-4000 manual which does indicate the presence of a "next address" field and an "index tag field" (in the lowest-order bit). Ed Nather's story talks about "a jump instruction," which the RPC-4000 doesn't have; but if you were to increment a command word whose index bit was set, you'd end up overflowing into the "next address" field, which could probably be made to do something similar, maybe?
Can anyone provide an example of an "infinite loop" that uses anything resembling Mel's technique to break the loop?
There's some previous discussion on Hacker News here. Commenter "kps" points to an FTP site where you can download an LGP-30 simulator (written in Pascal): ftp://ftp.informatik.uni-stuttgart.de/pub/cm/lgp30/simulator/lgp30sim.zip
and a blackjack game (ASCII dump of the machine code): ftp://ftp.informatik.uni-stuttgart.de/pub/cm/lgp30/papertapes/Games/bkjck.tx
If it's possible to "disassemble" that blackjack game, that at least would be very interesting, even if it might not answer the question because the LGP-30 wasn't much like the RPC-4000.
