The power of evolution had been demonstrated, but Ray was curious to see which elements of the system were required for evolution to work, and what ranges of frequency of mutation resulted in rapid evolution. He tried turning off mutation completely, out of curiosity--and was amazed to find that evolution carried on happening anyway!
It turned out that sometimes, two programs attempting to reproduce would choose the same location for their offspring, and would interact during reproduction. One of the programs might be overwriting the same memory as the other, slightly behind, and then die from old age or be killed by another program. The result would be a hybrid, with part of the code of one program and part of the code of the other. Similar hybrids would occur if a parasite was busy reproducing using a host program, and that host program died.
Although - even though the "mutation" routine was disabled, it now looks to me as if the environment is buggy in that the above splicing is a form of mutation?
wow, okay. that IS awesome

thanks for the source, I would not have guessed.
I do remember that one of the instructions* was some sort of equivalent to C's MALLOC function. So it would allocate a piece of free (not-alive) memory and return a pointer to it.
Another instruction which could have been called SPARK* would let the virtual machine know the just-allocated piece of memory was now to be considered "alive" and it would start being executed and get a slice of CPU time [yes this part is a bit artificial IMO, as well. he could have used a more traditional fork instruction perhaps].
Anyway, what *could* be the case, is that the MALLOC instruction would only return pointers to pieces of "dead" memory, with enough space for 1-2 times the length of the parent organism. But that means if two organism issue a MALLOC before they issue a SPARK, there is a possibility that they get pointers to partially overlapping memory ranges. It's also a typical kind of coding mistake that's easily to overlook at first, so I can see how that would happen.
Either way, AWESOME BALLS

(*from a 5-bit instruction set numbering about 24 different instructions, having some duplicates to mimic the redundancy as found in DNA coding for amino-acids. which is a funny idea, but I'm not really sure whether there was any solid reasoning behind that decision or whether it might have been a kind of cargo-cultish "let's put that in here, too" choice. but from a "that's pretty cool"-point-of-view, either works)
(**except it wasn't because in those days people believed assembly language instructions had to be cryptic abbreviations, so it might have been called MFB or something. FORK would have been a cool name too)
Although - even though the "mutation" routine was disabled, it now looks to me as if the environment is buggy in that the above splicing is a form of mutation?
well yes, sort of. of course if they'd be writing to overlapping memory locations, you'd get some kind of weird hybrid conjoined twin result program. and with those being buggy, that could also prompt more incorrect copying and just general weirdness, like how you'd call someone with a conjoined twin extra leg a "mutant" as well, perhaps
