Responses to the May column on Core War ranged from simple requests for the supplementary guidelines on the game to descriptions of complete Core War systems already in operation. In between were numerous anecdotes about Creeper-like programs inhabiting real systems (including worms in Apples), discussions of programs as genes and speculations about defensive and offensive strategy. Only a few important developments can be mentioned here; others will have to wait for a future column on the subject, which I hope will appear before the end of the year.

I have been told by Douglas B. McIlroy of AT&T Bell Laboratories that it was not he but Victor A. Vyssotsky of the same institution who invented the game Darwin. McIlroy did, however, invent an unkillable organism.

What happens when an Imp runs into a Dwarf? One possibility was explained in the May column: Dwarf transfers control to Imp's code and becomes a second Imp endlessly chasing the first one. Another possible outcome has the opposite effect. Suppose Dwarf has just jumped back to its first instruction when Imp copies itself over Dwarf's data location. The situation is then as follows:

  Imp → MOV    0    1
Dwarf → ADD   #5   -1
        MOV   #0  @-2
        JMP   -2

Since it is Dwarf's turn to execute, it adds 5 to Imp's code, turning it into MOV 0 6. Then Imp executes, copying itself six spaces ahead, well clear of Dwarf, which then bombs its next address (specified by the numerical code corresponding to MOV 0 6). On Imp's next turn something curious happens: it executes the first line of Dwarf's program, so that for a time the game is played by a “double dwarf” pointlessly shooting up the core array while the object of its attack inhabits its own body and does exactly the same thing!

David Menconi of Milpitas, Calif., a game designer at Atari, Inc., has suggested making this very phenomenon a regular feature of Core War by allowing each battle program to execute in two places at once. Thus even if a program loses one “self,” a second self might be able to repair the damage. Edsel Worrell of Bethesda, Md., suggests the somewhat more general scheme of n selves, all executing the same program at different addresses.

Robert Peraino of George Mason University wrote a Core War system for the Apple II+ computer, compensating for the machine's small word size by using a two-dimensional array of 2,000 by two bytes. Bill Dornfield of AMF, Inc., wrote a complete Core War system in extended BASIC on a Hewlett-Packard 9816/26 desktop computer.

The most impressive system to date was constructed by three graduate students: Gordon J. Goetsch and Michael L. Mauldin of Carnegie-Mellon University and Paul G. Milazzo of Rice University. Mauldin demonstrated the program on a VAX computer in my department at the University of Western Ontario. In an impressive screen display the entire core array is shown, with the position of each contending program marked by a capital letter and the areas affected by the program marked by the corresponding lowercase letter.

Mauldin has invented a battle program called Mortar that operates like Dwarf except that its bombs are directed according to the sequence of Fibonacci numbers (1, 1, 2, 3, 5 and so on, each number being the sum of its two predecessors). Oddly enough, Dwarf beats Mortar 60 percent of the time, but Mortar invariably kills a three-part self-repairing program called Voter. On the other hand, Voter survives attacks by Dwarf and regularly defeats it.

Goetsch, Mauldin and Milazzo have analyzed Mortar and concluded that if a battle program is longer than 10 instructions in must be self-repairing in order to defeat Mortar. No program longer than 141 instructions, however, can repair itself fast enough to survive an attack by Mortar.