Power-Programmierung

home *** CD-ROM | disk | FTP | other *** search

/ Power-Programmierung / CD2.mdf / c / library / xplatfrm / tierra / readme.t1 < prev next >

Wrap

Text File | 1992-04-26 | 36.1 KB | 796 lines

/* READMET 28-10-91 documentation for the Tierra Simulator */ /** Tierra Simulator V3.0: Copyright (c) 1991 Thomas S. Ray **/ sccsid: @(#)READMET 1.3 10/7/91 This file contains the following sections: 1) LICENSE AGREEMENT 2) WHAT THIS PROGRAM IS 3) RELATED SOFTWARE (IMPORTANT) 4) QUICK START (UNIX AND DOS VERSIONS) 5) RUNNING TIERRA 5.1) Startup 5.2) The Assembler/Disassembler 5.3) The Standard Output 5.4) The Birth-Death Output 5.5) The Genebank Output 5.6) The Interrupt Handler 5.7) Using the Turbo Debugger as a Frontend 5.8) Restarting an Old Run 6) LISTING OF DISTRIBUTION FILES 7) SOUP_IN PARAMETERS 8) THE ANCESTOR & WRITING A CREATURE 8.1) The Ancestor 8.2) Writing a Creature 9) IF YOU WANT TO MODIFY THE SOURCE CODE 9.1) Creating a Frontend 9.2) Creating New Instruction Sets 9.3) Creating New Slicer Mechanisms 9.4) Creating a Sexual Model 9.5) Creating a Multi-cellular Model 10) KNOWN BUGS 11) IF YOU HAVE PROBLEMS 11.1) Problems with Installation 11.2) Problems Running Tierra 1) LICENSE AGREEMENT /* * Tierra Simulator V3.0: Copyright (c) 1991 Thomas S. Ray * * by Tom Ray, ray@brahms.udel.edu (the bulk of the code) * Tom Uffner, tom@genie.slhs.udel.edu (rework of genebanker & assembler) * Dan Pirone, cocteau@life.slhs.udel.edu (the interrupt handler) * Marc Cygnus, cygnus@udel.edu (connections to the ALmond monitor) * * This code and documentation is copyrighted and is not in the public domain. * All rights reserved. This package may be freely copied and distributed * without fees, subject to the following restrictions: * * - This notice may not be removed or altered. * * - You may not try to make money by distributing the package or by using the * process that the code creates. * * - You may not prevent others from copying it freely. * * - You may not distribute modified versions without clearly documenting your * changes and notifying the principal author. * * - The origin of this software must not be misrepresented, either by * explicit claim or by omission. Since few users ever read sources, * credits must appear in the documentation. * * - Altered versions must be plainly marked as such, and must not be * misrepresented as being the original software. Since few users ever read * sources, credits must appear in the documentation. * * - The University and the authors are not responsible for the * consequences of use of this software, no matter how awful, even if they * arise from flaws in it. * * - Neither the name of the University, nor the authors of * the code may be used to endorse or promote products derived from this * software without specific prior written permission. * * - The provision of support and software updates is at our discretion. * * Please contact Tom Ray (full address below) if you have * questions or would like an exception to any of the above restrictions. * * If you make changes to the code, or have suggestions for changes, * let us know! If we use your suggestion, you will receive full credit * of course. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED * WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. * * Tom Ray * University of Delaware * School of Life & Health Sciences * Newark, Delaware 19716 * ray@tierra.slhs.udel.edu * ray@life.slhs.udel.edu * ray@brahms.udel.edu * 302-451-2281 (FAX) * 302-451-2753 (Phone) */ 2) WHAT THIS PROGRAM IS This problem is under very active development. The source code in the ftp site will probably be updated on a roughly weekly basis. We urge you to pick up the latest version frequently if you use the program. Very significant improvements are in the works. The C source code creates a virtual computer and its operating system, whose architecture has been designed in such a way that the executable machine codes are evolvable. This means that the machine code can be mutated (by flipping bits at random) or recombined (by swapping segments of code between algorithms), and the resulting code remains functional enough of the time for natural (or presumably artificial) selection to be able to improve the code over time. Along with the C source code which generates the virtual computer, we provide four programs written in the assembler code of the virtual computer. One of these was written by a human and does nothing more than make copies of itself in the RAM of the virtual computer. The other three evolved from the first, and are included to illustrate the power of natural selection. The virtual machine is an emulation of a MIMD (multiple instruction stream, multiple data stream) computer. This is a massively parallel computer in which each processor is capable of executing a sequence of operations distinct from the other processors. The parallelism is only emulated by time slicing, but there really are numerous virtual CPUs. One CPU will be created and assigned to each ``creature'' (self-replicating algorithm) living in the RAM of the virtual computer. The RAM of the virtual computer is known as the ``soup''. The operating system of the virtual computer provides memory management and timesharing services. It also provides control for a variety of factors that affect the course of evolution: three kinds of mutation rates, disturbances, the allocation of CPU time to each creature, the size of the soup, etc. In addition, the operating system provides a very elaborate observational system that keeps a record of births and deaths, sequences the code of every creature, and maintains a genebank of successful genomes. The operating system also provides facilities for automating the ecological analysis, that is, for recording the kinds of interactions taking place between creatures. The version of the software currently being distributed is considered to be a research grade implementation. This means two things: 1) It is under very rapid development, and is not bug free. 2) We have chosen to go with modifiability and modularity over speed of execution. If you find bugs in the code, please report them to us. By the time you find them and report them, we may have eliminated them, and would be able to provide you with a fixed version. If not, we will be able to fix the bug, and would like to make the fix available to other users. We have chosen modifiability over speed primarily because we know that the current version of the virtual computer is very poorly designed, except with respect to the features that make it evolvable. Specifically, consider that one third of the present instruction set is taken up by pushing and popping from the stack; there are only two inter-register moves, ax to bx and cx to dx; dx isn't used for anything; there is no I/O; and there is no way of addressing a data segment (in the original version, dx was used to set the template size, but that has been abandoned). In August, 100% of the original virtual CPU code was replaced, with new code that does exactly the same thing. However, the new code is written in a generalized way that will make it trivial to alter the machine architecture. With the new implementation of the virtual computer, it will be possible for anyone to painlessly swap in their favorite CPU architecture and instruction set, and their innovation will be seamlessly embedded within the heart of the elaborate observational software. Knowing how bad the original design was, there was a temptation to fix it when the virtual computer was reworked, but the original implementation was retained for historical reasons. In spite of its shortcomings, life proliferated in the environment that it created. Things should get interesting as we improve the architecture. The new organization of the code should make that easy. The bulk of the code and documentation was written by Tom Ray, whose address is listed at the end of this file. Substantial contributions have been made by Tom Uffner, tom@genie.slhs.udel.edu, who has been reworking the genebanker. Dan Pirone, cocteau@life.slhs.udel.edu, has written the interrupt handler and is now working on a frontend for the DOS release. Marc Cygnus, cygnus@udel.edu, developed the ALmond monitor, a separate piece of software that displays activity in a running Tierra (see below). The behavior of this software is described in the following publications: Ray, T. S. 1991. ``Is it alive, or is it GA?'' Proceedings of the 1991 International Conference on Genetic Algorithms, Eds. Belew, R. K., and L. B. Booker, San Mateo, CA: Morgan Kaufmann, 527-534. Ray, T. S. 1991. ``An approach to the synthesis of life.'' Artificial Life II, Santa Fe Institute Studies in the Sciences of Complexity, vol. XI, Eds. Farmer, J. D., C. Langton, S. Rasmussen, & C. Taylor, Redwood City, CA: Addison-Wesley, 371-408. Ray, T. S. 1991. ``Population dynamics of digital organisms.'' Artificial Life II Video Proceedings, Ed. C.G. Langton, Redwood City, CA: Addison Wesley. Ray, T. S. In Press. ``Evolution and optimization of digital organisms.'' 1990 IBM Supercomputing Competition: Large Scale Computing Analysis and Modeling Conference Proceedings, Ed. H. Brown, University of Georgia Press. This research was also reported in the August 10 issue of Science News, the August 27 issue of the New York Times in the Science Times section, and the April issue of Technology Review. 3) RELATED SOFTWARE (IMPORTANT) The Tierra simulator is the central piece of a growing set of programs. The accessory programs aid in observing the results of Tierra runs. We have rushed to make the Tierra source available, however, the related software has not been placed in the ftp site yet. We hope to have the other programs in the ftp site within the next few weeks. When they are available, you will want to select one or both of the following: 3.1) The Beagle Explorer which graphically displays the output that Tierra saves to disk. Beagle runs only on DOS systems, and while the heart of the source code is available, Beagle uses the Greenleaf DataWindows interface, and that source can not be distributed (available from Greenleaf Software, 16479 Dallas Parkway, Bent Tree Tower Two, Suite 570, Dallas, Texas, 75248, phone: 214-248-2561). Beagle would normally be distributed in the executable form. Beagle is currently configured only for the CGA or VGA graphics modes, but can be extended on request, in time. A "pre-release" version of Beagle in already in the ftp site in the directory /tierra/beagle. 3.2) The ALmond Monitor which displays activity in a running Tierra simulator. ALmond runs as a simultaneous but independent process (from Tierra) on the same or on a seperate machine, and establishes network socket communication with Tierra. ALmond can be attached to and detached from a running Tierra simulator without interrupting the simulation. ALmond runs only on unix systems supporting X Windows. The entire ALmond source code is available. Almond was developed and tested on Sun 3 and Sun 4 machines. It was developed under X11R4 by Marc Cygnus. 4) QUICK START (UNIX AND DOS VERSIONS) UNIX QUICK START (for DOS see below) 4.1) You should have a directory containing the source code and two subdirectories: tiedat and geneban1 The tiedat directory is where a record of births and deaths will be written The geneban1 directory contains the initial genomes used to innoculate the soup, and the genebanker will save new genomes to this directory. 4.2) You must compile the assember/disassembler, arg, and the simulator, tierra. Two executable files, ccarg and cctierra are included which perform the compilation. You may have to alter the flags for your system. Just type ccarg, then type cctierra to get the programs compiled. There is also a Makefile include which is preferable, if it works on your system. If you can use the Makefile, type: make, and follow instructions. 4.3) You must assemble the initial genomes, as binaries are not portable. To do this, go into the geneban1 directory and type: ../arg c 0080.gen 80 0080aaa.tie ../arg c 0045.gen 45 0045aaa.tie This will create the two binary files 0080.gen and 0045.gen which contain two creatures that you can use to innoculate the soup, the ancestor 0080aaa and a parasite that evolved from the ancestor, 0045aaa. You can check to see if this worked by disassembling the two genomes, by typing: ../arg x 0080.gen aaa ../arg x 0045.gen aaa This will create the two ascii files 0080aaa and 0045aaa. Compare them to the originals, 0080aaa.tie and 0045aaa.tie. Before you start a run, copy 0080.gen to 0080gen.ori and copy 0045.gen to 0045gen.ori, in order to have virgin copies for use later when you start another run. cp 0045.gen 0045gen.ori cp 0080.gen 0080gen.ori 4.4) Go back to the source code directory and examine the file soup_in. This file contains all of the parameters that control the run. It is currently set up to innoculate the soup with one cell of genotype 0080aaa, and to run for 50 million instructions in a soup of 60,000 instructions. 4.5) Run the simulator by typing: tierra or: tierra & (to run it in the background) or: tierra > tieout & (to run it in background, and save the output in a file called tieout) 4.6) When the run is over, if you want to start a new run, you should clean up the genebank, because the simulator will read in all genomes in the genebank at startup. The best way to do this is to go into the geneban1 directory and remove all .gen and .tmp files, and then copy the backup version of the 0080.gen file: cd geneban1 rm *.gen rm *.tmp cp 0080gen.ori 0080.gen cp list80 list DOS QUICK START (for UNIX see above) 4.1) You should have a directory containing the source code and two subdirectories: tiedat and geneban1 The tiedat directory is where a record of births and deaths will be written The geneban1 directory contains the initial genomes used to innoculate the soup, and the genebanker will save new genomes to this directory. 4.2) You must compile the assember/disassembler, arg, and the simulator, tierra. We include the two Turbo C V 2.0 project files: tierra.prj and arg.prj. If you are using a Borland C++ file you will have to make your own .prj file, listing the files in the .prj files that we have included. Compile these projects using the large memory model. Put the executables in the path. 4.3) You must assemble the initial genomes, as binaries are not portable. To do this, go into the geneban1 directory and type: arg c 0080.gen 80 0080aaa.tie arg c 0045.gen 45 0045aaa.tie This will create the two binary files 0080.gen and 0045.gen which contain two creatures that you can use to innoculate the soup, the ancestor 0080aaa and a parasite that evolved from the ancestor, 0045aaa. You can check to see if this worked by disassembling the two genomes, by typing: arg x 0080.gen aaa arg x 0045.gen aaa This will create the two ascii files 0080aaa and 0045aaa. Compare them to the originals, 0080aaa.tie and 0045aaa.tie. Before you start a run, copy 0080.gen to 0080gen.ori and copy 0045.gen to 0045gen.ori, in order to have virgin copies for use later when you start another run. copy 0045.gen 0045gen.ori copy 0080.gen 0080gen.ori 4.4) Go back to the source code directory and examine the file soup_in. This file contains all of the parameters that control the run. It is currently set up to innoculate the soup with one cell of genotype 0080aaa, and to run for 50 million instructions in a soup of 60,000 instructions. You will need a text editor to do this. If you use a regular word processor, be sure that you write the file back out as a plain ASCII text file. 4.5) Run the simulator by typing: tierra 4.6) When the run is over, if you want to start a new run, you should clean up the genebank, because the simulator will read in all genomes in the genebank at startup. The best way to do this is to go into the geneban1 directory and remove all .gen and .tmp files, and then copy the backup version of the 0080.gen file: cd geneban1 del *.gen del *.tmp copy 0080gen.ori 0080.gen copy list80 list 5) RUNNING TIERRA This section has the following sub-sections: 5.1) Startup 5.2) The Assembler/Disassembler 5.3) The Standard Output 5.4) The Birth-Death Output 5.5) The Genebank Output 5.6) The Interrupt Handler 5.7) Using the Turbo Debugger as a Frontend 5.8) Restarting an Old Run 5.1) Startup The first steps in running Tierra are described briefly above. One must place the genomes in the geneban1 directory, and one must have created the tiedat directory to receive the output of birth and death data. The genome files are supplied in the form of ASCII assembler code files. These must be assembled into binary form to be able to execute on the virtual machine. If you type arg, the assembler will give you a brief listing of assembler options. More complete documentation of the assembler follows: 5.2) The Assembler/Disassembler This documentation was written by Tom Uffner. A troff version is included in arg.1 Arg(1) USER COMMANDS Arg(1) NAME arg - genbank archive utility SYNOPSIS arg c|r[vo12...9] afile size file1 [file2...] arg x|t[vo12...9] afile [gen1 [gen2...]] DESCRIPTION The arg utility is used to manipulate the genebank archives that are used by tierra(1). It is used to assemble or dis- sasemble tierra code, list the genomes contained in a file, and also to convert between the old and new file formats. The arg commands are: c - create afile and add genomes in file1...filen r - replace in afile (or add to end) genomes in file1...filen x - extract entire contents or specified genomes from afile t - list entire contents or specified genomes in afile The optional modifiers are: v - verbose output o - old. will cause c & r to expect an old-style genome file rather than assembly code, and x to produce old format rather than disassembled listing, has no effect on t. 1,2...9 - instruction set (defaults to INST == 1) Where filen and afile are any legal filenames, genn is a 3 character genome label, and size is a decimal integer. (Note that tierra(1) expects archives to have names consisting of 4 digits, and an extension of .gen, .tmp, or .mem. FILES GenebankPath/nnnn.gen permanantly saved genomes GenebankPath/nnnn.tmp genomes from periodic saves GenebankPath/nnnn.mem genomes swapped to disk SEE ALSO An Approach to the Synthesis of Life tierra(1), ov(1X), beagle(1DOS), genio(3), arg(5) BUGS Genome extraction and internal search functions could be faster, and will be in the next release. Tierra, V 3.0 Last change: 7 October 1991 2 5.3) The Standard Output When Tierra runs it produces output to the console that looks like this: Using instruction set (INST) = 1 sizeof(Instruction) = 1 sizeof(struct cell) = 180 sizeof(struct mem_fr) = 16 60000 bytes allocated for soup 108000 bytes allocated for cells 8000 bytes allocated for mem_fr tsetup: arrays allocated without error beginning of GetNewSoup seed = 686777517 init of soup complete GetNewSoup: about to read 80 instructions of cell 0 InstExeC = 0 Generations = 0 NumCells = 1 Sun Oct 6 15:31:57 1991 RateMut = 4787 RateMovMut = 1280 RateFlaw = 25600 num_gen = 1 num_genq = 0 num_genl = 1 AverageSize = 80 tsetup: soup gotten extract: about to save genome 0080aao = 8 InstExeC = 1 Generations = 3 NumCells = 265 Sun Oct 6 15:33:05 1991 births = 828 deaths = 564 AvgPop = 256 AvgSize = 79 RateMut = 6615 RateMovMut = 1264 RateFlaw = 25280 num_gen = 2 num_genq = 151 num_genl = 152 AverageSize = 79 MaxGenPop = 80aaa = 150 MaxGenMem = 80aaa = 150 InstExeC = 2 Generations = 5 NumCells = 298 Sun Oct 6 15:34:17 1991 births = 825 deaths = 792 AvgPop = 318 AvgSize = 80 RateMut = 7628 RateMovMut = 1280 RateFlaw = 25600 num_gen = 2 num_genq = 163 num_genl = 164 AverageSize = 80 MaxGenPop = 80aaa = 147 MaxGenMem = 80aaa = 147 extract: about to save genome 0080abq = 7 extract: about to save genome 0080acv = 7 extract: about to save genome 0080aew = 8 extract: about to save genome 0080adh = 6 extract: about to save genome 0080abk = 7 InstExeC = 3 Generations = 8 NumCells = 338 Sun Oct 6 15:35:25 1991 births = 808 deaths = 768 AvgPop = 318 AvgSize = 80 RateMut = 8652 RateMovMut = 1280 RateFlaw = 25600 num_gen = 7 num_genq = 179 num_genl = 180 AverageSize = 80 MaxGenPop = 80aaa = 127 MaxGenMem = 80aaa = 127 extract: about to save genome 0081aab = 7 extract: about to save genome 0079aab = 7 extract: about to save genome 0080abp = 7 InstExeC = 4 Generations = 10 NumCells = 259 Sun Oct 6 15:36:35 1991 births = 781 deaths = 860 AvgPop = 318 AvgSize = 80 RateMut = 6630 RateMovMut = 1280 RateFlaw = 25600 num_gen = 10 num_genq = 184 num_genl = 185 AverageSize = 80 MaxGenPop = 80aaa = 92 MaxGenMem = 80aaa = 92 extract: about to save genome 0080ads = 6 extract: about to save genome 0080aei = 6 extract: about to save genome 0080aab = 7 InstExeC = 5 Generations = 13 NumCells = 315 Sun Oct 6 15:37:44 1991 births = 828 deaths = 772 AvgPop = 314 AvgSize = 80 RateMut = 8064 RateMovMut = 1280 RateFlaw = 25600 num_gen = 13 num_genq = 206 num_genl = 207 AverageSize = 80 MaxGenPop = 80aaa = 101 MaxGenMem = 80aaa = 101 The meaning of each different kind of information is described below: > Using instruction set (INST) = 1 Because we are likely to proliferate instruction sets in the near future, the system lets us know which one it is using. > sizeof(Instruction) = 1 > sizeof(struct cell) = 180 > sizeof(struct mem_fr) = 16 The size in bytes of each of the main structures, of which the system will allocate large arrays at startup. > 60000 bytes allocated for soup > 108000 bytes allocated for cells > 8000 bytes allocated for mem_fr The total number of bytes used for each of the three main arrays of structures. > tsetup: arrays allocated without error Statement indicating that the arrays were allocated without error. > beginning of GetNewSoup Statement indicating that the program is entering the GetNewSoup() function. > seed = 686777517 A record of the seed of the random number generator used in this run. This can be used to repeat the run if desired. > init of soup complete A statement indicating that the soup has been initialized. > GetNewSoup: about to read 80 instructions of cell 0 A statement indicating that the system is innoculating the soup with a creature of size 80. There will be a comparable line for every creature used in innoculating the soup at startup. > InstExeC = 0 Generations = 0 NumCells = 1 Sun Oct 6 15:31:57 1991 > RateMut = 4787 RateMovMut = 1280 RateFlaw = 25600 > num_gen = 1 num_genq = 0 num_genl = 1 AverageSize = 80 > tsetup: soup gotten These lines indicate the starting conditions of several variables which will be explained below. > extract: about to save genome 0080aao = 8 This line indicates that the genotype 0080aao crossed one of the frequency thresholds set in the soup_in file, SavThrMem or SavThrPop, and that there were eight adult creatures of this genotype in the soup at the threshold frequency. This genotype has been assigned a permanent name and is being saved to disk in the 0080.gen file in the geneban1 directory. > InstExeC = 1 Generations = 3 NumCells = 265 Sun Oct 6 15:33:05 1991 > births = 828 deaths = 564 AvgPop = 256 AvgSize = 79 > RateMut = 6615 RateMovMut = 1264 RateFlaw = 25280 > num_gen = 2 num_genq = 151 num_genl = 152 AverageSize = 79 > MaxGenPop = 80aaa = 150 MaxGenMem = 80aaa = 150 A statement of this form is printed after every million instructions executed by the system. See the plan() function in the bookeep.c module for more details on this. InstExeC = 1 tells us that one million instructions have been executed in this run. Generations = 3 tells us that roughly three generations of creatures have passed during this run. NumCells = 265 tells us that there were 265 adult cells (and a roughly equal number of daughter cells) at this point in the run. Sun Oct 6 15:33:05 1991 tells us the time and date at this point in the run. births = 828 tells us that during the last million instructions, there were 828 births. deaths = 564 tells us that during the last million instructions, there were 564 deaths. AvgPop = 256 tells us that during the last million instructions the average population was 256 adult cells. AvgSize = 79 tells us that during the last million instructions the average adult cell size was 79 instructions. RateMut = 6615 tells us that the actual average background (cosmic ray) mutation rate for the upcoming million instructions will be one mutation per 6615/2 instructions exectued. RateMovMut = 1264 tells us that the actual average move mutation rate (copy error) for the upcoming million instructions will be one mutation for every 1264/2 instructions copied. RateFlaw = 25280 tells us that the actual average flaw rate for the upcoming million instructions will be one flaw for every 25280/2 instructions exectued. The reason that these numbers represent twice the average mutation rates is that they are used to set the range of a uniform random variate determining the interval between mutations. num_gen = 2 tells us that there are two permanent genotype names saved to disk. num_genq = 151 tells us that there are 151 distinct genotype names and genomes stored in the RAM genebank. num_genl = 152 tells us that there are 152 genotype names in the list stored in RAM. AverageSize = 79 tells us that at this time the average size of adult cells is 79 instructions. MaxGenPop = 80aaa = 150 tells us that at this time, the genotype with the largest population is 80aaa, and that it has a population of 150 adult cells. MaxGenMem = 80aaa = 150 tells us that the genotype whose adult cells occupy the largest share of space in the soup is 80aaa, and that it has a population of 150 adult cells. 5.4) The Birth-Death Output During a run, if the DiskOut parameter is non-zero, a record of births and deaths will be written to disk in the path specified by OutPath, to files whose names depend on the BrkupSiz parameter. The format of this file is a bit cryptic, so it will be explained here. The file has either three or four columns of output, depending on whether the GeneBnker parameter is set. Three of the columns remain the same either way: 1) elapsed time since last birth or death event in instructions, output in hexidecimal format. 2) a `b' or a `d' depending on whether this is a birth or a death. 3) the size of the creature in instructions, output in decimal format. If the genebanker is on, then there will be a fourth column containg the three letter code identifying the genotype of the creature. Mutations in appear in the birth-death record as the death of one genotype followed by the birth of another, with an elapsed time of zero between the two events. What makes the file cryptic, and also compact, is that columns are implied to be identical in successive records unless otherwise indicated. Only the first column, elapsed time since last record, must be printed on every line, and only the first record must have all three or four columns. Therefore, if there is a series of successive births, only the first birth record in the series will contain the b. Notice that at the beginning of the file, there will generally be many lines with just one column, because at the outset, all records are of births of the same size and genotype. The record of births and deaths is read by the Beagle program, and converted into a variety of graphic displays: frequency distributions over time, phase diagrams of the interactions between pairs of sizes or genotypes, or diversity and related measures over time. 5.5) The Genebank Output If the GeneBnker parameter is set to a non-zero value, then as each creature is born, its genome will be sequenced and compared to that of its mother. If they are identical, the daughter will be assigned the same name as the mother. If they are different, the genome of the daughter will be compared to the same size genomes held in the RAM genebank. If the daughter genome is found in the bank, it will be given the same name as the matching genome in the bank. If the daughter genome is not found in the RAM genebank, it will be compared to any same size genomes stored on the disk that are not in the RAM genebank. If the daughter genome is found in the disk genebank, ti will be given the same name as the matching genome in the bank. If the daughter genome does not match the mother or any genome in either the RAM or disk banks, then it will be assigned an arbitrary but unique three letter code for identification. The genebank keeps track of the frequency of each size class and each genotype is the soup. If a genotype exceeds one of the two genotype frequency thresholds, SavThrMem or SavThrPop, its assigned name will be made permanent, and it will be saved to disk. Genotypes are grouped into individual files on the basis of size. For example, all permanent genotypes of size 80 will be stored together in binary form in a file called 0080.gen. When the simulator comes down, or when the state of the simulator is saved periodically during a run, all genotypes present in the soup which have not been assigned permanent names will be stored in files with a .tmp extension. For example, all temporary genotype names of size 45 would be stored in binary form in a file called 0045.tmp. The binary genebank files can be examined with the assembler-disassembler arg (see the relevant documentation, section 5.2 above). Also, the Beagle Explorer program contains utilities for examing the structure of genomes. One tool condenses the code by pulling out all instructions using templates, which can reveal the pattern of control flow of the algorithm. Another function allows one genome to be used as a probe of another, to compare the similarities and differences between genomes, or to look for the presence of a certain sequence in a genome. 5.6) The Interrupt Handler When Tierra is running in the foreground it is possible to interrupt it on either DOS or UNIX, usually by typing Ctrl C (^C). When you do this you will get a brief message listing your options, which looks something like this: TIERRA: traped a signal! # 2 @ 128519 TIERRA: port 4072 TIERRA: traped a signal! # 2 @ 128519 TIERRA: port 4072 Variable | siZe info | Save soup | save & Quit | Exit | Continue | {v,z,s,q,e,c} You must now choose one of the options by typing one of the corresponding letters: vzsqec. When you type the letter, the simulator will either prompt you for more input or do the requested operation. The six options are: Variable: allows you to alter the value of any of the variables in the soup_in file at any point during a run. siZe info: will display some information about creatures of the indicated size. This option is not currently implemented. Save soup: will cause the state of the system to be saved at this point, and then continue the run. save & Quit: will cause the state of the system to be saved at this point, and then exit from the run. Exit: will exit immediately without saving the state of the system. Continue: continue the run. 5.7) Using the Turbo Debugger as a Frontend If you run Tierra under DOS, it is best to run Tierra under the Turbo Debugger (386 virtual version). This provides a very flexible and handy frontend, and does not degrade the performance of the system. If you try to run Tierra under the regular (non-virtual) debugger, you will probably have memory problems unless you run a very small soup. I suggest the following setup for viewing the run: Startup the debugger with the tierra program. Then do the following: Ctrl F7 InstExe (Enter) Ctrl F7 NumCells (Enter) This will place the variables InstExe and NumCells into the watch window (2) at the bottom of the screen. InstExe records the number of instructions executed by the system (see the structure definition in tierra.h). NumCells records the current number of cells. Then type: Ctrl S TimeSlice (Enter) This will search for the TimeSlice routine which is the central loop of the simulator. This is the best place to watch the action. Now place the cursor on the line: ce = cells + ci; and type F4. This will cause the simulator to start up, and then stop execution at the current line. Now place the cursor on the variable cells on the current line, and type: Ctrl I Ctrl R 0, 400 (Enter) F5 This will allow you to inspect the cells array, which is where the most useful information is contained. See the tierra.h module for the structure definitions. You should adjust the size of the cells array window so that it does not overlap the watch window. You do this by using the Scroll Lock and arrow keys. Now type F9 to continue the run. Whenever you want to see how things are going type Ctrl Break to stop the run. It is likely that the CPU window will pop up. The best thing to do when this happens is to type Alt 2 followed by Alt 3, which will cause the windows you want to see to be above the CPU window. 5.8) Restarting an Old Run When you start Tierra by typing tierra to the prompt, you may provide an optional command line argument, which is the name of the file to use as input. This is the file that contains the startup parameters. The default file name is soup_in. When a simulator comes down, and periodically during a run, the complete state of the machine is saved so that the simulator can start up again where it left off. In order to do this you must have the simulator read the file soup_out on startup. This means that you must type: tierra soup_out That is all there is to it. It appears that this does not work for the version of the current distribution. Check again later. We have this working in the newer version currently under development. 11) IF YOU HAVE PROBLEMS 11.1) Problems with Installation Read the installation instructions carefully. Where we present alternative methods, try them all. If it still doesn't work, please let us know. We would like to help people with installation, and make sure that our instructions are clear. If you are using a compiler or machine we have not tested, we may not be able to help you, but we want to accomodate these additional conditions. We would like to help you find a solution and incorporate the solution in future releases. 11.2) Problems Running Tierra Read all of the README files. You may find the answer there. If a problem still persists, get a new copy of the source code out of the ftp site. It is likely that the source code will be updated on a roughly weekly basis as we continue to improve the program. By the time you are sure there is a problem, we may already have fixed it and placed a fix in the ftp site. If the problem still persists after you have tested the latest version of the software, let us know about the problem. We would like to fix it.