home *** CD-ROM | disk | FTP | other *** search
/ Collection of Hack-Phreak Scene Programs / cleanhpvac.zip / cleanhpvac / TIERRA40.ZIP / DOC / TIERRA.DOC < prev    next >
Text File  |  1992-09-11  |  202KB  |  4,404 lines
  1. /* TIERRA.DOC  9-9-92  documentation for the Tierra Simulator */
  2. /* Tierra Simulator V4.0: Copyright (c) 1991, 1992 Tom Ray & Virtual Life */
  3.  
  4. This file contains the following sections:
  5.  
  6. 1)  LICENSE AGREEMENT
  7. 2)  WHAT THIS PROGRAM IS, PUBLICATIONS, NEWS
  8. 3)  RELATED SOFTWARE (IMPORTANT)
  9. 4)  QUICK START   <-------------- You might want to start here! 
  10.   4.1) DOS QUICK START
  11.   4.2) UNIX QUICK START
  12. 5)  RUNNING TIERRA
  13.   5.1) Startup
  14.   5.2) The Assembler/Disassembler
  15.   5.3) The Birth-Death Output
  16.   5.4) The Genebank Output
  17.   5.5) Restarting an Old Run
  18.   5.6) The User Interface
  19.     5.6.1) The Basic Interface
  20.       5.6.1.1) The Basic Screen
  21.       5.6.1.2) The Menu Options
  22.         5.6.1.2.1) The Size Histogram
  23.         5.6.1.2.2) The Memory Histogram
  24.         5.6.1.2.3) The Genotype Histogram
  25.         5.6.1.2.4) The Size Class Information Display
  26.         5.6.1.2.5) The Virtual Debugger
  27.         5.6.1.2.6) The Genome Injector
  28.     5.6.2) The Standard Output
  29.     5.6.3) The tierra.log file
  30. 6)  LISTING OF DISTRIBUTION FILES
  31. 7)  SOUP_IN PARAMETERS (IMPORTANT)
  32. 8)  THE INSTRUCTION SETS
  33.   8.1) Synopsis of the Four Sets
  34.   8.2) Details of Set 1
  35.   8.3) New Features in Sets 2 through 4
  36. 9)  THE ANCESTOR & WRITING A CREATURE
  37.   9.1) The Ancestor
  38.   9.2) Writing a Creature
  39. 10) IF YOU WANT TO MODIFY THE SOURCE CODE
  40.   10.1) Creating a Frontend
  41.   10.2) Creating New Instruction Sets
  42.   10.3) Creating New Slicer Mechanisms
  43.   10.4) Creating a Sexual Model
  44.   10.5) Creating a Multi-cellular Model
  45. 11) CONFIGURATION AT COMPILE TIME (configur.h)
  46. 12) KNOWN BUGS
  47. 13) IF YOU HAVE PROBLEMS
  48.   13.1) Problems with Installation
  49.   13.2) Problems Running Tierra
  50. 14) REGISTRATION & MAILING LISTS
  51.  
  52. 1)  LICENSE AGREEMENT
  53.  
  54. /* 
  55.  * Tierra Simulator V4.0: Copyright (c) 1990, 1991, 1992 Thomas S. Ray
  56.  * 
  57.  * by Tom Ray, ray@brahms.udel.edu ray@santafe.edu (the bulk of the code)
  58.  *    Dan Pirone, cocteau@life.slhs.udel.edu (frontend, overhaul, sex)
  59.  *    Tom Uffner, tom@genie.slhs.udel.edu (rework of genebanker & assembler)
  60.  * 
  61.  * If you purchased this program on disk, thank you for your support.  If 
  62.  * you obtained the source code through the net or friends, we invite you to
  63.  * contribute an amount that represents the program's worth to you.  You may
  64.  * make a check in US dollars payable to Virtual Life, and mail the check to
  65.  * one of the two addresses listed below.
  66.  * 
  67.  * This license agreement has two parts: 
  68.  * 
  69.  * 1) The source code, documentation, and the beagle.exe file can be freely
  70.  *    distributed.
  71.  * 
  72.  * 2) The executables (the .exe files in DOS) are for sale and can not be
  73.  *    freely distributed (with the exception of the beagle.exe file).
  74.  *    Executables (binaries) on any platform (Unix, Mac, Amiga, DOS, etc.)
  75.  *    can not be freely distributed.
  76.  * 
  77.  * These two points are elaborated below:
  78.  * 
  79.  * 1) The source code, documentation, and the beagle.exe file can be freely
  80.  *    distributed.
  81.  * 
  82.  * The source code and documentation is copyrighted, all rights reserved.
  83.  * The source code, documentation, and the beagle.exe file may be freely
  84.  * copied and distributed without fees (contributions welcome), subject to
  85.  * the following restrictions:
  86.  * 
  87.  * - This notice may not be removed or altered.
  88.  * 
  89.  * - You may not try to make money by distributing the package or by using the
  90.  *   process that the code creates.
  91.  * 
  92.  * - You may not prevent others from copying it freely.
  93.  * 
  94.  * - You may not distribute modified versions without clearly documenting your
  95.  *   changes and notifying the principal author.
  96.  * 
  97.  * - The origin of this software must not be misrepresented, either by
  98.  *   explicit claim or by omission.  Since few users ever read sources,
  99.  *   credits must appear in the documentation.
  100.  * 
  101.  * - Altered versions must be plainly marked as such, and must not be
  102.  *   misrepresented as being the original software.  Since few users ever read
  103.  *   sources, credits must appear in the documentation.
  104.  * 
  105.  * 2) The executables (the .exe files in DOS) are for sale and can not be
  106.  *    freely distributed (with the exception of the beagle.exe file).
  107.  *    Executables (binaries) on any platform (Unix, Mac, Amiga, DOS, etc.)
  108.  *    can not be freely distributed.
  109.  * 
  110.  * The executables (the .exe files in DOS) are copyrighted, all rights
  111.  * reserved.  You should treat this software just like a book.  This means
  112.  * that this software (the executables) may be used by any number of people
  113.  * and may be freely moved from one computer to another so long as the program
  114.  * is not used by more than one person at a time.  This applies to binaries on
  115.  * any platform.
  116.  * 
  117.  *   The following provisions also apply in both cases 1 and 2: 
  118.  * 
  119.  * - Virtual Life and the authors are not responsible for the consequences of
  120.  *   use of this software, no matter how awful, even if they arise from flaws
  121.  *   in it.
  122.  * 
  123.  * - Neither the name of Virtual Life, nor the authors of the code may be used
  124.  *   to endorse or promote products derived from this software without
  125.  *   specific prior written permission.
  126.  * 
  127.  * - The provision of support and software updates is at our discretion.
  128.  * 
  129.  * Please contact Tom Ray (full address below) if you have questions or would
  130.  * like an exception to any of the above restrictions.
  131.  * 
  132.  * If you make changes to the code, or have suggestions for changes,
  133.  * let us know!  If we use your suggestion, you will receive full credit
  134.  * of course.
  135.  * 
  136.  * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
  137.  * WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
  138.  * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
  139.  *
  140.  *    Tom Ray
  141.  *
  142.  *    Virtual Life              (September through December)
  143.  *    P.O. Box 625
  144.  *    Newark, Delaware  19715
  145.  *
  146.  *    School of Life & Health Sciences
  147.  *    University of Delaware
  148.  *    Newark, DE  19716
  149.  *
  150.  *    ray@udel.edu (email)
  151.  *    302-831-2753 (Phone)
  152.  *    302-831-2281 (Fax)
  153.  *
  154.  *    or
  155.  *
  156.  *    Santa Fe Institute        (January through August)
  157.  *    1660 Old Pecos Trail
  158.  *    Suite A
  159.  *    Santa Fe, NM 87501
  160.  *
  161.  *    ray@santafe.edu (email)
  162.  *    505-984-8800 (Phone)
  163.  *    505-982-0565 (Fax)
  164.  */
  165.  
  166. 2)  WHAT THIS PROGRAM IS, PUBLICATIONS, NEWS
  167.  
  168.      The C source code creates a virtual computer and its operating system,
  169. whose architecture has been designed in such a way that the executable
  170. machine codes are evolvable.  This means that the machine code can be mutated
  171. (by flipping bits at random) or recombined (by swapping segments of code
  172. between algorithms), and the resulting code remains functional enough of the
  173. time for natural (or presumably artificial) selection to be able to improve
  174. the code over time.
  175.  
  176.      Along with the C source code which generates the virtual computer, we
  177. provide several programs written in the assembler code of the virtual
  178. computer.  Some of these were written by a human and does nothing more than
  179. make copies of itself in the RAM of the virtual computer.  The others evolved
  180. from the first, and are included to illustrate the power of natural selection.
  181.  
  182.      The virtual machine is an emulation of a MIMD (multiple instruction
  183. stream, multiple data stream) computer.  This is a massively parallel computer
  184. in which each processor is capable of executing a sequence of operations
  185. distinct from the other processors.  The parallelism is only emulated by
  186. time slicing, but there really are numerous virtual CPUs.  One CPU will be
  187. created and assigned to each ``creature'' (self-replicating algorithm)
  188. living in the RAM of the virtual computer.  The RAM of the virtual computer
  189. is known as the ``soup''.
  190.  
  191.      The operating system of the virtual computer provides memory management
  192. and timesharing services.  It also provides control for a variety of factors
  193. that affect the course of evolution: three kinds of mutation rates,
  194. disturbances, the allocation of CPU time to each creature, the size of the
  195. soup, the spatial distribution of creatures, etc.  In addition, the operating
  196. system provides a very elaborate observational system that keeps a record of
  197. births and deaths, sequences the code of every creature, and maintains a
  198. genebank of successful genomes.  The operating system also provides facilities
  199. for automating the ecological analysis, that is, for recording the kinds of
  200. interactions taking place between creatures.
  201.  
  202.      The version of the software currently being distributed is considered
  203. to be a research grade implementation.  This means two things: 1) It is
  204. under very rapid development, and may not be completely bug free.  2) We have
  205. chosen to go with modifiability and modularity over speed of execution.
  206.  
  207.      If you find bugs in the code, please report them to us.  By the time
  208. you find them and report them, we may have eliminated them, and would be
  209. able to provide you with a fixed version.  If not, we will be able to fix
  210. the bug, and would like to make the fix available to other users.
  211.  
  212.      We have chosen modifiability over speed primarily because we know that
  213. the original version of the virtual computer was very poorly designed, except
  214. with respect to the features that make it evolvable.  Specifically, consider
  215. that one third of the original instruction set is taken up by pushing and
  216. popping from the stack; there are only two inter-register moves, ax to bx and
  217. cx to dx; dx isn't used for anything (in the initial version, dx was used to
  218. set the template size, but that has been abandoned); there are no moves
  219. between CPU registers and RAM; there is no I/O; and there is no way of
  220. addressing a data segment.
  221.  
  222.      In August 1991, 100% of the original virtual CPU code was replaced, with
  223. new code that does exactly the same thing.  However, the new code is written
  224. in a generalized way, a meta-virtual computer, that makes it trivial to
  225. alter the machine architecture.  With the new implementation of the virtual
  226. computer, it is possible for anyone to painlessly swap in their favorite
  227. CPU architecture and instruction set, and their innovation will be seamlessly
  228. embedded within the heart of the elaborate observational software.  Knowing
  229. how bad the original design was, there was a temptation to fix it when the
  230. virtual computer was reworked, but the original implementation was retained
  231. for historical reasons.  In spite of its shortcomings, life proliferated in
  232. the environment that it created.  Things should get interesting as we improve
  233. the architecture.  The new organization of the code should make that easy.
  234.  
  235.      In August of 1992, the modifications of the previous August bore fruit
  236. as three new instruction sets were implemented.  These are documented in some
  237. detail below, and in general, eliminate most of the problems discussed
  238. above.
  239.  
  240.      The bulk of the code and documentation was written by Tom Ray, whose
  241. address is listed at the end of this file.  Substantial contributions have
  242. been made by: Dan Pirone, cocteau@santafe.edu, has been involved in
  243. the Tierra project since the Fall of 1990.  Dan began working full
  244. time on Tierra in February 1992.  Dan has written the user interface,
  245. and has been working on a phylogeny tool that should be completed by
  246. October of 1992.  Tom Uffner, tom@genie.slhs.udel.edu, reworked the genebanker
  247. and assembler/disassembler in the Fall of 1991.  Marc Cygnus,
  248. cygnus@udel.edu, developed the ALmond monitor, a separate piece
  249. of software that displays activity in a running Tierra (see below).
  250.  
  251.      The behavior of this software is described in the following publications:
  252.  
  253. Ray, T. S.  1991.  ``Is it alive, or is it GA?''
  254. Proceedings of the 1991 International Conference on Genetic Algorithms,
  255. Eds. Belew, R. K., and L. B. Booker, San Mateo, CA: Morgan Kaufmann, 527-534.
  256.  
  257. Ray, T. S.  1991.  ``An approach to the synthesis of life.''
  258. Artificial Life II, Santa Fe Institute Studies in the Sciences of
  259. Complexity, vol. XI, Eds. Farmer, J. D., C. Langton, S. Rasmussen, &
  260. C. Taylor, Redwood City, CA: Addison-Wesley, 371-408.
  261.  
  262. Ray, T. S.  1991.  ``Population dynamics of digital organisms.''
  263. Artificial Life II Video Proceedings,  Ed. C.G. Langton,
  264. Redwood City, CA: Addison Wesley.
  265.  
  266. Ray, T. S.  1991.  ``Evolution and optimization of digital organisms.''
  267. Scientific Excellence in Supercomputing: The IBM 1990 Contest Prize
  268. Papers, Eds. Keith R. Billingsley, Ed Derohanes, Hilton Brown, III.
  269. Athens, GA, 30602, The Baldwin Press, The University of Georgia.
  270.  
  271. Ray, T. S.  1992.  ``Evolution ecology and optimization of digital organisms.''
  272. Santa Fe Institute working paper (available in the ftp site as tierra.tex
  273. and tierra.ps).
  274.  
  275. The Tierra Simulator has been widely reported in the media.  Below is a
  276. list of most of the national or international reports that I am aware of.
  277. If you know of some news report not on this list, please send me a hard
  278. copy.
  279.  
  280. Nature (John Maynard Smith, UK) February 27, 1992: ``Byte-sized evolution.
  281. ...we badly need a comparative biology.  So far, we have been able to study
  282. only one evolving system and we cannot wait for interstellar flight to
  283. provide us with a second.  If we want to discover generalizations about
  284. evolving systems, we will have to look at artificial ones.  Ray's study is a
  285. good start.''
  286.  
  287. Science (Mitchell Waldrop, USA) August 21, 1992: ``Artificial Life's Rich
  288. Harvest, Startlingly realistic simulations of organisms, ecosystems, and
  289. evolution are unfolding on computer screens as researchers try to recreate
  290. the dynamics of living things.''
  291.  
  292. New York Times (Malcolm Browne, USA) August 27, 1991: ``Lively Computer
  293. Creation Blurs Definition of Life.  Software forms, obeying Darwin's rules,
  294. vie to avoid the `reaper'.''
  295.  
  296. Whole Earth Review (Steven Levy, USA) Fall 1992: ``Artificial Life, The
  297. Quest for a New Creation.''  Reprinted from a book of the same name published
  298. by Pantheon Books.
  299.  
  300. Science News (John Travis, USA) August 10, 1991: ``Digital Darwinism:
  301. Electronic Ecosystem.  Evolving `life' flourishes and surprises in a
  302. novel electronic world''.
  303.  
  304. Nature (Laurence Hurst & Richard Dawkins, UK) May 21, 1992:
  305. ``Life in a test tube.''
  306.  
  307. Scientific American (John Rennie, USA) January 1992: ``Cybernetic Parasites...
  308. Tierra... has been hailed as the most sophisticated artificial-life program
  309. yet developed...''
  310.  
  311. New Scientist (Roger Lewin, UK) February 22, 1992: ``Life and death in a
  312. digital world.  No one can turn back the evolutionary clock, but we can
  313. follow the fate of a rich menagerie of artificial organisms as they evolve
  314. in a model world.''
  315.  
  316. The Economist (Anon, UK) January 4, 1992: ``The meaning of `life'.
  317. In order to understand the origin of life, scientists are switching from the
  318. chemistry set to the computer.  In the process, they are beginning to
  319. understand what it means to be alive.''
  320.  
  321. Release 1.0 (Esther Dyson, US) April 28, 1992: ``Artificial Worlds: A
  322. Field Scientist in Tierra Cognita.''
  323.  
  324. Guardian (Jocelyn Paine, UK) January 9, 1992: ``Unravelling the loop in the
  325. primordial soup.  Tierran machine code is so adaptable it survives.  Jocelyn
  326. Paine charts the evolution of artificial life within the computer.''
  327.  
  328. Asahi (Katsura Hattori, Japan) September 15, 1992: Title in Japanese
  329. characters.
  330.  
  331. Actuel (Ariel Kyrou, France) April 1992: ``Visite Guidee Aux Extremes De
  332. La Science: La Vie Artificielle.  Etes-vous pr\^{e}ts \`{a} entrer dans
  333. l'univers vertigineux de la vie artificielle?  Un champ scientifique tout neuf
  334. sur lequel se penchent les grosses t\^{e}tes et les Nobel de labos
  335. am\'{e}ricains.''
  336.  
  337. The Chronicle of Higher Education (David Wilson, USA) December 4, 1991:
  338. ``Approaching Artificial Life on a Computer.  Survival-of-the-fittest
  339. electronic organisms dramatically illustrate Darwinian principles.''
  340.  
  341. Mikrobitti (Pekka Tolonen, Finland) November 1991: ``Olemmeko humanoiden
  342. biologinen koe?  Tierra simuloi el\"{a}m\"{a}\"{a}.''
  343.  
  344. Europeo (Giovanni Caprara, Italy) September 1991: ``Anche il computer ha
  345. fatto un figlio.  Un biologo americano ha creato un software capace di
  346. elaborare programmi che si evolvono da soli.''
  347.  
  348. GenteMoney (Riccardo Orizio, Italy) November 1991: ``Cos\`{\i} ho dato
  349. la vita al software.''
  350.  
  351. Computerworld (Michael Alexander, USA) September 30, 1991: ``Tierra adds to
  352. evolutionary studies.  A computerized world created on an IBM PC could
  353. have real-world benefits for scientists.''
  354.  
  355. Sueddeutsche Zeitung (Konrad Peters, Germany) October 21, 1991:
  356. ``Die Evolution im Computer.  `K\"{u}nstliches Leben' hilft Biologen und
  357. Informatikern auf die Spr\"{u}nge.''
  358.  
  359. Super Interessante (Anon, Brazil) November 1991: ``A vida dentro do
  360. computador.''
  361.  
  362. Technology Review (Susan Scheck, USA) April 14, 1991: ``Is It Live Or Is
  363. It Memory?''
  364.  
  365. Corriere Della Sera (Giovanni Capara, Italy) August 28, 1991: ``Pronto in
  366. USA il programma che si riproduce.  Il computer `padre' crea vita
  367. informatica.''
  368.  
  369. Fakta (Tom Ottmar, Norway) March 1992: ``Den Lever!  En `skabning', der
  370. best\aa r af nuller og \'{e}nere, er vokset ud af indamaden p\aa \ en
  371. computer og er blevet en videnskabelig sensation i USA.''
  372.  
  373. Associated Press (Theresa Humphrey, USA) October 1991: ``Bringing life to
  374. computer.  U of D biologist's program is self-replicating, shows evolution.''
  375.  
  376. Hovedomr\aa det (Jakob Skipper, Denmark) December 6, 1990: ``Kunstigt liv.
  377. Nu kommer det kunstige liv.  En voksende gruppe af dataloger, biologer,
  378. fysikere, psykologer og mange andre forskere efterlinger p\aa \ computer
  379. det naturlige liv.''
  380.  
  381. 3)  RELATED SOFTWARE (IMPORTANT)
  382.  
  383.      The Tierra simulator is the central piece of a growing set of programs.
  384. The accessory programs aid in observing the results of Tierra runs.  You will
  385. want to select one or both of the following:
  386.  
  387.   3.1) The Beagle Explorer which graphically displays the output that Tierra
  388.    saves to disk.  Beagle runs only on DOS systems, and while the heart of
  389.    the source code is available, Beagle uses the Greenleaf DataWindows
  390.    interface, and that source can not be distributed (available from
  391.    Greenleaf Software, 16479 Dallas Parkway, Bent Tree Tower Two, Suite 570,
  392.    Dallas, Texas, 75248, phone: 214-248-2561).  Beagle would normally be
  393.    distributed in the executable form.  Once you have the executables, you
  394.    will be able to run them on your PC, and you will not need Greenleaf.
  395.    You only need Greenleaf if you plan to modify the source code.  Beagle is
  396.    currently configured only for the CGA or VGA graphics modes, but can be
  397.    extended on request, in time.  Beagle executables are now available on disk
  398.    from Virtual Life, or in the same ftp site as the Tierra source code, in
  399.    the directory: /beagle.  If you pick up the Beagle executables from
  400.    the ftp site, remember to trasfer the files in binary mode.
  401.  
  402.   3.2) The ALmond Monitor which displays activity in a running Tierra
  403.    simulator.  ALmond runs as a simultaneous but independent process (from
  404.    Tierra) on the same or on a seperate machine, and establishes network
  405.    socket communication with Tierra.  ALmond can be attached to and detached
  406.    from a running Tierra simulator without interrupting the simulation.
  407.    ALmond runs only on unix systems supporting X Windows.  The entire ALmond
  408.    source code is available.  Almond was developed and tested on Sun 3 and Sun
  409.    4 machines.  It was developed under X11R4 by Marc Cygnus.  Dan Pirone
  410.    has now taken over ALmond development. 
  411.  
  412. 4)  QUICK START 
  413.  
  414.      The steps required to run the system on DOS and UNIX are slightly
  415. different, so there are two sets of instructions listed below.
  416.  
  417.   4.1) DOS QUICK START
  418.  
  419.      If you obtained the Tierra software on disk, the installation program
  420. will take care of steps 1 - 3, so you can skip to step 4.  If you
  421. obtained the software over the net, start with step 1. 
  422.  
  423.       step 1)  You should have a directory containing the executables and
  424. source code and five subdirectories: td, gb1, gb2, gb3, and gb4.  The td
  425. directory is where a record of births and deaths will be written.  The gb
  426. directories contain the initial genomes used to innoculate the soup and the
  427. opcode maps.  The genebanker will save new genomes to the gb directories.
  428. There is a gb directory for each of the four instruction sets.
  429.  
  430.       step 2)  You must compile the assember/disassembler, arg, and the
  431. simulator, tierra.  We include the two Turbo C V 2.0 project files:
  432. tierra.prj and arg.prj.  If you are using a more recent version of the
  433. compiler, such as Borland C++, you must use the Borland project tool to
  434. create a binary project file.  Just list the files listed in the two ascii
  435. project files that are provided.  Compile these projects using the large
  436. memory model.  Put the executables in the path.
  437.  
  438.       step 3)  You must assemble the initial genomes, as binaries are not
  439. portable.  To do this, go into the gb1 directory and type:
  440.  
  441. arg c 0080.gen 80 0080aaa.tie
  442.  
  443. This will create the binary file 0080.gen which contains a creature that you
  444. can use to innoculate the soup, the ancestor 0080aaa.  You can check to see if
  445. this worked by disassembling the genome, by typing:
  446.  
  447. arg x 0080.gen aaa
  448.  
  449. This will create the ascii file 0080aaa.  Compare it to the original,
  450. 0080aaa.tie (it will not be exactly the same).  Before you start a run, copy
  451. 0080.gen to 0080gen.vir, in order to have a virgin copy for use later when
  452. you start another run.
  453.  
  454. copy 0080.gen 0080gen.vir
  455.  
  456.      You can do the same for each of the four gb directories (gb1, gb2, gb3,
  457. and gb4).  Be sure to assemble the genomes listed at the ends of the
  458. corresponding soup_in files (soup_in1, soup_in2, soup_in3, soup_in4).
  459.  
  460.       step 4)  Go back to the source code directory and examine the file
  461. soup_in1.  This file contains all of the parameters that control the run.  It
  462. is currently set up to innoculate the soup with one cell of genotype 0080aaa,
  463. and to run for 500 million instructions in a soup of 50,000 instructions.  You
  464. will need a text editor if you want to modify this file.  If you use a regular
  465. word processor, be sure that you write the file back out as a plain ASCII text
  466. file.
  467.  
  468.       step 5)  Run the simulator by typing: tierra
  469.  
  470.       step 6)  When the run is over, if you want to start a new run, you
  471. should clean up the genebank, because the simulator will read in all genomes
  472. in the genebank at startup.  The best way to do this is to use the batch files
  473. that are provided for this purpose: clr1.bat, clr2.bat, clr3.bat and clr4.bat.
  474. Since we are discussing a run of instruction set 1, use clr1.bat, by typing
  475. clr1 to the DOS prompt.  The batch file will take care of the cleanup.
  476.  
  477.      If you wish to use a cumulative genebank in successive runs, use the
  478. corresponding cumulative clear batch files: cclr1.bat, cclr2.bat, cclr3.bat,
  479. and cclr4.bat.
  480.  
  481.   4.2) UNIX QUICK START
  482.  
  483.       step 1)  You should have a directory containing the source code and five
  484. subdirectories: td and gb1, gb2, gb3 and gb4.  The td (tiedat) directory is
  485. where a record of births and deaths will be written.  The gb (genebank)
  486. directories contain the initial genomes used to innoculate the soup and the
  487. opcode map, and the genebanker will save new genomes to these directories.
  488.  
  489.       step 2)  You must compile the assember/disassembler, arg, and the
  490. simulator, tierra.  There is a Makefile included to perform the compilation.
  491. This Makefile needs to be edited to comment in the lines for your particular
  492. hardware.  It has been tested on Sun 3, Sun 4, IBM RS6000, Silicon Graphics
  493. Personal Iris and Indigo, DEC DS5000, and NeXT.  If you can use the Makefile,
  494. type: make, and follow instructions.
  495.  
  496.       step 3)  You must assemble the initial genome, as binaries are not
  497. portable.  To do this, go into the gb1 directory and type:
  498.  
  499. ../arg c 0080.gen 80 0080aaa.tie
  500.  
  501. This will create the binary file 0080.gen which contains a creature that you
  502. can use to innoculate the soup, the ancestor 0080aaa.  You can check to
  503. see if this worked by disassembling the genome, by typing:
  504.  
  505. ../arg x 0080.gen aaa
  506.  
  507. This will create the ascii file 0080aaa.  Compare it to the original,
  508. 0080aaa.tie (they will not be exactly the same).  Before you start a run,
  509. copy 0080.gen to 0080gen.vir, in order to have virgin copies for use later
  510. when you start another run.
  511.  
  512. cp 0080.gen 0080gen.vir
  513.  
  514.      You can do the same for each of the four gb directories (gb1, gb2, gb3,
  515. and gb4).  Be sure to assemble the genomes listed at the ends of the
  516. corresponding soup_in files (soup_in1, soup_in2, soup_in3, soup_in4).
  517.  
  518.       step 4)  Go back to the source code directory and examine the file
  519. soup_in1.  This file contains all of the parameters that control the run.  It
  520. is currently set up to innoculate the soup with one cell of genotype 0080aaa,
  521. and to run for 500 million instructions in a soup of 50,000 instructions.
  522.  
  523.       step 5)  Run the simulator by typing:
  524.            tierra
  525.        or: tierra > /dev/null &  (to run it in the background
  526.                      a Log file can be created by setting
  527.                      the soup_in variable Log = 1)
  528.  
  529.      In order to run tierra in the background, you must compile it with:
  530.  
  531. #define FRONTEND STDIO
  532.  
  533.      If you will run Tierra in the foreground, we recommend that you use:
  534.  
  535. #define FRONTEND BASIC
  536.  
  537.      These definitions are made in the configur.h file.
  538.  
  539.       step 6)  When the run is over, if you want to start a new run, you
  540. should clean up the genebank.  The best way to do this is to use the
  541. Unix script files that have been provided for this purpose (clr1, clr2,
  542. clr3 and clr4).  You must make the clr# files executable by changing their
  543. protection:
  544.  
  545. chmod +x clr1
  546.  
  547.      Then all you have to do is type ``clr1'' to the prompt, and the
  548. shell script will take care of the cleanup.
  549.  
  550.      If you wish to use a cumulative genebank in successive runs, use the
  551. cumulative clear files (cclr1, cclr2, cclr3, cclr4).  You must also make
  552. sure that they are executable:
  553.  
  554. chmod +x cclr1
  555.  
  556. 5)  RUNNING TIERRA
  557.  
  558.      This section has the following sub-sections:
  559.  
  560.   5.1) Startup
  561.   5.2) The Assembler/Disassembler
  562.   5.3) The Birth-Death Output
  563.   5.4) The Genebank Output
  564.   5.5) Restarting an Old Run
  565.   5.6) The User Interface
  566.     5.6.1) The Basic Interface
  567.       5.6.1.1) The Basic Screen
  568.       5.6.1.2) The Menu Options
  569.         5.6.1.2.1) The Size Histogram
  570.         5.6.1.2.2) The Memory Histogram
  571.         5.6.1.2.3) The Genotype Histogram
  572.         5.6.1.2.4) The Size Class Information Display
  573.         5.6.1.2.5) The Virtual Debugger
  574.         5.6.1.2.6) The Genome Injector
  575.     5.6.2) The Standard Output
  576.     5.6.3) The tierra.log file
  577.  
  578.   5.1) Startup
  579.  
  580.      The first steps in running Tierra are described briefly above.  One must
  581. place the genomes and the opcode map in the gb directory, and one must have
  582. created the td directory to receive the output of birth and death data.  The
  583. genome files are supplied in the form of ASCII assembler code files.  These
  584. must be assembled into binary form to be able to execute on the virtual
  585. machine.  If you type arg, the assembler will give you a brief listing of
  586. assembler options.  More complete documentation of the assembler follows:
  587.  
  588.   5.2) The Assembler/Disassembler
  589.  
  590.      This documentation was written by Tom Uffner.
  591.  
  592. Arg(1)                   USER COMMANDS                     Arg(1)
  593.  
  594. NAME
  595.      arg - genbank archive utility
  596.  
  597. SYNOPSIS
  598.      arg c|r[v12...9] afile size file1 [file2...]
  599.      arg x|t[v12...9] afile [gen1 [gen2...]]
  600.  
  601. DESCRIPTION
  602.      The arg utility is used to manipulate the genebank  archives
  603.      that  are used by tierra(1).  It is used to assemble or dis-
  604.      sasemble tierra code, list the genomes contained in a  file,
  605.      and also to convert between the old and new file formats.
  606.  
  607.      The arg commands are:
  608.  
  609.           c - create afile and add genomes in file1...filen
  610.  
  611.           r - replace  in  afile  (or  add  to  end)  genomes  in
  612.                file1...filen
  613.  
  614.           x - extract entire contents or specified  genomes  from
  615.                afile
  616.  
  617.           t - list entire contents or specified genomes in afile
  618.  
  619.      The optional modifiers are:
  620.  
  621.           v - verbose output
  622.  
  623.           1,2...9 - instruction set (defaults to Format: parameter
  624.                      of ascii source or to INST = 1)
  625.  
  626.      Where filen and afile are any legal filenames, genn is  a  3
  627.      character genome label, and size is a decimal integer. (Note
  628.      that tierra(1) expects archives to have names consisting  of
  629.      4 digits, and an extension of .gen, or .tmp.
  630.  
  631. FILES
  632.      GenebankPath/nnnn.gen permanantly saved genomes
  633.      GenebankPath/nnnn.tmp genomes from periodic saves
  634.  
  635. SEE ALSO
  636.      An Approach to the Synthesis of Life
  637.      tierra(1), ov(1X), beagle(1DOS), genio(3), arg(5)
  638.  
  639. BUGS
  640.      Genome extraction and internal  search  functions  could  be
  641.      faster, and will be in the next release.
  642.  
  643. Tierra, V 4.0      Last change: 8 September 1992                  2
  644.  
  645. Please remember that this new form of arg needs the file opcode.map
  646. to be in the current working directory.  Arg ALWAYS reads the file
  647. opcode.map for the mappings for assembling/disassembling genebank
  648. archives.
  649.  
  650.   5.3) The Birth-Death Output
  651.  
  652.      During a run, if the DiskOut parameter is non-zero, a record of births
  653. and deaths will be written to disk in the path specified by OutPath, to
  654. files whose names depend on the BrkupSiz parameter.  The format of this
  655. file is a bit cryptic, so it will be explained here.  The file has either
  656. three or four columns of output, depending on whether the GeneBnker parameter
  657. is set.  Three of the columns remain the same either way: 1) elapsed time
  658. since last birth or death event in instructions, output in hexidecimal format.
  659. 2) a `b' or a `d' depending on whether this is a birth or a death.  3) the size
  660. of the creature in instructions, output in decimal format.  If the genebanker
  661. is on, then there will be a fourth column containg the three letter code
  662. identifying the genotype of the creature.  Mutations appear in the
  663. birth-death record as the death of one genotype followed by the birth of
  664. another, with an elapsed time of zero between the two events.
  665.  
  666.      What makes the file cryptic, and also compact, is that columns are
  667. implied to be identical in successive records unless otherwise indicated.
  668. Only the first column, elapsed time since last record, must be printed on
  669. every line, and only the first record must have all three or four columns.
  670. Therefore, if there is a series of successive births, only the first birth
  671. record in the series will contain the b.  Notice that at the beginning of
  672. the file, there will generally be many lines with just one column, because
  673. at the outset, all records are of births of the same size and genotype.
  674.  
  675.      The record of births and deaths is read by the Beagle program, and
  676. converted into a variety of graphic displays: frequency distributions over
  677. time, phase diagrams of the interactions between pairs of sizes or genotypes,
  678. or diversity and related measures over time.  The source code for reading and
  679. interpreting the record of births and deaths is in the bread.c module of the
  680. Beagle source code.
  681.  
  682.   5.4) The Genebank Output
  683.  
  684.      If the GeneBnker parameter is set to a non-zero value, then as each
  685. creature is born, its genome will be sequenced and compared to that of its
  686. mother.  If they are identical, the daughter will be assigned the same name
  687. as the mother.  If they are different, the genome of the daughter will be
  688. compared to the same size genomes held in the RAM genebank.  If the daughter
  689. genome is found in the bank, it will be given the same name as the matching
  690. genome in the bank.  If the daughter genome is not found in the RAM genebank,
  691. it will be compared to any same size genomes stored on the disk that are not
  692. in the RAM genebank.  If the daughter genome is found in the disk genebank,
  693. it will be given the same name as the matching genome in the disk genebank,
  694. and that genome will be brougt back into RAM from the disk.  If the
  695. daughter genome does not match the mother or any genome in either the RAM
  696. or disk banks, then it will be assigned an arbitrary but unique three letter
  697. code for identification.
  698.  
  699.      The genebanker keeps track of the frequency of each size class and each
  700. genotype in the soup.  If a genotype exceeds one of the two genotype frequency
  701. thresholds, SavThrMem or SavThrPop, its assigned name will be made permanent,
  702. and it will be saved to disk in a .gen file.  Genotypes are grouped into
  703. individual files on the basis of size.  For example, all permanent genotypes
  704. of size 80 will be stored together in binary form in a file called 0080.gen.
  705.  
  706.      When the simulator comes down, or when the state of the simulator is
  707. saved periodically during a run, all genotypes present in the soup which have
  708. not been assigned permanent names will be stored in files with a .tmp
  709. extension.  For example, all temporary genotype names of size 45 would be
  710. stored in binary form in a file called 0045.tmp.
  711.  
  712.      The parameter RamBankSiz places a limit on how many genotypes will be
  713. stored in RAM.  If there are more than RamBankSiz genotypes in the RAM bank,
  714. if any of them have permanent genotype names but have gone extinct in the
  715. soup, they will be swapped out to disk into a .gen file.  Genotypes without
  716. permanent names are deleted when they go extinct.  If the number
  717. of living genotypes in the soup is greater than RamBankSiz, then the value
  718. of RamBankSiz is essentially ignored (actually it is treated as if the
  719. value were equal to the number of living genotypes).  Living genotypes are
  720. never swapped out to disk, only extinct ones.  Under DOS, the parameter
  721. RamBankSiz is of little importance, because it is raised if there are more
  722. living genotypes and if the simulator uses all 640K of RAM, RamBankSiz is
  723. lowered so that genotypes will be swapped out to avoid running out of
  724. memory.  Under Unix, this parameter does determine how many genotypes
  725. will be held in the rambank, as long as there are not more than RamBankSiz
  726. living genotypes.
  727.  
  728.      The binary genebank files can be examined with the assembler-disassembler
  729. arg (see the relevant documentation, section 5.2 above).  Also, the Beagle
  730. Explorer program contains utilities for examing the structure of genomes.
  731. One tool condenses the code by pulling out all instructions using templates,
  732. which can reveal the pattern of control flow of the algorithm.  Another
  733. function allows one genome to be used as a probe of another, to compare
  734. the similarities and differences between genomes, or to look for the presence
  735. of a certain sequence in a genome.  A completely separate tool called probe
  736. will scan the genebank pulling out any genomes that meet a variety of
  737. criteria that the user may define.
  738.  
  739.   5.5) Restarting an Old Run
  740.  
  741.      When you start Tierra by typing tierra to the prompt, you may provide
  742. an optional command line argument, which is the name of the file to use as
  743. input.  This is the file that contains the startup parameters.  The default
  744. file name is soup_in.  When a simulator comes down, and periodically during
  745. a run, the complete state of the machine is saved so that the simulator can
  746. start up again where it left off.  In order to do this you must have the
  747. simulator read the file soup_out on startup.  This means that you must type:
  748.  
  749. tierra soup_out
  750.  
  751.      That is all there is to it.
  752.  
  753.   5.6) The User Interface
  754.  
  755.      There are two interfaces available for Tierra.  The source code and
  756. executables are shipped in a form that is configured for the nicer of the
  757. two, the Basic interface.  However, if you make the appropriate modifications
  758. to the configur.h file, you can recompile with the Standard Output interface
  759. (useful for running Tierra in the background).  Documentation for each of
  760. these interfaces follows.
  761.  
  762.     5.6.1) The Basic Interface
  763.  
  764.       5.6.1.1) The Basic Screen
  765.  
  766.      The Basic frontend features a dynamic interface to the simulation.
  767. The screen area is divided into five basic areas:
  768.  
  769. The STATS area consists of the top two lines of the screen.  This area
  770. displays several important variables, whose values are updated after every
  771. birth:
  772.  
  773. > InstExec  = 75,529993  Cells =  387  Genotypes =  191  Sizes =  23
  774. > Extracted = 0080aad @ 8
  775.  
  776. InstExec  = 75,529993 tells us that the simulation has executed a total of
  777. 75,529,993 instructions.  Cells =  387 tells us that there are presently
  778. 387 adult cells living in the soup.  Genotypes =  191 tells us that there
  779. are presently 191 distinct genotypes of adult cells living in the soup.
  780. Sizes =  23 tells us that there are presently 23 distinct sizes of adult
  781. cells living in the soup.  Extracted =  0080aad @ 8 tells us that the last
  782. genotype to cross one of the frequency thresholds (SavThrMem or SavThrPop)
  783. and get saved to disk and get a permanent name was a creature of size 80
  784. with the name aad, which had a population of 8 adult cells when it crossed
  785. the threshold.
  786.  
  787. The PLAN area displays the values of several variables, whose values are
  788. updated every million instructions:
  789.  
  790. > InstExeC      =     75  Generations  =    188  Thu Apr 30 11:49:46 1992
  791. >     NumCells  =    356  NumGenotypes =    178  NumSizes  =     21
  792. >     AvgSize   =     76  NumGenDG     =    171  NumGenRQ  =    239
  793. >     AvgPop    =    376  Births       =   1007  Deaths    =   1034
  794. >     RateMut   =  10966  RateMovMut   =   1216  RateFlaw  =  97280
  795. >     MaxGenPop =     21  (0078aak)    MaxGenMem =     21 (0078aak)
  796.  
  797. InstExeC = 75 tells us that this set of variables was written when
  798. the simulation had executed 75 million instructions.  Generations = 188
  799. tells us that the simulation had run for about 188 generations at this time.
  800. Thu Apr 30 11:49:46 1992 tells us the actual time and date that this data
  801. was printed.
  802.  
  803. NumCells = 356 tells us that there were 356 adult cells living in the soup.
  804. NumGenotypes = 178 tells us that there were 178 distinct genotypes of adult
  805. cells living in the soup.  NumSizes = 21 tells us that there were 21 distinct
  806. sizes of adult cells living in the soup.
  807.  
  808. AvgSize = 76 tells us that during the last million instructions, the
  809. average size was 76.  NumGenDG = 171 tells us that there are 171 genotypes
  810. that have received permanent names and been saved to disk as .gen files in
  811. the genebank directory gb.  NumGenRQ = 239 tells us that at this time there
  812. were 239 distinct genotypes being held in the genebank in RAM (the ramqueue).
  813.  
  814. AvgPop = 376 tells us that during the last million instructions, the
  815. population was 376 adult cells.  Births = 1007 tells us that during the last
  816. million instructions, there were 1007 births.  Deaths = 1034 tells us that
  817. during the last million instructions, there were 1034 deaths.
  818.  
  819.      RateMut = 10966 tells us that the actual average background (cosmic ray)
  820. mutation rate for the upcoming million instructions will be one mutation per
  821. 10966/2 instructions exectued.  RateMovMut = 1216 tells us that the actual
  822. average move mutation rate (copy error) for the upcoming million instructions
  823. will be one mutation for every 1216/2 instructions copied.  RateFlaw = 97280
  824. tells us that the actual average flaw rate for the upcoming million
  825. instructions will be one flaw for every 97280/2 instructions exectued.  The
  826. reason that these numbers represent twice the average mutation rates is that
  827. they are used to set the range of a uniform random variate determining the
  828. interval between mutations.
  829.  
  830.      MaxGenPop = 21 (0078aak) tells us that at this time, the genotype
  831. with the largest population is 0078aak, and that it has a population of 21
  832. adult cells.  MaxGenMem = 21 (0078aak) tells us that the genotype whose
  833. adult cells occupy the largest share of space in the soup is 0078aak, and
  834. that it has a population of 21 adult cells.
  835.  
  836. The MESSAGE area, for state changes, and Genebank data.  This area serves
  837. many purposes - memory reallocation messages, Genebank information displays,
  838. large interface prompts (eg changing a soup_in variable ).
  839.  
  840. The ERROR area at the second to the last line of the screen.
  841. All simulation errors and exit conditions are passed through this area.
  842.  
  843. The HELP area at the last line of the screen.  This area provides
  844. suggestions for keystroke navigation.  Under DOS it will usually look
  845. like this:
  846.  
  847. >                  Press any Key for menu ...
  848.  
  849. Under Unix it will generally look like this:
  850.  
  851. >                  Press Interupt Key for menu ...
  852.  
  853. Under DOS, pressing any key will get you the menu, under Unix, pressing the
  854. interrupt key (usually Ctrl C) will get you the menu, described in the
  855. next section.
  856.  
  857.       5.6.1.2) The Menu Options
  858.  
  859.      Please note that if the Tierra simulator is started with two arguments,
  860. it will come up with the menu system activated.  The first argument must be
  861. the name of the soup_in file, the second argument is a dummy and anything will
  862. do:  tierra soup_in1 junk
  863.  
  864. The frontend menu looks like this:
  865.  
  866. > TIERRA |  i-info  v-var  s-save  q-save&quit  Q-quit  m-misc c-continue |->
  867.  
  868.       These options allow for rapid IO from the simulation, in a user friendly
  869. format.  The interface allows transition between any data display mode.  The
  870. features are ativated by a single keypress ("Enter/Return" is usually not
  871. needed).
  872.  
  873. The options are: 
  874.  
  875.             i-info  v-var  s-save  q-save&quit  Q-quit  m-misc c-continue |->
  876.  
  877. i-info: will display some information about creatures stored in the Genebank.
  878.      See below for details.
  879.  
  880. v-var: allows you to alter the value of any of the variables in the
  881.      soup_in file at any point during a run.
  882.  
  883. s-save: will cause the state of the system to be saved at this point, and
  884.      then continue the run.
  885.  
  886. q-save&quit: will cause the state of the system to be saved at this point,
  887.      and then exit from the run.
  888.  
  889. Q-quit: will exit immediately without saving the state of the system.
  890.  
  891. m-misc: pulls up the miscellaneous sub-menu
  892.  
  893. c-continue: continue the run.
  894.  
  895. If you press 'i' for info, from the main TIERRA menu, you are able to select
  896. one of the Genebank (GeneBnker = 1) data display modes:
  897.  
  898. > INFO   |  p-plan  s-size_histo g-gen_histo m-mem_histo z-size_query     |->
  899.  
  900. The second line from the top of the screen will change, providing additional
  901. information on the operating system memory use, or the Tierrian memory use.
  902. At the bottom of the screen, a new list of GeneBank data display options are
  903. available.  All of these modes will try to provide as much data as can fit on
  904. the screen.  These modes are detailed below:
  905.  
  906. Hit the c key to continue (to get out of this level of the menu)
  907.  
  908. The options are:
  909.  
  910.            p-plan  s-size_histo g-gen_histo m-mem_histo z-size_query
  911.  
  912. If you press 'p' from the info menu you get the Plan Display mode: 
  913.  
  914. >Now in Plan Display mode, updated every million time steps
  915.  
  916. This provides the normal statistics every million virual time steps
  917. (this is also an easy way to clear the message area):
  918.  
  919. > InstExeC      =    141  Generations  =    363  Thu Mar 26 15:20:28 1992
  920. >     NumCells  =    483  NumGenotypes =    202  NumSizes  =     27
  921. >     AvgSize   =     53  AvgPop       =    471
  922. >     RateMut   =   5426  RateMovMut   =    848  RateFlaw  =  16960
  923. >     NumGenRQ  =    579  NumGenDM     =      0  NumGenDG  =    400
  924. >     births    =   1210  deaths       =   1125
  925. >     MaxGenPop =     48  (0032aah)    MaxGenMem =     48 (0032aah)
  926.  
  927. The meaning of this information is detailed above.
  928.  
  929.         5.6.1.2.1) The Size Histogram
  930.  
  931. If you press 's' from the info menu, the message area will show a histogram
  932. of frequency distributions of the currently living size classes:
  933.  
  934.    13   1      2 | *
  935.    18   3      9 | **
  936.    19   3      4 | *
  937.    20   2      4 | *
  938.    21   1      3 | *
  939.    22   1      4 | *
  940.    27   3      5 | *
  941.    34   2      4 | *
  942.    35   1      4 | *
  943.    36  34     84 | ****************
  944.    37  70    198 | *************************************
  945.    38  33     92 | ******************
  946.    39   7      9 | **
  947.    40  13     25 | *****
  948.    44   1      2 | *
  949.    45   1      2 | *
  950.    46   2      2 | *
  951.    47   1      4 | *
  952.    49   1      2 | *
  953.    54   1      1 | *
  954.    56   2      3 | *
  955.    70  10     13 | ***
  956.    71  21     42 | ********
  957.    72  24     42 | ********
  958.    73   6      6 | **
  959.    74   7     12 | ***
  960.    75   3      3 | *
  961.    77   2      2 | *
  962.    78   6      7 | **
  963.   109   1      2 | *
  964.  
  965. In the above histogram, the left column of numbers is the size class,
  966. the middle column is the number of genotypes of that size class, and the
  967. right column is the number of living adult cells of that size class.
  968.  
  969.         5.6.1.2.2) The Memory Histogram
  970.  
  971. If you press 'm' from the info menu, the message area will show a histogram
  972. of frequency distributions of the currently living size classes, by memory
  973. use:
  974.  
  975.    Size  Memory use (size * freq.)
  976.  
  977.    18   3    180 | *
  978.    19   3     76 | *
  979.    20   2     60 | *
  980.    21   1     63 | *
  981.    22   1    110 | *
  982.    27   3    162 | *
  983.    31   1     31 | *
  984.    33   1     33 | *
  985.    34   2    136 | *
  986.    35   1    105 | *
  987.    36  37   3096 | *****************
  988.    37  69   7141 | *************************************
  989.    38  34   3610 | *******************
  990.    39   7    351 | **
  991.    40  13    960 | *****
  992.    41   1     41 | *
  993.    42   1     42 | *
  994.    43   1     43 | *
  995.    44   1     44 | *
  996.    45   1     90 | *
  997.    46   2     92 | *
  998.    47   1    235 | **
  999.    48   1     48 | *
  1000.    49   1     98 | *
  1001.    50   1     50 | *
  1002.    54   1     54 | *
  1003.    56   2    168 | *
  1004.    66   1     66 | *
  1005.    71  22     42 | *
  1006.    72  25     42 | *
  1007.  
  1008. In the above histogram, the left column of numbers is the size class,
  1009. the middle column is the number of genotypes of that size class, and the
  1010. right column is the amount of memory occupied by living adult cells of that
  1011. size class.
  1012.  
  1013.         5.6.1.2.3) The Genotype Histogram
  1014.  
  1015. If you press 'g' from the info menu,  the message area will show a histogram
  1016. of genotype sizes, by specific genotypes:
  1017.  
  1018. Size      Frequency 
  1019.  
  1020.     18aab      3 | ***
  1021.       aac      6 | ******
  1022.     27aab      2 | **
  1023.       aad      3 | ***
  1024.     35aaa      3 | ***
  1025.     36aam      7 | *******
  1026.       aat     39 | **************************************
  1027.       abb      3 | ***
  1028.     37abb     26 | *************************
  1029.       abp      5 | *****
  1030.       abt      6 | ******
  1031.       acm     23 | **********************
  1032.       acn      4 | ****
  1033.     38abb      5 | *****
  1034.       abc      3 | ***
  1035.     40aaj      3 | ***
  1036.       aal      2 | **
  1037.     47aaa      5 | *****
  1038.     49aaa      2 | **
  1039.     56aac      2 | **
  1040.     70aae      2 | **
  1041.       aaf      2 | **
  1042.     71aac      3 | ***
  1043.       aaj      4 | ****
  1044.       aat      3 | ***
  1045.       aav      6 | ******
  1046.     72aai      2 | **
  1047.       aau      3 | ***
  1048.       aax      4 | ****
  1049.     74aac      4 | ****
  1050.  
  1051. In the above histogram, the left column of numbers is the size and genotype
  1052. class, and the right column is the number of living adult cells of that
  1053. genotype class.
  1054.  
  1055.         5.6.1.2.4) The Size Class Information Display
  1056.  
  1057. If you press 'z' from the info menu, you will be prompted for a 
  1058. specific size class to examine, then you will get a list of the most
  1059. common genotypes of that size, with some statistics on them:
  1060.  
  1061. Gene:    #  Mem Errs   Move  Bits
  1062. aae      4   0   1     39    EX      TC      TP      MF      MT      MB
  1063. aaj      1   0   0      0    EX      TC      TP      MF      MT      MB
  1064. aak      1   0   0      0    EX      TC      TP      MF      MT      MB
  1065. aan      1   0   0      0    EX      TC      TP      MF      MT      MB
  1066. aap      1   0   0      0    EX      TC      TP      MF      MT      MB
  1067. aaq      1   0   0      0    EX      TC      TP      MF      MT      MB
  1068. aat     10   0   2     38    EXsofh  TCsofh  TPs     MF      MT      MBsof
  1069. aau      1   0   0      0    EX      TC      TP      MF      MT      MB
  1070. aaw      1   0   0      0    EX      TC      TP      MF      MT      MB
  1071. aax      2   0   0      0    EX      TC      TP      MF      MT      MB
  1072. aay      1   0   0      0    EX      TC      TP      MF      MT      MB
  1073. aba      1   0   0      0    EX      TC      TP      MF      MT      MB
  1074. abb      1   0   0      0    EX      TC      TP      MF      MT      MB
  1075. abc      1   0   0      0    EX      TC      TP      MF      MT      MB
  1076. abe      1   0   7    146    EX      TC      TP      MF      MT      MB
  1077. abi     61   3   2     38    EXsdofh TCsofh  TPs     MFsof   MTsf    MBsdofh
  1078. abk      1   0   2     38    EX      TC      TP      MF      MT      MB
  1079. abl      1   0   0      0    EX      TC      TP      MF      MT      MB
  1080. abm      1   0   0      0    EX      TC      TP      MF      MT      MB
  1081. abw     17   1   2     38    EXsdofh TCsofh  TPs     MF      MT      MBsdofh
  1082. aby      6   0   1     38    EXsdofh TCsof   TPs     MF      MT      MBsdofh
  1083. acb      2   0   0      0    EX      TC      TP      MF      MT      MB
  1084. acd      1   0   0      0    EX      TC      TP      MF      MT      MB
  1085. ace      1   0   0      0    EX      TC      TP      MF      MT      MB
  1086. acf      1   0   0      0    EX      TC      TP      MF      MT      MB
  1087. acg      4   0   2     38    EX      TC      TP      MF      MT      MB
  1088. ach     13   0   2     38    EXsdofh TCsdofh TPs     MFsdofh MTsdf   MBsdofh
  1089. aci      2   0   2     38    EX      TC      TP      MF      MT      MB
  1090. acj      2   0   0      0    EX      TC      TP      MF      MT      MB
  1091.  
  1092. #    = acutal count, populations of adult cells of this genotype 
  1093. Mem  = is the percent of Soup, occupied by adult cells of this genotype
  1094. Err  = is the number of error flag commited,
  1095. Move = number of instructions moved to daughter cell,
  1096. Bits = Watch bits, defined in section: 7)  SOUP_IN PARAMETERS
  1097.  
  1098. 0 values usually represent cases of insufficient data.
  1099.  
  1100. If you press 'm' for misc, from the main TIERRA menu, you will get the
  1101. miscellaneous sub-menu, which looks like the following in unix:
  1102.  
  1103. > MISC |  H-Histo Logging  I-Inject Gene M-Micro Toggle    |->
  1104.  
  1105. and the following in DOS:
  1106.  
  1107. > MISC |  H-Histo Logging  S-DOS Shell  I-Inject Gene M-Micro Toggle    |->
  1108.  
  1109. When this sub-menu is selected, some information is displayed at the top
  1110. of the screen about what variables are #defined:
  1111.  
  1112. VER=4.00 INST=1 PLOIDY=1  ERROR
  1113.  
  1114. This tells us that this is Version 4.00 of the Tierra program, we are using
  1115. Instruction Set 1, that it is a haploid model (Ploidy = 1), and that error
  1116. checking code is included.
  1117.  
  1118. From this menu, you have the following options:
  1119.  
  1120. H-Histo Logging: if you press the H key, it will toggle the logging of any
  1121. histograms you create to the tierra.log file.
  1122.  
  1123. S-DOS shell: (DOS only) this causes you to exit to the DOS prompt, while the
  1124.      simulator remains in the RAM in suspended animation.  You can now do
  1125.      anything that doesn't require a lot of memory.  Be careful that if you
  1126.      change directories, you come back to the current directories before you
  1127.      exit from the shell.  Also, be careful not to do anything that changes
  1128.      the graphics mode.
  1129.  
  1130. I-Inject Gene: inject a genome of your choice from the genebank into the
  1131.      soup of the running simulator.
  1132.  
  1133. M-Micro Toggle: turn on the virtual debugger.  The debugger has three states:
  1134.      delay, keypress, and off.  In delay mode, the debugger will execute one
  1135.      Tierran instruction per second.  In the keypress mode, the debugger will
  1136.      execute one Tierran instruction per keypress.
  1137.  
  1138. c-continue: exit from this sub-menu.
  1139.  
  1140.         5.6.1.2.5) The Virtual Debugger
  1141.  
  1142. The debugger has three main states: delay, keypress, and off.  In delay mode,
  1143. the debugger will execute one Tierran instruction per second.  In the keypress
  1144. mode, the debugger will execute one Tierran instruction per keypress.  Once
  1145. you have selected your mode, press c to start the simulator again.  You can
  1146. use this tool to step through the genome of a creature, either to see what
  1147. it does, or to debug a creature that you are writing.
  1148.  
  1149. In keypress mode, there are two additional modes.  Given that there is
  1150. usually a population of cells in the soup, the virtual debugger will swap
  1151. from cell to cell as each one gets its time slice.  However, this can be
  1152. disconcerting if one is trying to study the behavior of a particular cell.
  1153. The debugger can be made to follow a single creature using the trace option
  1154. as specified at the bottom of the screen in keypress mode:
  1155.  
  1156.       MICRO  |  T-Track cell  ESC-Main Menu  n-Next Step
  1157.  
  1158. If you hit the T key, you will go into trace mode, and the menu will change
  1159. to:
  1160.  
  1161.       MICRO  |  t-Untrack cell  ESC-Main Menu  n-Next Step
  1162.  
  1163. Now hitting the t key will return to the mode that swaps between cells.
  1164.  
  1165. If you wish to start debugging from the very beginning of a run, you will
  1166. want to start the simulator fresh with the menu activated, so that you can
  1167. start the debugger before the creature has started to run.  This is done by
  1168. giving two arguments when starting Tierra, one must be the name of the
  1169. soup_in file, the second is a dummy argument.  So for example, you should type:
  1170.  
  1171. tierra soup_in1 junk
  1172.  
  1173. The debugger display in keypress mode looks like:
  1174.  
  1175. InstExec  = 11,346072  Cells =  679  Genotypes =  274  Sizes =  26
  1176. VER=4.0 INST=1 PLOIDY=1    MICRO
  1177.  MICRO STEP Mode = keypress
  1178.  
  1179. Cell  1: 55 0045aaa @   12595 Slice=  19  Stack[  12628]
  1180. IP [  12572]( -23    ) = 0x01     nop1         [  12639]
  1181. AX [  30236]                                   [  12595]
  1182. BX [  12632]                                   [     45] <
  1183. CX [      7]                                   [      0]
  1184. DX [      4]                                   [      0]
  1185. Flag = 0                                       [      0]
  1186. Daughter @ 30199  + 45                         [      0]
  1187.                                                [      0]
  1188.                                                [      0]
  1189.  
  1190.       MICRO  |  T-Track cell  ESC-Main Menu  n-Next Step
  1191.  
  1192.      The various components of the display are documented in the following:
  1193.  
  1194. Cell  1: 55 0045aaa @   12595 Slice=  19
  1195.  
  1196.      Each creature has associated with it, a cell structure.  The cell
  1197. structures are organized in a two dimensional array.  Cell  1: 55 tells us
  1198. that the structure for the currently active creature is at location 1,55 in
  1199. the cells array.
  1200.  
  1201.      The currently active creature is 0045aaa whose cell starts at address
  1202. 12595 in the soup.  This creature currently has 19 CPU cycles left in its
  1203. time slice.  Note that when the Slice counts down to zero, the slicer will
  1204. swap in the next creature in the slicer queue, and the debugger will display
  1205. the CPU of the next creature.  Therefore when there are more than one
  1206. creature in the soup, it is hard to follow the activity of a single creature,
  1207. since the debugger will be swapped from creature to creature.  This problem
  1208. can be eliminated by activating the track mode (see above).
  1209.  
  1210. Daughter @ 30199  + 45
  1211.  
  1212.      The currently active creature has allocated a space of 45 instructions
  1213. at address 30199 in the soup, which it presumably will use to make a daughter.
  1214.  
  1215. IP [  12572]( -23    ) = 0x01     nop1
  1216.  
  1217.      The instruction pointer (IP) of the currently active creature is
  1218. presently located at the soup address 12572.  Notice that this address is
  1219. located 23 instruction BEFORE the start of its own cell.  The number in
  1220. parentheses (-23) is the offset of the IP from the start of the cell.  As
  1221. long as the IP is inside the cell, this offset will be displayed without a
  1222. sign.  If the IP is outside of the cell, the offset will be displayed with
  1223. a + or a - sign.  The current offset of -23 means that the instruction pointer
  1224. of this creature is executing the code of some other creature.  In fact
  1225. 0045aaa is a parasite.  The instruction currently being executed is
  1226. represented in the soup by the hex value 0x01.  The assembler mnemonic of this
  1227. instruction is nop1, it is a no-operation.
  1228.  
  1229. AX [  30236]
  1230. BX [  12632]
  1231. CX [      7]
  1232. DX [      4]
  1233.  
  1234.      The four CPU registers of the currently active creature contain the
  1235. values indicated above.  Probably, the AX value is the address where the
  1236. creature is writing in its daughter cell, the BX value is the address that
  1237. it is copying from in its own cell, the CX value is the number of
  1238. instructions of the genome remaining to be copied, and the DX value is the
  1239. size of the last template used.
  1240.  
  1241. Flag = 0
  1242.  
  1243.      This shows the status of the flag register.  This can be used to
  1244. recognize when an instruction has failed, generating an error condition.
  1245.  
  1246. Stack[  12628]
  1247.      [  12639]
  1248.      [  12595]
  1249.      [     45] <
  1250.      [      0]
  1251.      [      0]
  1252.      [      0]
  1253.      [      0]
  1254.      [      0]
  1255.      [      0]
  1256.  
  1257.      The stack of the currently active creature contains the values indicated
  1258. above.  The stack pointer points at the location indicated by the < sign
  1259. (the top of the stack).  The values on the stack probably include the
  1260. address of the instruction pointer (12628) which was pushed on the stack when
  1261. the parasite called the copy procedure of its host, the address of the end
  1262. of the creature (12639), the address of the beginning of the creature
  1263. (12595), and the size of the creature (45).
  1264.  
  1265.       5.6.1.2.6) The Genome Injector
  1266.  
  1267.      The menu system provides a mechanism for injecting genomes into a
  1268. running simulation.  This tool allows a genome from the genebank to be
  1269. injected into the run at the user's command.  The genome must be in a .gen
  1270. file in the path indicated by the GenebankPath soup_in variable.
  1271.  
  1272.      However, there is a function Inject(), in the genebank.c module, which
  1273. takes a pointer to a genome as an argument.  This function can be used to
  1274. inject genomes from any source.  An interesting use of this function would be
  1275. to facilitate migration of genomes between simulations running on separate
  1276. machines, creating an archipelago (this is the basis of the CM5 port
  1277. currently underway).
  1278.  
  1279.     5.6.2) The Standard Output & Interrupt Handler
  1280.  
  1281.      When Tierra is compiled with: #define FRONTEND STDIO, while running it
  1282. produces output to the console that looks something like this:
  1283.  
  1284. Using instruction set (INST) = 1
  1285. TIERRA: LOG = on, Histogram Logging = off 
  1286.  
  1287. sizeof(Instruction)   = 1
  1288. sizeof(Cell)   = 180
  1289. sizeof(MemFr) = 16
  1290.     60000 bytes allocated for soup
  1291.     16380 bytes allocated for cells
  1292.     8000 bytes allocated for MemFr
  1293. tsetup: arrays allocated without error
  1294. beginning of GetNewSoup
  1295. seed = 1
  1296. init of soup complete
  1297. GetNewSoup: loading 0080aaa into cell 0,2
  1298. InstExeC      =      0  Generations  =      0  Wed Apr 29 17:00:06 1992
  1299.     NumCells  =      1  NumGenotypes =      1  NumSizes  =      1
  1300.     AvgSize   =     80  NumGenDG     =      1  NumGenRQ  =      1
  1301.     RateMut   =   6382  RateMovMut   =   1280  RateFlaw  = 102400
  1302. tsetup: soup gotten
  1303. extract: 0080aaa @ 276 v
  1304. InstExeC      =      1  Generations  =      3  Wed Apr 29 17:01:04 1992
  1305.     NumCells  =    376  NumGenotypes =    131  NumSizes  =      8
  1306.     AvgSize   =     79  NumGenDG     =      1  NumGenRQ  =    131
  1307.     AvgPop    =    292  Births       =    995  Deaths    =    620
  1308.     MaxGenPop =    208  (0080aaa)    MaxGenMem =    208 (0080aaa)
  1309.     RateMut   =  12515  RateMovMut   =   1264  RateFlaw  = 101120
  1310. extract: 0080abl @ 8
  1311. InstExeC      =      2  Generations  =      5  Wed Apr 29 17:02:05 1992
  1312.     NumCells  =    380  NumGenotypes =    159  NumSizes  =     12
  1313.     AvgSize   =     79  NumGenDG     =      2  NumGenRQ  =    159
  1314.     AvgPop    =    378  Births       =    847  Deaths    =    843
  1315.     MaxGenPop =    169  (0080aaa)    MaxGenMem =    169 (0080aaa)
  1316.     RateMut   =  12648  RateMovMut   =   1264  RateFlaw  = 101120
  1317. extract: 0080aan @ 8
  1318. extract: 0045aab @ 8
  1319. InstExeC      =      3  Generations  =      8  Wed Apr 29 17:03:17 1992
  1320.     NumCells  =    373  NumGenotypes =    141  NumSizes  =     15
  1321.     AvgSize   =     77  NumGenDG     =      4  NumGenRQ  =    141
  1322.     AvgPop    =    368  Births       =    918  Deaths    =    925
  1323.     MaxGenPop =    144  (0080aaa)    MaxGenMem =    144 (0080aaa)
  1324.     RateMut   =  11794  RateMovMut   =   1232  RateFlaw  =  98560
  1325. extract: 0080adj @ 7
  1326. extract: 0080acu @ 7
  1327. extract: 0080aek @ 8
  1328. extract: 0045aad @ 8
  1329. InstExeC      =      4  Generations  =     10  Wed Apr 29 17:05:11 1992
  1330.     NumCells  =    383  NumGenotypes =    144  NumSizes  =     19
  1331.     AvgSize   =     74  NumGenDG     =      8  NumGenRQ  =    144
  1332.     AvgPop    =    376  Births       =   1071  Deaths    =   1061
  1333.     MaxGenPop =    118  (0080aaa)    MaxGenMem =    118 (0080aaa)
  1334.     RateMut   =  11185  RateMovMut   =   1184  RateFlaw  =  94720
  1335. extract: 0080aad @ 8
  1336.  
  1337.      The meaning of each different kind of information is described below:
  1338.  
  1339. > Using instruction set (INST) = 1
  1340.  
  1341.      Because we are likely to proliferate instruction sets in the near
  1342. future, the system lets us know which one it is using.
  1343.  
  1344. > TIERRA: LOG = on, Histogram Logging = off 
  1345.  
  1346. If the soup_in variable ``Log'' is non-zero, most of the information
  1347. shown in the standard output listing above will be written to the file
  1348. ``tierra.log'' on disk.  Histogram Logging = off indicates that histograms
  1349. viewed through the menu system will not be saved to the log.  This option
  1350. can be toggled so that static histograms are saved to the log.
  1351.  
  1352. > sizeof(Instruction)   = 1
  1353. > sizeof(Cell)   = 180
  1354. > sizeof(MemFr) = 16
  1355.  
  1356.      The size in bytes of each of the main structures, of which the system
  1357. will allocate large arrays at startup.
  1358.  
  1359. >     60000 bytes allocated for soup
  1360. >     16380 bytes allocated for cells
  1361. >     8000 bytes allocated for MemFr
  1362.  
  1363.      The total number of bytes used for each of the three main arrays of
  1364. structures.
  1365.  
  1366. > tsetup: arrays allocated without error
  1367.  
  1368.      Statement indicating that the arrays were allocated without error.
  1369.  
  1370. > beginning of GetNewSoup
  1371.  
  1372.      Statement indicating that the program is entering the GetNewSoup()
  1373. function.
  1374.  
  1375. > seed = 690349257
  1376.  
  1377.      A record of the seed of the random number generator used in this run.
  1378. This can be used to repeat the run if desired.
  1379.  
  1380. > init of soup complete
  1381.  
  1382.      A statement indicating that the soup has been initialized.
  1383.  
  1384. > GetNewSoup: loading 0080aaa into cell 0,2
  1385.  
  1386.      A statement indicating that the system is innoculating the soup with
  1387. a creature of size 80.  There will be a comparable line for every creature
  1388. used in innoculating the soup at startup.  The first creature goes into cell
  1389. 2 of array 0, because cells 0 and 1 are used for other purposes.
  1390.  
  1391. > InstExeC      =      0  Generations  =      0  Wed Apr 29 17:00:06 1992
  1392. >     NumCells  =      1  NumGenotypes =      1  NumSizes  =      1
  1393. >     AvgSize   =     80  NumGenDG     =      1  NumGenRQ  =      1
  1394. >     RateMut   =   6382  RateMovMut   =   1280  RateFlaw  = 102400
  1395. > tsetup: soup gotten
  1396.  
  1397.      These lines indicate the starting conditions of several variables which
  1398. will be explained below.
  1399.  
  1400. > extract: 0080aaa @ 276 v
  1401.  
  1402.      This line indicates that the genotype 0080aaa crossed one of the
  1403. frequency thresholds set in the soup_in file, SavThrMem or SavThrPop,
  1404. and that there were 276 adult creatures of this genotype in the soup
  1405. when this was noted.  However, no creatures are extracted until the
  1406. reaper is activated when the soup becomes full.  This means that 0080aaa
  1407. was not actually extracted at the time that it crossed a threshold, but
  1408. actually much later, when it had a relatively large population.  The v
  1409. after 276 indicates that this was a ``virtual extraction'', which means
  1410. that the genome was not actually saved to disk, since it already has been
  1411. saved to disk.  Anytime a permanent genotype goes extinct, then reappears
  1412. and crosses a threshold, it will experience a virtual extraction, which
  1413. just means that the crossing of the threshold will be reported as an extract
  1414. in standard out and in the tierra.log file (this information can be put
  1415. to good use by the tieout tool: tieout tierra.log ie ex)
  1416.  
  1417. > InstExeC      =      1  Generations  =      3  Wed Apr 29 17:01:04 1992
  1418. >     NumCells  =    376  NumGenotypes =    131  NumSizes  =      8
  1419. >     AvgSize   =     79  NumGenDG     =      1  NumGenRQ  =    131
  1420. >     AvgPop    =    292  Births       =    995  Deaths    =    620
  1421. >     MaxGenPop =    208  (0080aaa)    MaxGenMem =    208 (0080aaa)
  1422. >     RateMut   =  12515  RateMovMut   =   1264  RateFlaw  = 101120
  1423.  
  1424.      A statement of this form is printed after every million instructions
  1425. executed by the system.  See the plan() function in the bookeep.c module
  1426. for more details on this.
  1427.  
  1428. > InstExeC      =      1  Generations  =      3  Wed Apr 29 17:01:04 1992
  1429.  
  1430.      InstExeC = 1 tells us that one million instructions have been executed
  1431. in this run.  Generations = 3 tells us that roughly three generations of
  1432. creatures have passed so far during this run.  Wed Apr 29 17:01:04 1992
  1433. tells us the time and date of this record.
  1434.  
  1435. >     NumCells  =    376  NumGenotypes =    131  NumSizes  =      8
  1436.  
  1437.      NumCells = 376 tells us that there were 376 adult cells (and a roughly
  1438. equal number of daughter cells) at this point in the run.  NumGenotypes = 131
  1439. tells us that there were 131 distinct adult genotypes (code sequences) living
  1440. in the soup at the time of this record.  NumSizes = 8 tells us that there
  1441. were eight distinct adult genome sizes (creature code lengths) living in the
  1442. soup at this time.
  1443.  
  1444. >     AvgSize   =     79  NumGenDG     =      1  NumGenRQ  =    131
  1445.  
  1446.      AvgSize = 79 tells us that the average size of all the adult creatures
  1447. living in the soup at this time was 79 instructions.  NumGenDG = 1 tells us
  1448. that there is one genotype that has received a permanent name and been saved
  1449. to disk as .gen files in the genebank directory gb.  NumGenRQ = 131 tells us
  1450. that at this time there were 131 distinct genotypes being held in the genebank
  1451. in RAM (the ramqueue).
  1452.  
  1453. >     AvgPop    =    292  Births       =    995  Deaths    =    620
  1454.  
  1455. AvgPop = 292 tells us that during the last million instructions the average
  1456. population was 292 adult cells.  Births = 995 tells us that during the last
  1457. million instructions, there were 995 births.  Deaths = 620 tells us that
  1458. during the last million instructions, there were 620 deaths.
  1459.  
  1460. >     MaxGenPop =    208  (0080aaa)    MaxGenMem =    208 (0080aaa)
  1461.  
  1462.      MaxGenPop =    208  (0080aaa) tells us that at this time, the genotype
  1463. with the largest population is 80aaa, and that it has a population of 208
  1464. adult cells.  MaxGenMem =    208 (0080aaa) tells us that the genotype whose
  1465. adult cells occupy the largest share of space in the soup is 80aaa, and that
  1466. it has a population of 208 adult cells.
  1467.  
  1468. >     RateMut   =  12515  RateMovMut   =   1264  RateFlaw  = 101120
  1469.  
  1470.      RateMut = 12515 tells us that the actual average background (cosmic ray)
  1471. mutation rate for the upcoming million instructions will be one mutation per
  1472. 12515/2 instructions exectued.  RateMovMut = 1264 tells us that the actual
  1473. average move mutation rate (copy error) for the upcoming million instructions
  1474. will be one mutation for every 1264/2 instructions copied.  RateFlaw = 101120
  1475. tells us that the actual average flaw rate for the upcoming million
  1476. instructions will be one flaw for every 101120/2 instructions exectued.  The
  1477. reason that these numbers represent twice the average mutation rates is that
  1478. they are used to set the range of a uniform random variate determining the
  1479. interval between mutations.
  1480.  
  1481. > extract: 0080abl @ 8
  1482.  
  1483.      This is a real extraction, as indicated by the absence of a v after
  1484. the 8.  This genotype, 0080abl, crossed the threshold frequency with a
  1485. population of 8 adult creatures, its name was made permanent, and its genome
  1486. was saved to disk.
  1487.  
  1488.      When Tierra is running in the foreground it is possible to interrupt
  1489. it on either DOS or UNIX, usually by typing Ctrl C (^C).  When you do this
  1490. you will get a brief message listing your options, which looks something
  1491. like this:
  1492.  
  1493. ==========================================================
  1494. TIERRA: SIGINT Handler
  1495. ---------------------------------------------------------
  1496. InstExe.m    =      6  InstExec.i = 478414  NumCells =  362
  1497. NumGenotypes =    145  NumSizes   =     20
  1498. ---------------------------------------------------------
  1499.         Key     Function
  1500.  
  1501.         i       Information on simulation
  1502.         v       Change a soup_in variable
  1503.         S       Execute a system Shell
  1504.         s       Save the soup
  1505.         q       Save the soup & quit
  1506.         Q       Quit/Abort simulation
  1507.         c       To Continue simulation
  1508. ---------------------------------------------------------
  1509. TIERRA | i-info v-var s-save S-shell q-save&quit Q-quit c-continue |->
  1510.  
  1511. DOS only: Coreleft, is the amount of free memory above the highest block of
  1512. allocated memory, within the first 640K of system memory.  This is a clue to
  1513. how much memory remains for use by the simulator.
  1514.  
  1515. Unix only: If ALCOMM has been defined at compile time, VPORT is the value of
  1516. the socket for ALmond data communication.
  1517.  
  1518.      You must now choose one of the options by typing one of the corresponding
  1519. letters: ivSsqQc.  When you type the letter, the simulator will either prompt
  1520. you for more input or do the requested operation.  
  1521.  
  1522. The options are: 
  1523.  
  1524.      i-info v-var s-save S-shell q-save&quit Q-quit c-continue |->
  1525.  
  1526. i-info: will display some information about creatures stored in the Genebank.
  1527.      See below for details.
  1528.  
  1529. v-var: allows you to alter the value of any of the variables in the
  1530.      soup_in file at any point during a run.
  1531.  
  1532. s-save soup: will cause the state of the system to be saved at this point, and
  1533.      then continue the run.
  1534.  
  1535. S-Shell: (DOS only) this causes you to exit to the DOS prompt, while the
  1536.      simulator remains in the RAM in suspended animation.  You can now do
  1537.      anything that doesn't require a lot of memory.  Be careful that if you
  1538.      change directories, you come back to the current directories before you
  1539.      exit from the shell.  Also, be careful not to do anything that changes
  1540.      the graphics mode.
  1541.  
  1542. q-save&quit: will cause the state of the system to be saved at this point,
  1543.      and then exit from the run.
  1544.  
  1545. Q-quit: will exit immediately without saving the state of the system.
  1546.  
  1547. c-continue: continue the run.
  1548.  
  1549. i-info:  Choosing this option produces a sub-menu:
  1550.  
  1551. ---------------------------------------------------------
  1552.         s       Spectrum of all Size Classes
  1553.         m       Spectrum of Size Classes, by memory use
  1554.         g       Spectrum of Size Classes, by geneotype
  1555.         z       Break down of a specific Size Class
  1556.                 Any other key to main menu ...
  1557. ---------------------------------------------------------
  1558.  
  1559.      These options are documented under the BASIC frontend above.
  1560.  
  1561.     5.6.3) The tierra.log file
  1562.  
  1563.      If the soup_in variable:
  1564.  
  1565. Log = 1        0 = no log file, 1 = write log file
  1566.  
  1567. is set to a non-zero value, a file named tierra.log will be written to
  1568. the current directory.  This file contains in abbreviated form, much the
  1569. same information that is contained in the Standard Output frontend.  An
  1570. example of the output to this file follows:
  1571.  
  1572. TIERRA: LOG = on, Histogram Logging = off 
  1573.  
  1574. sizeof(Instruction)   = 1
  1575. sizeof(Cell)   = 180
  1576. sizeof(MemFr) = 16
  1577.     60000 bytes allocated for soup
  1578.     16380 bytes allocated for cells
  1579.     8000 bytes allocated for MemFr
  1580. tsetup: arrays allocated without error
  1581. beginning of GetNewSoup
  1582. seed = 1
  1583. init of soup complete
  1584. GetNewSoup: loading 0080aaa into cell 0,2
  1585.  
  1586. ie0 gn0 Wed Apr 29 16:12:08 1992
  1587. nc1 ng1 ns1
  1588. as80 rq1 dg1
  1589. rm6382 mm1280 rf102400
  1590.  
  1591. tsetup: soup gotten
  1592. ex = 0080aaa @ 276 v
  1593.  
  1594. ie1 gn3 Wed Apr 29 16:13:14 1992
  1595. nc376 ng131 ns8
  1596. as79 rq131 dg1
  1597. bi995 de620 ap292
  1598. mp208 @ 0080aaa mg208 @ 0080aaa
  1599. rm12515 mm1264 rf101120
  1600.  
  1601. ex = 0080abl @ 8
  1602.  
  1603. ie2 gn5 Wed Apr 29 16:14:17 1992
  1604. nc380 ng159 ns12
  1605. as79 rq159 dg2
  1606. bi847 de843 ap378
  1607. mp169 @ 0080aaa mg169 @ 0080aaa
  1608. rm12648 mm1264 rf101120
  1609.  
  1610. ex = 0080aan @ 8
  1611. ex = 0045aab @ 8
  1612.  
  1613. ie3 gn8 Wed Apr 29 16:15:32 1992
  1614. nc373 ng141 ns15
  1615. as77 rq141 dg4
  1616. bi918 de925 ap368
  1617. mp144 @ 0080aaa mg144 @ 0080aaa
  1618. rm11794 mm1232 rf98560
  1619.  
  1620. ex = 0080adj @ 7
  1621. ex = 0080acu @ 7
  1622. ex = 0080aek @ 8
  1623. ex = 0045aad @ 8
  1624.  
  1625. ie4 gn10 Wed Apr 29 16:17:27 1992
  1626. nc383 ng144 ns19
  1627. as74 rq144 dg8
  1628. bi1071 de1061 ap376
  1629. mp118 @ 0080aaa mg118 @ 0080aaa
  1630. rm11185 mm1184 rf94720
  1631.  
  1632.      Because this file is of essentially the same form as the standard
  1633. output, only the abbreviations will be documented here.  Refer to the
  1634. documentation of the Standard Output to interpret the meaning of this file.
  1635.  
  1636. ie = InstExeC; gn = Generations; nc = NumCells; ng = NumGenotypes;
  1637. ns = NumSizes; as = AvgSize; rq = NumGenRQ; dg = NumGenDG;
  1638. bi = Births; de = Deaths; ap = AvgPop; mp = MaxGenPop; mg = MaxGenMem.
  1639. rm = RateMut; mm = RateMovMut; rf = RateFlaw;
  1640.  
  1641. 6)  LISTING OF DISTRIBUTION FILES
  1642.  
  1643. The distribution includes the following files:
  1644.  
  1645. arg.c - the main module for the assembler/disassembler, originally written by
  1646.      Tom Uffner.  This program converts ascii assembler files into binary
  1647.      files which can be executed by the Tierran virtual computer.
  1648.  
  1649. arg.prj - the Turbo C V 2.0 project file for compiling the
  1650.      assember/disassembler.  If you are using a more recent Borland compiler,
  1651.      you must use the Borland tool to build the binary project file.  Include
  1652.      the modules listed in this ascii version of the file.
  1653.  
  1654. arg_inc.c - a file used to include some of the files used in compiling the
  1655.      assembler (arg).  They are included in this way because arg_inc.c
  1656.      defines ARG, which alters the included modules to be compatible with
  1657.      arg rather than tierra.
  1658.  
  1659. arginst.h - a file containing some variable used by the assembler.
  1660.  
  1661. bookeep.c - source code for bookeeping routines, which keep track of how many
  1662.      of what kind of creatures are in the soup, and other stuff like that.
  1663.  
  1664. cclr1, cclr2, cclr3, cclr4, cclr1.bat, cclr2.bat, cclr3.bat, cclr4.bat -
  1665.      Unix shell scripts, and DOS batch files for cleaning up an old run in
  1666.      preparation for a new run with a cumulative genebank (or you can just
  1667.      use it to remove files generated by a run, to get you disk space back).
  1668.      You must change the protection on the unix files to make them executable:
  1669.      chmod +x cclr1
  1670.      There is a different file for each instruction set.
  1671.  
  1672. clr1, clr2, clr3, clr4, clr1.bat, clr2.bat, clr3.bat, clr4.bat -
  1673.      Unix shell scripts and DOS batch files for cleaning up an old run in
  1674.      preparation for a new run (or you can just use it to remove files
  1675.      generated by a run, to get you disk space back).
  1676.      You must change the protection on the unix files to make them executable:
  1677.      chmod +x clr1
  1678.      There is a different file for each instruction set.
  1679.  
  1680. configur.h - a file for configuring Tierra.  You probably won't need to
  1681.      touch this unless you get into advanced stuff.
  1682.  
  1683. declare.h - all global variables are declared in this file, except those
  1684.      whose values are set by soup_in.  Those globals are declared in
  1685.      soup_in.h.  declare.h is included by tierra.c which contains the main
  1686.      function.
  1687.  
  1688. diskbank.c - some functions that deal with writing to disk.
  1689.  
  1690. extern.h - all global variables are delcared as extern in this file, and this
  1691.      file is included by all *.c files except tierra.c which includes
  1692.      delcare.h instead.
  1693.  
  1694. frontend.c - functions for handling input/output for Tierra.  This stuff was
  1695.      written by Dan Pirone.  This module contains basic data reporting
  1696.      functions, and includes one of the following:
  1697.   tstdio.c - low level IO for standard IO, simple, and good for debugging.
  1698.   tcurses.c - advanced IO for unix, based on "standard" curses calls,
  1699.      Please see the manual pages on curses for the nitty gritty details.
  1700.   tturbo.c - advanced IO for the Turbo C / DOS environment.
  1701.      On machines with EGA or VGA harware, 43/50 lines modes are used.
  1702.  
  1703. genio.c - functions for input/output of creatures.  This stuff is also used
  1704.      by arg.c, the assembler/disassembler.  This module has benefited from
  1705.      a lot of work by Tom Uffner.
  1706.  
  1707. instruct.c - this module contains generalized executable functions.  These
  1708.      generalized functions are mapped to specific functions by the parsing
  1709.      functions in the parse.c module.
  1710.  
  1711. license.h - a file stating the terms of the license agreement, which is
  1712.      include in all the source code modules.
  1713.  
  1714. Makefile - the make file, for compiling tierra and arg under Unix.
  1715.  
  1716. memalloc.c - functions for handling memory allocation in the soup, the stuff
  1717.      that ``cell membranes'' are made of.
  1718.  
  1719. memtree.c - additional memory allocation routines, written by
  1720.      Chris Stephenson of the IBM T. J. Watson Research Center.
  1721.  
  1722. parse.c - the parsing functions interpret the executable code of the
  1723.      creatures, and map it onto the executable functions contained in the
  1724.      instruct.c module.  This file includes one of the following four files,
  1725.      depending on which instruction set is being compiled:
  1726.   parse1.c
  1727.   parse2.c
  1728.   parse3.c
  1729.   parse4.c
  1730.  
  1731. portable.c - functions for portability between operating systems.
  1732.  
  1733. portable.h - definitions for portability between operating systems and
  1734.      architectures.
  1735.  
  1736. probe.c - a separate tool for observing the genebank, documented in probe.doc.
  1737.  
  1738. prototyp.h - all functions in Tierra are prototyped here.
  1739.  
  1740. queues.c - queue management functions for the slicer and reaper queues. 
  1741.  
  1742. rambank.c - functions for managing the genebank.  This module has benefited
  1743.      from a lot of work by Tom Uffner.
  1744.  
  1745. rnd_inst.c - a separate tool for randomizing the mapping of opcodes to
  1746.      instructions, documented in rnd_inst.doc
  1747.  
  1748. slicers.c - interchangeable slicer functions.  This file contains some
  1749.      experiments in the allocation of cpu time to creatures.  This is
  1750.      an interesting thing to play with.
  1751.  
  1752. soup_in1, soup_in2, soup_in3, soup_in4 - the ascii files read by Tierra on
  1753.      startup, which contains all the global parameters that determine the
  1754.      environment.  There is a different file for each instruction set.
  1755.  
  1756. soup_in.h - this file defines the default values of all the soup_in variables,
  1757.      and defines the instruction set by mapping the assember mnemonics to the
  1758.      opcodes, parser functions, and executables.
  1759.  
  1760. tcurses.c - see under frontend.c above.
  1761.  
  1762. tcolors.cfg - an ascii file that maps the colors of the Tierra display.
  1763.      This makes it easy to remap the colors.  This is useful for odd displays
  1764.      such as LCD where the colors do not map nicely.
  1765.  
  1766. tieout.c - a separate tool for observing the contents of the tierra.log file
  1767.      documented in tieout.doc.
  1768.  
  1769. tieout.doc - documentation of the tieout tool.
  1770.  
  1771. tieout.exe - the DOS distribution also includes the executable version of
  1772.      the tieout tool, so that it does not have to be compiled.
  1773.      See tieout.doc.
  1774.  
  1775. tierra.c - this file contains the main function, and the central code
  1776.      driving the virtual computer.
  1777.  
  1778. tierra.doc - this file, on line documentation.
  1779.  
  1780. tierra.exe - the DOS distribution includes the executable version of the
  1781.      Tierra program, so that it does not have to be compiled.
  1782.  
  1783. tierra.h - this file contains all the structure definitions.  It is a good
  1784.      source of documentation for anyone trying to understand the code.
  1785.  
  1786. tierra.prj - the Turbo C V 2.0 project file for compiling Tierra.
  1787.      If you are using a more recent Borland compiler, you must use the
  1788.      Borland tool to build the binary project file.  Include
  1789.      the modules listed in this ascii version of the file.
  1790.  
  1791. tmonitor.c - this file contains support calls for the ALmond tool.
  1792.  
  1793. trand.c - random number generation routines from Numerical Recipes in C.
  1794.  
  1795. tsetup.c - routines called when Tierra starts up and comes down.  Tom Uffner
  1796.      has put some work into this module as well.
  1797.  
  1798. ttools.c - routins used in generating the histograms displayed by the
  1799.      frontend.
  1800.  
  1801. gb1: - a subdirectory containing the genomes of the creatures saved
  1802.      during a run of instruction set 1.
  1803.  
  1804. gb1/0080aaa.tie - the ancestor, written by a human, mother of all other
  1805.      creatures.
  1806.  
  1807. gb1/0073aaa.tie - a new ancestor, written by a human, like 0080aaa, but
  1808.      with some junk code removed.
  1809.  
  1810. gb1/0022aaa.tie - the smallest non-parasitic self-replicating creature to
  1811.      evolve.
  1812.  
  1813. gb1/0045aaa.tie - the archtypical parasite.
  1814.  
  1815. gb1/0046aaa.tie - a symbiont with 0064aaa.  These two were created by hand,
  1816.      by splitting 0080aaa into two parts.
  1817.  
  1818. gb1/0064aaa.tie - a symbiont with 0046aaa.  These two were created by hand,
  1819.      by splitting 0080aaa into two parts.
  1820.  
  1821. gb1/0072aaa.tie - a phenomenal example of optimization through evolution,
  1822.      involving the unrolling of the copy loop.
  1823.  
  1824.      At the time of this writing, only a single run, of a billion
  1825. instructions, has been analyzed at the level of detail to reveal the specifics
  1826. of the ecological arms race that took place.  That information is presented
  1827. in the manuscripts cited above.  This run can be seen on the video, available
  1828. from Media Magic, P.O. Box 507, Nicasio, CA 94946.  Some of the major players
  1829. in that run are listed below, and included in the software distribution,
  1830. in the chronological order of their appearance:
  1831.  
  1832. gb1/0079aab.tie - this creature dominated the soup at the time that a major
  1833.      optimization took place, resulting in 0069aaa and its relatives.
  1834.  
  1835. gb1/0069aaa.tie - this fully self-replicating (non-parasitic) creature
  1836.      appeared at a time that the dominant self-replicating size class was 79.
  1837.      Thus this creature was a hopeful monster.  It managed to shave 10
  1838.      instructions off of the genome in a single genetic change.  Actually this
  1839.      creature claims that its immediate ancestor (parental genotype) was
  1840.      0085aal.  If this is true, then it actually shaved 16 instructions off
  1841.      its size in a single genetic event.  Unfortunately, 0085aal was not
  1842.      preserved in the fossil record.
  1843.  
  1844. gb1/0069aab.tie - this host creature co-dominates the soup for a time, with
  1845.      the parasite 0031aaa.
  1846.  
  1847. gb1/0031aaa.tie - this parasite co-dominates the soup for a time, with the
  1848.      host 0069aab.
  1849.  
  1850. gb1/0070aaw.tie - while 0069aab and 0031aaa co-dominate the soup, this
  1851.      creature, which is the first hyper-parasite, surges up.  It and its
  1852.      relatives drive the parasites to extinction.
  1853.  
  1854. gb1/0061aag.tie - this hyper-parasites dominates at the time that the first
  1855.      social creatures appear.
  1856.  
  1857. gb1/0061aai.tie - this is the first social hyper-parasite to surge up.  It is
  1858.      social by virtue of using a template in its tail to jump back to its
  1859.      head.  This only works when it occurs in close aggregations of same
  1860.      kind creatures.
  1861.  
  1862. gb1/0061aab.tie - this is the second social hyper-parasite to surge up.  It
  1863.      operates on the basis of a completely different social mechanism from
  1864.      0061aai.  In this creature the basis of cooperation is that the
  1865.      template used to search for its tail, does not match to the tail
  1866.      template.  However, it two of these creatures abut in memory, the
  1867.      union of the tail template of one with the head template of the next,
  1868.      forms the template that is used to identify the tail.  This algorithm
  1869.      also only works when the creatures occur in aggregations.  However, this
  1870.      mechanism is more fragile than that used by 0061aai.  For 0061aab, the
  1871.      two cooperating creatures must exactly abut.  For 0061aai, the two
  1872.      cooperating creatures may have some space between them.  Therefore
  1873.      it is not surprising that the social mechanism of 0061aai is the one
  1874.      prevailed.
  1875.  
  1876. gb1/0061aaa.tie - this is the social hyper-parasite that dominated at the time
  1877.      that cheaters invaded.
  1878.  
  1879. gb1/0027aab.tie - this is the dominant cheater that invaded against the social
  1880.      hyper-parasites.
  1881.  
  1882. gb1/0080.gen - the DOS distribution also includes the assembled binary version
  1883.      of the 0080aaa.tie file, so that Tierra can be run without having to
  1884.      assemble the genome file first.
  1885.  
  1886. gb1/arg.exe - the DOS distribution includes the executable version of the
  1887.      assembler/disassembler.
  1888.  
  1889. gb1/opcode.map - a file read by Tierra, Beagle, and arg upon startup.  This
  1890.      file determines the correspondence between opcodes and the associated
  1891.      machine instructions.  This is a simple way to play with the definition
  1892.      of the physics and chemistry of the simulator.
  1893.  
  1894. gb1/opcode.vir - a virginal copy of opcode.map.  You may use the rnd_inst tool
  1895.      to create new opcode maps, or you may create them by hand.  You will
  1896.      have to name the new versions opcode.map in order to assemble the
  1897.      genomes based on the new mapping.  You can keep opcode.vir in reserve.
  1898.  
  1899. gb1/opcode.scr - an opcode map where all pairs of most similar instructions
  1900.      are mapped with a hamming distance of five, including the two nops.
  1901.  
  1902. gb1/probe.doc - documentation of the probe tool.
  1903.  
  1904. gb1/probe.exe - the DOS distribution includes the executable version of the
  1905.      probe program, so that it does not have to be compiled.
  1906.  
  1907. gb1/rnd_inst.doc - documentation of the run_inst tool.
  1908.  
  1909. gb1/rnd_inst.exe - the DOS distribution includes the executable version of the
  1910.      rnd_inst program, so that it does not have to be compiled.
  1911.  
  1912. gb2: - a subdirectory containing the genomes of the creatures written for
  1913.      use with instruction set 2.
  1914.  
  1915. gb2/0005aaa.tie - non-replicating program written to test get().
  1916.  
  1917. gb2/0010aaa.tie - non-replicating program written to test put.
  1918.  
  1919. gb2/0011aaa.tie - non-replicating program written to test get with template.
  1920.  
  1921. gb2/0013aaa.tie - non-replicating program to test put with template.
  1922.  
  1923. gb2/0016aaa.tie - non-replicating program to test put.
  1924.  
  1925. gb2/0060aaa.tie - a parasite hand-made from the ancestor.
  1926.  
  1927. gb2/0095aaa.tie - the ancestor for use in instruction set 2.
  1928.  
  1929. gb2/opcode.map - the opcode map for use in instruction set 2.
  1930.  
  1931. gb2/opcode.vir - a virginal copy of the opcode map for use in
  1932.      instruction set 2.
  1933.  
  1934. gb3: - a subdirectory containing the genomes of the creatures written for
  1935.      use with instruction set 3.
  1936.  
  1937. gb3/0050aaa.tie - a parasite hand-made from the ancestor.
  1938.  
  1939. gb3/0093aaa.tie - the ancestor for use in instruction set 3.
  1940.  
  1941. gb3/opcode.map - the opcode map for use in instruction set 3.
  1942.  
  1943. gb3/opcode.vir - a virginal copy of the opcode map for use in
  1944.      instruction set 3.
  1945.  
  1946. gb4: - a subdirectory containing the genomes of the creatures written for
  1947.      use with instruction set 4.
  1948.  
  1949. gb4/0082aaa.tie - the ancestor for use in instruction set 4.
  1950.  
  1951. gb4/opcode.map - the opcode map for use in instruction set 4.
  1952.  
  1953. gb4/opcode.vir - a virginal copy of the opcode map for use in
  1954.      instruction set 4.
  1955.  
  1956. td: - a subdirectory where a complete record of births and deaths will
  1957.      be written.
  1958.  
  1959. td/break.1 - a file containing a record of births and deaths.  A dummy file is
  1960.      provided to hold the space.
  1961.  
  1962. td/diverse.c - a separate tool for observing the diversity of genotypes and
  1963.      size classes in a run, documented in diverse.doc.
  1964.  
  1965. td/diverse.doc - documentation of the diversity tool.
  1966.  
  1967. td/diverse.exe - the DOS distribution also includes the executable version of
  1968.      the diversity index tool, so that it does not have to be compiled.
  1969.      See diverse.doc.
  1970.  
  1971. td/fragment.c - a separate tool for peparing fragments of a run for
  1972.      observation by the beagle tool, documented in beagle.doc.
  1973.  
  1974. td/fragment.exe - the DOS distribution also includes the executable version of
  1975.      the fragment tool.  See beagle.doc.
  1976.  
  1977. td/run_info.c - a separate tool for peparing the output of a run for
  1978.      observation by the beagle tool, documented in beagle.doc.
  1979.  
  1980. td/run_info.exe - the DOS distribution also includes the executable version of
  1981.      the run_info tool.  See beagle.doc.
  1982.  
  1983. 7)  SOUP_IN PARAMETERS
  1984.  
  1985. A typical soup_in file looks like the following:
  1986.  
  1987. /* begin soup_in file */
  1988.  
  1989. # tierra core: 9-9-92 
  1990.  
  1991. # observational parameters:
  1992.  
  1993. BrkupSiz = 1024      size of output file in K, named break.1, break.2 ...
  1994. CumGeneBnk = 1    Use cumulative gene files, or overwrite
  1995. debug = 0               0 = off, 1 = on, printf statements for debugging
  1996. DiskOut = 1            output data to disk (1 = on, 0 = off)
  1997. GeneBnker = 1   turn genebanker on and off
  1998. GenebankPath = gb1/  path for genebanker output
  1999. hangup = 0            0 = exit on error, 1 = hangup on error for debugging
  2000. Log = 1        0 = no log file, 1 = write log file
  2001. MaxFreeBlocks = 700     initial number of structures for memory allocation
  2002. OutPath = td/  path for data output
  2003. RamBankSiz = 1000 array size for genotypes in ram, use with genebanker
  2004. SaveFreq = 50        frequency of saving core_out, soup_out and list
  2005. SavMinNum = 2     minimum number of individuals to save genotype
  2006. SavThrMem = .04  threshold memory occupancy to save genotype
  2007. SavThrPop = .04  threshold population proportion to save genotype
  2008. WatchExe = 0     mark executed instructions in genome in genebank
  2009. WatchMov = 0     set mov bits in genome in genebank
  2010. WatchTem = 0     set template bits in genome in genebank
  2011.  
  2012. # environmental variables:
  2013.  
  2014. alive = 500            how many generations will we run
  2015. DistFreq = -.3       frequency of disturbance, factor of recovery time
  2016. DistProp = .2       proportion of population affected by distrubance
  2017. DivSameGen = 0 cells must produce offspring of same genotype, to stop evolution
  2018. DivSameSiz = 0 cells must produce offspring of same size, to stop size change
  2019. DropDead = 5 stop system if no reproduction in the last x million instructions
  2020. GenPerBkgMut = 16 mutation rate control by generations ("cosmic ray")
  2021. GenPerFlaw = 64       flaw control by generations
  2022. GenPerMovMut = 8    mutation rate control by generations (copy mutation)
  2023. IMapFile = opcode.map map of opcodes to instructions, file in GenebankPath
  2024. MalMode = 1 0 = first fit, 1 = better fit, 2 = random preference,
  2025. # 3 = near mother's address, 4 = near dx address, 5 = near top of stack address
  2026. MalReapTol = 1  0 = reap by queue, 1 = reap oldest creature within MalTol
  2027. MalTol = 20 multiple of avgsize to search for free block
  2028. MateProb = 0.2  probability of mating at each mal
  2029. MateSearchL = 5 multiple of avgsize to search 0 = no limit
  2030. MateSizeEp = 2 size epsilon for potential mate
  2031. MateXoverProp = 1.0 proportion of gene to secect for crossover point
  2032. MaxMalMult = 3        multiple of cell size allowed for mal()
  2033. MemModeFree = 0  read, write, execute protection for free memory
  2034. MemModeProt = 2 rwx protect mem: 1 bit = execute, 2 bit = write, 4 bit = read
  2035. MinCellSize = 8       minimum size for cells
  2036. MinTemplSize = 1       minimum size for templates
  2037. MovPropThrDiv = .7       minimum proportion of daughter cell filled by mov
  2038. new_soup = 1          1 = this a new soup, 0 = restarting an old run
  2039. NumCells = 6      number of creatures and gaps used to inoculate new soup
  2040. PhotonPow = 1.5         power for photon match slice size
  2041. PhotonWidth = 8   amount by which photons slide to find best fit
  2042. PhotonWord = chlorophill  word used to define photon
  2043. ReapRndProp = .3 top prop of reaper que to reap from
  2044. SearchLimit = 5
  2045. seed = 0 seed for random number generator, 0 uses time to set seed
  2046. SizDepSlice = 0  set slice size by size of creature
  2047. SlicePow = 1    set power for slice size, use when SizDepSlice = 1
  2048. SliceSize = 25    slice size when SizDepSlice = 0
  2049. SliceStyle = 2   choose style of determining slice size
  2050. SlicFixFrac = 0   fixed fraction of slice size
  2051. SlicRanFrac = 2   random fraction of slice size
  2052. SoupSize = 50000 size of soup in instructions
  2053.  
  2054. space 10000
  2055. 0080aaa
  2056. space 10000
  2057. 0045aaa
  2058. space 10000
  2059. 0080aaa
  2060.  
  2061. /* end soup_in file */
  2062.  
  2063.      The ordering of parameters is not important, except that the creatures
  2064. used to innoculate the soup must be listed at the end of the file, with no
  2065. blank lines between the creatures (if there is more than one).  Parameters
  2066. that are not listed in the soup_in or soup_out files, default to the values
  2067. set in the soup_in.h file.  The parameter names must begin at the first
  2068. character of the line (no spaces or other characters may appear at the
  2069. beginning of the line before the parameter name).
  2070.  
  2071. The meaning of each of these parameters is explained below:
  2072.  
  2073. # tierra core: 9-9-92 
  2074.  
  2075. # observational parameters:
  2076.  
  2077.      These lines are comments.  The code that reads the soup_in and soup_out
  2078. files skips all blank lines, and all lines beginning with the # character.
  2079. The input parameters have been divided into two groups, the ``observational
  2080. parameters'' and the ``environmental variables''.  The observational
  2081. parameters are listed first, and they do not affect the course of events
  2082. in the run.  They only affect what kind of information we extract, and how
  2083. and where it is stored.
  2084.  
  2085. BrkupSiz = 1024      size of output file in K, named break.1, break.2 ...
  2086.  
  2087.      If this value is set to zero (0) the record of births and deaths will
  2088. be written to a single file named tierra.run.  However, if BrkupSiz has a
  2089. non-zero value, birth and death records will be written to a series of files
  2090. with the names break.1, break.2, etc.  Each of these files will have the
  2091. size specified, in K (1024 bytes).  The value 1024 indicates that the
  2092. break files will each be one megabytes in size.  The output file(s) will
  2093. be in the path specified by OutPath (see below).  See also DiskOut.
  2094. Please note that these files can get quite large.
  2095.  
  2096. CumGeneBnk = 0  0 = start new genebank, 1 = use cumulative genebank
  2097.  
  2098.      This parameter gives us the option of starting a fresh genebank, or
  2099. of working with a cumulative genebank.  If you are planning to compare the
  2100. results of a series of runs, you should consider using a cumulative
  2101. genebank.  With a cumulative genebank, if the identical genotypes appear in
  2102. successive runs, they will have identical names.
  2103.  
  2104. debug = 0               0 = off, 1 = on, printf statements for debugging
  2105.  
  2106.      This is used during code development, to turn on and off print statements
  2107. for debugging purposes.
  2108.  
  2109. DiskOut = 1            output data to disk (1 = on, 0 = off)
  2110.  
  2111.      If this parameter is set to zero (0), no birth and death records will
  2112. be saved.  Any other value will cause birth and death records to be saved
  2113. to a file whose name is discussed under BrkupSiz above, in the path discussed
  2114. under OutPath below.
  2115.  
  2116. GeneBnker = 1   turn genebanker on and off
  2117.  
  2118.      The parameter turns the genebanker on and off.  The value zero turns
  2119. the genebanker off, any other value turns it on.  With the genebanker off,
  2120. the record of births and deaths will contain the sizes of the creatures,
  2121. but not their genotypes.  Also no genomes will be saved in the genebank.
  2122. When the genebanker is turned on, the record of births and deaths will
  2123. contain a three letter unique name for each genotype, as well as the size
  2124. of the creatures.  Also, any genome whose frequency exceeds the thresholds
  2125. SavThrMem and SavThrPop (see below) will be saved to the genebank, in
  2126. the path indicated by GenebankPath (see below).
  2127.  
  2128. GenebankPath = gb1/  path for genebanker output
  2129.  
  2130.      This is a string variable which describes the path to the genebank
  2131. where the genomes will be saved.  The path name should be terminated by
  2132. a forward slash.
  2133.  
  2134. hangup = 0            0 = exit on error, 1 = hangup on error for debugging
  2135.  
  2136.      If an error occurs which is serious enough to bring down the system,
  2137. having hangup set to 1 will prevent the program from exiting.  In this case,
  2138. the program will hang in a simple loop so that it remains active for
  2139. debugging purposes.  Set this parameter only if you are running the
  2140. simulator under a debugger.
  2141.  
  2142. Log = 1        0 = no log file, 1 = write log file
  2143.  
  2144.     If Log is non zero, a disk file called tierra.log will be written
  2145. mirroring all major simulation states.  If disk space is a problem,
  2146. please set Log = 0. This can be changed at any point in the run.
  2147.  
  2148. MaxFreeBlocks = 700     initial number of structures for memory allocation
  2149.  
  2150.      There is an array of structures used for the virtual memory allocator.
  2151. This parameter sets the initial size of the allocated array, at startup.
  2152.  
  2153. OutPath = td/  path for data output
  2154.  
  2155.      The record of births and deaths will be written to files in a directory
  2156. specified by OutPath.  See BrkupSiz above for a discussion of the name of
  2157. the file(s) containing the birth and death records.
  2158.  
  2159. RamBankSiz = 1000 array size for genotypes in ram, use with genebanker
  2160.  
  2161.      The parameter RamBankSiz places a limit on how many genotypes will be
  2162. stored in RAM.  When the number of genotypes in the genebank exceeds the
  2163. RamBankSiz, if there are genotypes with permanent names in the rambank that
  2164. are extinct in the soup, they will be swapped out to disk as .gen files.
  2165. However, if the number of living genotypes in the soup is greater than
  2166. RamBankSiz, then the value of RamBankSiz is essentially ignored (actually it
  2167. is treated as if the value were equal to the number of living genotypes).
  2168. Living genotypes are never swapped out to disk, only extinct ones.  Under DOS,
  2169. the parameter RamBankSiz is of little importance, because it is raised if
  2170. there are more living genotypes, and if the simulator uses all 640K of RAM,
  2171. RamBankSiz is lowered so that genotypes will be swapped out to avoid running
  2172. out of memory.  Under DOS, with a SoupSize of 60,000, the rambank can hold
  2173. somewhere between 600 and 800 genotypes.  If there are more than that, the
  2174. system will thrash terribly, swapping genomes in and out from disk to RAM
  2175. and back.  Under Unix, this parameter does determine how many genotypes
  2176. will be held in the rambank, as long as there are not more than RamBankSiz
  2177. living genotypes.
  2178.  
  2179. SaveFreq = 50        frequency of saving core_out, soup_out and list
  2180.  
  2181.      Every SaveFreq million instructions, the complete state of the
  2182. virtual machine is saved.  This is a useful feature for long runs, so that
  2183. the system can be restarted if it is interrupted for some reason.
  2184.  
  2185. SavMinNum = 2     minimum number of individuals to save genotype
  2186.  
  2187.      A genotype will not be given a permanent name and saved to disk in
  2188. a .gen file unless it has a population of SavMinNum or more adult individuals.
  2189.  
  2190. SavThrMem = .04  threshold memory occupancy to save genotype
  2191. SavThrPop = .04  threshold population proportion to save genotype
  2192.  
  2193.      These two variables affect the rate at which genomes are assigned
  2194. permanent names and saved to disk.  In a soup of 60,000 instructions
  2195. (SoupSize = 60000),   thresholds of .05 will save about one genome per two
  2196. million instructions, thresholds of .04 will save about one genome per
  2197. million instructions, thresholds of .03 will save about 1.2 genomes per
  2198. million instructions, thresholds of .02 will save about three genome per
  2199. million instructions.  On DOS systems, care should be taken to avoid
  2200. saving too many genomes as they will clog the memory and bring the system
  2201. down (See KNOWN BUGS below).
  2202.  
  2203. SavThrMem = .04  threshold memory occupancy to save genotype
  2204.  
  2205.      If a particular genotype fills SavThrMem of the total space available
  2206. in the soup, it will be assigned a permanent unique name, and saved to disk.
  2207. Note that an adjustment is made because only adult cells are counted, and
  2208. embryos generally fill half the soup.  Therefore adult cells of a particular
  2209. genotype need only occupy SavThrMem * 0.5 of the space to be saved.
  2210.  
  2211. SavThrPop = .04  threshold population proportion to save genotype
  2212.  
  2213.      If a particular genotype amounts to SavThrPop of the total population
  2214. of (adult) cells in the soup, it will be assigned a permanent unique name,
  2215. and saved to disk.
  2216.  
  2217. WatchExe = 0     mark executed instructions in genome in genebank
  2218. WatchMov = 0     set mov bits in genome in genebank
  2219. WatchTem = 0     set template bits in genome in genebank
  2220.  
  2221.      WARNING: setting any of these three watch parameters will engage cpu
  2222. intensive observational software that will substantially slow down any
  2223. simulation.  Engage these tools only if you plan to use the data that
  2224. they generate.
  2225.  
  2226. WatchExe = 0     mark executed instructions in genome in genebank
  2227.  
  2228.      If the genebank is on, setting this parameter to a non-zero value
  2229. will turn on a watch of which instructions are being executed in each
  2230. permanent genotype (this helps to distinguish junk code from code that is
  2231. executed), and also, who is executing whose instructions.  There is a bit
  2232. field in the GList structure (bit definitions are defined in the tierra.h
  2233. module) that keeps track of whether a creature executes its own instructions,
  2234. those of another creature, if another creature executes this creatures
  2235. instructions, etc:
  2236.  
  2237.     bit  2  EXs = executes own instructions (self)
  2238.     bit  3  EXd = executes daughter's instructions
  2239.     bit  4  EXo = executes other cell's instructions
  2240.     bit  5  EXf = executes instructions in free memory
  2241.     bit  6  EXh = own instructions are executed by other creature (host)
  2242.  
  2243. WatchMov = 0     set mov bits in genome in genebank
  2244.  
  2245.      If the genebank is on, setting this parameter to a non-zero value
  2246. will turn on a watch of who moves whose instructions and where.  This
  2247. information is recorded in the bit field in GList structure:
  2248.  
  2249.     bit 17  MFs = moves instruction from self
  2250.     bit 18  MFd = moves instruction from daughter
  2251.     bit 19  MFo = moves instruction from other cell
  2252.     bit 20  MFf = moves instruction from free memory
  2253.     bit 21  MFh = own instructions are moved by other creature (host)
  2254.     bit 22  MTs = moves instruction to self
  2255.     bit 23  MTd = moves instruction to daughter
  2256.     bit 24  MTo = moves instruction to other cell
  2257.     bit 25  MTf = moves instruction to free memory
  2258.     bit 26  MTh = is written on by another creature (host)
  2259.     bit 27  MBs = executing other creature's code, moves inst from self
  2260.     bit 28  MBd = executing other creature's code, moves inst from daughter
  2261.     bit 29  MBo = executing other creature's code, moves inst from other cell
  2262.     bit 30  MBf = executing other creature's code, moves inst from free memory
  2263.     bit 31  MBh = other creature uses another cpu to move your instructions
  2264.  
  2265. WatchTem = 0     set template bits in genome in genebank
  2266.  
  2267.      If the genebank is on, setting this parameter to a non-zero value
  2268. will turn on a watch of whose templates are matched by whom.  This
  2269. information is recorded in the bit field in the GList structure:
  2270.  
  2271.     bit  7  TCs = matches template complement of self
  2272.     bit  8  TCd = matches template complement of daughter
  2273.     bit  9  TCo = matches template complement of other
  2274.     bit 10  TCf = matches template complement of free memory
  2275.     bit 11  TCh = own template complement is matched by other creature (host)
  2276.     bit 12  TPs = uses template pattern of self
  2277.     bit 13  TPd = uses template pattern of daughter
  2278.     bit 14  TPo = uses template pattern of other
  2279.     bit 15  TPf = uses template pattern of free memory
  2280.     bit 16  TPh = own template pattern is used by other creature (host)
  2281.  
  2282. # environmental variables:
  2283.  
  2284.      This is a comment indicating the beginning of the environmental
  2285. parameters.  These parameters affect the course of evolution and
  2286. ecology of the run.
  2287.  
  2288. alive = 500            how many generations will we run
  2289.  
  2290.      This tells the simulator how long to run, in generations.
  2291.  
  2292. DistFreq = -.3       frequency of disturbance, factor of recovery time
  2293.  
  2294.      The frequency of disturbance, as a factor of recovery time.  This and
  2295. the next option control the pattern of disturbance.  If you do not want the
  2296. system to be disturbed, set DistFreq to a negative value.  If DistFreq has
  2297. a non-negative value, when the soup fills up the reaper will be invoked to
  2298. kill cells until it has freed a proportion DistProp of the soup.  The system
  2299. will then keep track of the time it takes for the creatures to recover from
  2300. the disturbance by filling the soup again.  Let's call this recovery time:
  2301. rtime.  The next disturbance will occur: (rtime X DistFreq) after recovery
  2302. is complete.  Therefore, if DistFreq = 0, each disturbance will occur
  2303. immediately after recovery is complete.  If DistFreq = 1, the time between
  2304. disturbances will be twice the recovery time, that is, the soup will remain
  2305. full for a period equal to the recovery time, before another disturbance hits.
  2306.  
  2307. DistProp = .2       proportion of population affected by distrubance
  2308.  
  2309.      The proportion of the soup that is freed of cells by each disturbance.
  2310. The disturbance occurs by invoking the reaper to kill cells until the total
  2311. amount of free memory is greater than or equal to: (DistProp X SoupSize).
  2312. Note that cells are not killed at random, they are killed off the top of the
  2313. reaper queue, except as modified by the ReapRndProp variable.
  2314.  
  2315. DivSameGen = 0 must produce offspring of same genotype, to stop evolution
  2316.  
  2317.      This causes attempts at cell division to abort if the offspring is of
  2318. a genotype different from the parent.  This can be used when the mutation
  2319. rates are set to zero, to prevent sex from causing evolution.
  2320.  
  2321. DivSameSiz = 0 cells must produce offspring of same size, to stop size change
  2322.  
  2323.      Like DivSameGen, but cell division aborts only if the offspring is of
  2324. a different size than the parent.  Changes in genotype are not prevented,
  2325. only changes in size are prevented.
  2326.  
  2327. DropDead = 5 stop system if no reproduction in the last x million instructions
  2328.  
  2329.      Sometimes the soup dies, such as when mutation rates are too high.
  2330. This parameter watches the time elapsed since the last cell division, and
  2331. brings the system down if it is greater than DropDead million instructions.
  2332.  
  2333. GenPerBkgMut = 16 mutation rate control by generations ("cosmic ray")
  2334.  
  2335.      Control of the background mutation rate ("cosmic ray").  The value 16
  2336. indicates that in each generation, roughly one in sixteen cells will be hit
  2337. by a mutation.  These mutations occur completely at random, and also affect
  2338. free space where there are no cells.  If the value of GenPerBkgMut were 0.5,
  2339. it would mean that in each generation, each cell would be hit by roughly
  2340. two mutations.
  2341.  
  2342. GenPerFlaw = 64       flaw control by generations
  2343.  
  2344.      Control of the flaw rate.  The value 64 means that in each generation,
  2345. roughly one in sixty-four individuals will experience a flaw.  Flaws cause
  2346. instructions to produce results that are in error by plus or minus one,
  2347. in some sense.  If the value of GenPerFlaw were 0.5, it would mean that in
  2348. each generation, each cell would be hit by roughly two flaws.  This parameter
  2349. has a profound effect on the rate at which creatures shrink in size under
  2350. selection for small size.
  2351.  
  2352. GenPerMovMut = 8    mutation rate control by generations (copy mutation)
  2353.  
  2354.      Control of the move mutation rate (copy mutation).  The value 8
  2355. indicates that in each generation, roughly one in eight cells will be hit
  2356. by a mutation.  These mutations only affect copies of instructions made
  2357. during replication (by the double indirect mov instruction).  When an
  2358. instruction is affected by a mutation, one of its five bits is selected
  2359. at random and flipped.  If the value of GenPerMovMut were 0.5, it would
  2360. mean that in each generation, each cell would be hit by roughly two
  2361. move mutations.
  2362.  
  2363. IMapFile = opcode.map map of opcodes to instructions, file in GenebankPath
  2364.  
  2365.     Names the file containing the Instruction Set Map.  The simulator will
  2366. look for this file in the GenebankPath.  Please remember to only use
  2367. genebank files created with compatible map files.  If you specify the
  2368. name of the map file as: IMapFile = -.map
  2369. then the file will not be read, and the default opcode mapping will be used.
  2370.  
  2371. MalMode = 1 0 = first fit, 1 = better fit, 2 = random preference,
  2372. # 3 = near mother's address, 4 = near dx address, 5 = near top of stack address
  2373. MalReapTol = 1  0 = reap by queue, 1 = reap oldest creature within MalTol
  2374. MalTol = 20 multiple of avgsize to search for free block
  2375.  
  2376. Memory allocation control:
  2377.  
  2378. Chris Stephenson of the IBM T. J. Watson Research Center
  2379. (cjs@yktem.vnet.ibm.com) has contributed a new memory allocator to Tierra,
  2380. based on a cartesian tree scheme that he developed.  The new allocator is
  2381. more efficient than the old and provides a variety of options for controlling
  2382. where offspring are placed.  Free blocks are maintained in a two dimensional
  2383. binary tree, in which daughter blocks can not be larger than their parents,
  2384. and blocks are ordered from left to right according to their position in
  2385. memory.
  2386.  
  2387. MalMode = 1 0 = first fit, 1 = better fit, 2 = random preference,
  2388. # 3 = near mother's address, 4 = near dx address, 5 = near top of stack address
  2389.  
  2390.      This variable provides six options for controlling where offspring are
  2391. placed in the soup.  0 = first fit: this is the method used in versions of
  2392. Tierra before V4.0.  In this method, free blocks are checked starting with
  2393. the leftmost block in memory, and the first block large enough to accomodate
  2394. the request us used.
  2395.  
  2396.      1 = better fit: this method starts from the root of the tree, and if the
  2397. free block is larger than the request, it moves to the daughter free block
  2398. that is closest to the size of the request, this provides a better fit of the
  2399. request to the free block, but not necessarily the best fit.
  2400.  
  2401.      2 = random preference: blocks of memory are allocated at positions
  2402. selected at random from the soup.
  2403.  
  2404.      3 = near mother's address: blocks of memory will be placed near the
  2405. creature making the request (daughters will be placed near mothers), within
  2406. the specified tolerance (see MalReapTol and MalTol).
  2407.  
  2408.      4 = near dx address: blocks of memory will be placed near the address
  2409. specified in the dx register, within the specified tolerance (see MalReapTol
  2410. and MalTol).
  2411.  
  2412.      5 = near top of stack address: blocks of memory will be placed near the
  2413. address specified at the top of the stack, within the specified tolerance
  2414. (see MalReapTol and MalTol).
  2415.  
  2416. MalReapTol = 1  0 = reap by queue, 1 = reap oldest creature within MalTol
  2417.  
  2418.      When a position and tolerance is specified for the daughter cell, the
  2419. reaper will probably have to free memory in that area to service the request.
  2420. If the reaper kills strictly by the reaper queue, without regard to location,
  2421. it may kill many cells before killing in the vicinity of the request.  This
  2422. creates situations in which it is difficult for populations to grow, because
  2423. the reaper kills much more than is necessary.  To resolve this problem, an
  2424. option is added in which the reaper still uses the queue, but it only kills
  2425. cells that fall within the tolerance region of the requested location.
  2426. The variable MalReapTol turns this option on.
  2427.  
  2428. MalTol = 20 multiple of avgsize to search for free block
  2429.  
  2430.      This determines a region of tolerance within which a request for a
  2431. specific location of memory can be serviced.  It is specified as a multiple
  2432. of the average creature size.
  2433.  
  2434. MateProb = 0.2  probability of mating at each mal
  2435. MateSearchL = 5 multiple of avgsize to search 0 = no limit
  2436. MateSizeEp = 2 size epsilon for potential mate
  2437. MateXoverProp = 1.0 proportion of gene to secect for crossover point
  2438.  
  2439. Haploid Sex (aka crosover):
  2440.  
  2441. Haploid sex has been implemented in mimicry of Walter Tackett's
  2442. (tackett@ipld01.hac.com) implementation
  2443. in his private version of Tierra.  This form of sex is more in the spirit
  2444. of the genetic algorithm that Tierra, in that the creatures don't have any
  2445. choice in the matter, they are forced to have sex at god's whim.  However,
  2446. it does have the virtue of creating something like a biological species, in
  2447. that individuals close in size exchange genes creating an evolving gene pool.
  2448.  
  2449. The Tierran reproduction mechanism of repeatedly copying data from an offset
  2450. in the mother cell to an offset (presumably) in a daughter cell, can be
  2451. modified to easily allow ``crossover'' of genetic data.  Crossover seems to
  2452. provide a means of increasing the rate of evolution.  It can be thought of as
  2453. a higher mutation rate which can ``favor good genes''.  This affect will be
  2454. made clear by euclidating how haploid crossover ``sex'' is done in the
  2455. Tierran model.
  2456.  
  2457. At the time a creature allocates a block of memory for a daughter (mal),
  2458. Tierra decides if this creature will mate, using the soup_in variable
  2459. MateProb (0.0 = no mating at all, 100.0 = creatures will try to mate 100% of
  2460. the time). If the creature is not selected for mating, Tierra continues
  2461. as normal until the next time this creature executes a memory allocate.
  2462. If this creature does mate, a point in the creatures genome, selected
  2463. randomly from the proportion MateXoverProp of the genome size, is chosen 
  2464. as the ``cross over'' point.  Also whether we use the first part, or the last 
  2465. part of the genome is also chosen (chances are 1 in 2 for each "half").  
  2466. No further actions are taken until the creature begins moving data 
  2467. (presumably from herself, to the daughter cell).
  2468.  
  2469. At the time that the creature first copies an instruction of its genome to
  2470. a new location (presumably in the daughter cell) using the moviab instruction,
  2471. a mate is chosen.  The mate is chosen at this point because the chances 
  2472. of the mate dying before the cross over is complete are smaller now than
  2473. at the time of the memory allocation.  A potential mate must be similar
  2474. in size to the creature trying to mate (creature's size +/- MateSizeEp),
  2475. and may not be of the exact same genotype (eg. 0080aaa can't mate
  2476. with another 0080aaa, there would be no point in the operation).  The
  2477. search radius from the creature to the mate is determinied by MateSearchL.
  2478. MateSearchL is multiplied by the Average Creature Size to determine the
  2479. number of bytes to search.  NOTE - in release 3.13, only FORWARD ( towards
  2480. higher addresses ) in done.  This will become bidirectional in future 
  2481. releases.  Even if a creature is selected for mating a the time of execution
  2482. of the mal instruction, it may not actually mate, because it may not be
  2483. able to find a mate of a different genotype, in the correct size range, and
  2484. within the search radius.
  2485.  
  2486. If we have chosen to contribute our first section to the daughter, our mate
  2487. will contribute the second section.  In that case, the copying of the genome
  2488. will proceed normally until we reach the crossover point.  After that, each
  2489. time we execute the moviab instruction, we will copy an instruction from
  2490. the genome of our mate rather than from our genome.  The creature is
  2491. ``unaware'' of this process.  For the sake of clarity an example is given:
  2492.  
  2493. Example A - Mate contributes second half :
  2494.  
  2495.   creature ( 10 bytes long ) & mate ( 9 bytes long )
  2496.   [ step 0 ] mal - selects Xover point of 5, second half
  2497.   [ step 1 ] move bytes at offset 0-4 from self
  2498.   [ step 2 ] move byte at offset 5-9 from mate
  2499.   [ step 3 ] move byte after last byte of mate ( 10th byte )
  2500.  
  2501. Example B - Mate contributes first half :
  2502.  
  2503.   creature ( 10 bytes long ) & mate ( 11 bytes long )
  2504.   [ step 0 ] mal - selects Xover point of 5, first half
  2505.   [ step 1 ] move bytes at offset 0-4 from mate
  2506.   [ step 2 ] move byte at offset 5-10 from self 
  2507.  
  2508. MaxMalMult = 3        multiple of cell size allowed for mal()
  2509.  
  2510.      When a cell attempts to allocate a second block of memory (presumably
  2511. to copy its genome into), this parameter is checked.  If the amount of memory
  2512. requested is greater than MaxMalMult times the size of the mother cell, the
  2513. request will fail.  This prevents mutants from requesting the entire soup,
  2514. which would invoke the reaper to cause a massive kill off.
  2515.  
  2516. MemModeFree = 0  read, write, execute protection for free memory
  2517.  
  2518.      When memory is free, not owned by any creature, it will have this
  2519. protection.  0 means that anybody can read, write, or execute the memory.
  2520.  
  2521. MemModeProt = 2 rwx protect mem: 1 bit = execute, 2 bit = write, 4 bit = read
  2522.  
  2523.      When memory is owned by a creature, it will have this protection.
  2524. 2 means that write privelage is protected, so only the owner can write on
  2525. the memory.  The owner always has read write, execute privelages on owned
  2526. memory.  However, other creatures must obey the MemModeProt protection,
  2527. they are excluded from the activities whose bits are set.  Be aware that
  2528. each of the three forms of memory protection is turned on at compile time
  2529. by the appropriate definitions:
  2530.  
  2531. #define READPROT     /* define to implement read protection of soup */
  2532. #define WRITEPROT    /* define to implement write protection of soup */
  2533. #define EXECPROT     /* define to implement execute protection of soup */
  2534.  
  2535.      The version distributed on disk only has write protection turned on.
  2536. To implement the other forms of protection you will need to comment in
  2537. the appropriate line in the configur.h file, and recompile.  Once the
  2538. relevant form of protection is defined at compile time, the MemModeProt
  2539. variable still determines whether it is actually used.  We do this because
  2540. each form of memory protection is costly of cpu time, and write protection
  2541. is the only one likely to be used.
  2542.  
  2543. MinCellSize = 8       minimum size for cells
  2544.  
  2545.      When a cell attempts to divide, this parameter is checked.  If the
  2546. daughter cell would be smaller than MinCellSize instructions, divide will
  2547. fail.  The reason this is needed is that with no lower limit, there is a
  2548. tendency for some mutants to spawn large numbers of very small cells.
  2549.  
  2550. MinTemplSize = 1       minimum size for templates
  2551.  
  2552.      When an instruction (like jump) attempts to use a template, this
  2553. parameter is checked.  If the actual template is smaller than MinTemplSize
  2554. instructions, the instruction will fail.  This is a matter of taste.
  2555.  
  2556. MovPropThrDiv = .7       minimum proportion of daughter cell filled by mov
  2557.  
  2558.      When a cell attempts to divide, this parameter is checked.  If the
  2559. mother cell has moved less than MovPropThrDiv times the mother cell size, of
  2560. instructions into the daughter cell, cell division will abort.  A value of .7
  2561. means that the mother must at least fill the daughter 70% with instructions
  2562. (though all these instructions could have been moved to the same spot in
  2563. the daughter cell).  The reason this parameter exists is that without it,
  2564. mutants will attempt to spew out large numbers of empty cells.
  2565.  
  2566. new_soup = 1          1 = this a new soup, 0 = restarting an old run
  2567.  
  2568.      This value is checked on startup, to determine if this is a new soup,
  2569. or if this is restarting an old run where it left off.  When the system
  2570. comes down, all soup_in parameter (and many other global variables) are
  2571. saved in a file called soup_out.  The value of new_soup is set to 0 in
  2572. soup_out.  In order to restart an old run, just use soup_out as the input
  2573. file rather than soup_in.  This is done by using soup_out as a command line
  2574. parameter at startup: tierra soup_out
  2575.  
  2576. NumCells = 3      number of creatures and gaps used to inoculate new soup
  2577.  
  2578.      This parameter is checked at startup, and the system will look for a
  2579. list of NumCells creatures at the end of the soup_in file.  The value 3
  2580. indicates that the soup will initially be innoculated by three cells.
  2581. However, NumCells also counts gaps that are placed between cells (without
  2582. gaps, all cells are packed together at the bottom of the soup at startup).
  2583. The gap control feature does not work at present, so don't use it.  Notice
  2584. that after the list of parameters in the soup_in file, there is a blank
  2585. line, followed by a list of genotypes.  The system will read the first 
  2586. NumCells genotypes from the list, and place them in the soup in the same
  2587. order that they occur in the list.
  2588.  
  2589. PhotonPow = 1.5         power for photon match slice size
  2590.  
  2591.      If SliceStyle (see below) is set to the value 1, then the allocation
  2592. of CPU cycles to creatures is based on a photon - chlorophyll metaphor.
  2593. Imagine that photons are raining down on the soup at random.  The cell hit
  2594. by the photon gets a time slice that is proportional to the goodness of fit
  2595. between the pattern of instructions that are hit, and an arbitrary pattern
  2596. (defined by PhotonWord, see below).
  2597.  
  2598.      The template of instructions defined by PhotonWord is laid over the
  2599. sequence of instructions at the site hit by the photon.  The number of
  2600. instructions that match between the two is used to determine the slice
  2601. size.  However, the number of matching instructions is raised to the power
  2602. PhotonPow, to calculate the slice size.
  2603.  
  2604. PhotonWidth = 8   amount by which photons slide to find best fit
  2605.  
  2606.      When a photon hits the soup, it slides a distance PhotonWidth, counting
  2607. the number of matching characters at each position, and the slice size will
  2608. be equal to the number of characters in the best match (raised to the power
  2609. PhotonPow, see above).  If PhotonWidth equals 8, the center of the template
  2610. will start 4 instructions to the left of the site hit by the photon, and
  2611. slide to 4 instructions to the right of the site hit.
  2612.  
  2613. PhotonWord = chlorophill  word used to define photon
  2614.  
  2615.      This string determines the arbitrary pattern that absorbs the photon.
  2616. It uses a base 32 numbering system: the digits 0-9 followed by the characters
  2617. a-v.  The characters w, x, y and z are not allowed (that is why chlorophyll
  2618. is misspelled).  The string may be any length up to 79 characters.
  2619.  
  2620. ReapRndProp = .3 top prop of reaper que to reap from
  2621.  
  2622.      This parameter determines the degree to which mortality is random.
  2623. If ReapRndProp is set to zero, the reaper always kills the creature at the
  2624. top of the reaper queue.  If ReapRndProp is set to one, the reaper kills
  2625. at random.  If ReapRndProp is set to 0.3, the reaper will kill a cell selected
  2626. at random from the top 30% of the reaper queue.
  2627.  
  2628. SearchLimit = 5
  2629.  
  2630.      This parameter controls how far instructions may search to match
  2631. templates.  The value five means that search is limited to five times the
  2632. average adult cell size.  The actual distance is updated every million
  2633. instructions.
  2634.  
  2635. seed = 0 seed for random number generator, 0 uses time to set seed
  2636.  
  2637.      The seed for the random number generator.  If you use the value zero,
  2638. the system clock combined with the random number generator is used to set the
  2639. seed.  If you use any other value, it will be the seed.  The starting seed
  2640. (even when provided by the clock) will be written to standard output, the
  2641. tierra.log file, and also saved in the soup_out file when the simulator comes
  2642. down.  By using the original seed and all the same initial parameter settings
  2643. in soup_in, a run may be repeated exactly.
  2644.  
  2645. SizDepSlice = 0  set slice size by size of creature
  2646.  
  2647.      This determines a major slicer option.  If this parameter is set to
  2648. zero, the slice size will either be a constant set by SliceSize (see below)
  2649. or a uniform random variate, or a mix of the two.  The mix is determined by
  2650. the relative values of SlicFixFrac and SlicRanFrac (see below).  The actual
  2651. slice size will be:
  2652.  
  2653. (SlicFixFrac * SliceSize) + (tlrand() % (I32s) ((SlicRanFrac * SliceSize) + 1))
  2654.  
  2655.      If SizDepSlice is set to a non-zero value, the slice size will be
  2656. proportional to the size of the genome.  In this case, the base slice size
  2657. will be the genome size raised to the power SlicePow (see below).  To clarify
  2658. let slic_siz = genome_size ^ SlicePow, the actual slice size will be:
  2659.  
  2660. (SlicFixFrac * slic_siz) + (tlrand() % (I32s) ((SlicRanFrac * slic_siz) + 1))
  2661.  
  2662. SlicePow = 1    set power for slice size, use when SizDepSlice = 1
  2663.  
  2664.      This parameter is only used when SizDepSlice = 1.  In this case, the
  2665. genome size is raised to the power SlicePow to determine the slice size
  2666. (see algorithm under SizDepSlice above).  If SlicePow = 1, the run will be
  2667. size neutral, selection will not be biased toward either large or small
  2668. creatures (the probability of an instruction being executed is not dependent
  2669. on the size of the genome it is located in).  If SlicePow > 1, selection will
  2670. favor larger genomes.  If SlicePow < 1, selection will favor small genomes.
  2671.  
  2672. SliceSize = 25    slice size when SizDepSlice = 0
  2673.  
  2674.      This parameter determines the base slice size when SizDepSlice = 0.
  2675. The actual slice size in this case depends on the values of SlicFixFrac
  2676. and SlicRanFrac (see below).  The way the slice size is actually calculated
  2677. is explained under SizDepSlice above.
  2678.  
  2679. SliceStyle = 2   choose style of determining slice size
  2680.  
  2681.      The slicer is a pointer to function, and the function actually used
  2682. is determined by this parameter.  At present there are three choices (0-2).
  2683. The pointer to function is assigned in the setup.c module, and the slicer
  2684. functions themselves are contained in the slicers.c module.
  2685. 0 = SlicerQueue() - slice sizes without a random component
  2686. 1 = SlicerPhoton() - slice size based on photon interception metaphor
  2687. 2 = RanSlicerQueue() - slice size with a fixed and a random component
  2688.  
  2689. SlicFixFrac = 0   fixed fraction of slice size
  2690.  
  2691.      When SliceStyle = 2, the slice size has a fixed component and a random
  2692. component.  This parameter determines the fixed component as a multiple
  2693. of SliceSize, or genome_size ^ SlicePow.
  2694.  
  2695. SlicRanFrac = 2   random fraction of slice size
  2696.  
  2697.      When SliceStyle = 2, the slice size has a fixed component and a random
  2698. component.  This parameter determines the random component as a multiple
  2699. of SliceSize, or genome_size ^ SlicePow.
  2700.  
  2701. SoupSize = 50000 size of soup in instructions
  2702.  
  2703.      This variable sets the size of the soup, measured in instructions.
  2704.  
  2705. space 10000
  2706. 0080aaa
  2707. space 10000
  2708. 0045aaa
  2709. space 10000
  2710. 0080aaa
  2711.  
  2712.      This is the list of cells that will be loaded into the soup when
  2713. the simulator starts up.  This example indicates that three cells will
  2714. be loaded at startup, the ancestor 0080aaa alternating with the parasite
  2715. 0045aaa.  The line:
  2716.  
  2717. space 10000
  2718.  
  2719. indicates that a space of ten thousand instructions will be left before the
  2720. cell that follows.  Therefore the first cell will start after 10,000 blank
  2721. instructions, and there will be 10,000 instructions between each of the
  2722. three creatures.
  2723.  
  2724. 8)  THE INSTRUCTION SETS
  2725.   8.1) Synopsis of the Four Sets
  2726.   8.2) Details of Set 1
  2727.   8.3) New Features in Sets 2 through 4
  2728.  
  2729.   8.1) Synopsis of the Four Sets
  2730.  
  2731.      At present, four instruction sets have been implemented.  They are
  2732. INST == 1, INST == 2, INST == 3, and INST == 4.  The associations of opcodes,
  2733. mnemonics, parsing functions and executables that define this instruction set
  2734. are determined by an array of the following structures (defined in the
  2735. tierra.h file):
  2736.  
  2737. typedef struct { /* structure for instruction set definitions */
  2738.     I8s op;                         /* op code */
  2739.     I8s mn[9];                      /* assembler mnemonic */
  2740.     void (*execute) P_((Cell  *));  /* pointer to execute function */
  2741.     void (*parse) P_((Cell  *));    /* pointer to parse function */
  2742. } InstDef; /* this structure is defined in tierra.h */
  2743.  
  2744. InstDef id[INSTNUM];
  2745.  
  2746.      The parsing functions are contained in the parse1.c, parse2.c, parse3.c,
  2747. and parse4.c files, which are conditionally included by the parse.c file.
  2748. The executables are contained in the instruct.c file.
  2749.  
  2750. ******************************************************************************
  2751.  
  2752. Instset #1  the original instruction set, designed and implemented by
  2753.     Tom Ray.
  2754.  
  2755.     This instruction set operates on a cpu based on the following definitions:
  2756.  
  2757. #define INSTBITNUM 5
  2758. #define INSTNUM 32      /* INSTNUM = 2 ^ INSTBITNUM */
  2759. #define INST 1
  2760. #define STACK_SIZE 10
  2761. #define ALOC_REG 4
  2762. #define NUMREG 4        /* NUMREG = ALOC_REG */
  2763.  
  2764. typedef struct {        /* structure for registers of virtual cpu */
  2765.     Reg re[ALOC_REG];   /* array of registers */
  2766.     Reg sp;             /* stack pointer */
  2767.     Reg st[STACK_SIZE]; /* stack */
  2768.     Reg ip;             /* instruction pointer */
  2769.     I8s fl;             /* flag */
  2770. } Cpu;
  2771.  
  2772. The four registers in the re[] array are referred to as follows:
  2773. AX = re[0], BX = re[1], CX = re[2], DX = re[3].
  2774.  
  2775. No Operations: 2
  2776.  
  2777. nop0
  2778. nop1
  2779.  
  2780. Memory Movement: 11
  2781.  
  2782. pushax (push AX onto stack)
  2783. pushbx (push BX onto stack)
  2784. pushcx (push CX onto stack)
  2785. pushdx (push DX onto stack)
  2786. popax  (pop from stack into AX)
  2787. popbx  (pop from stack into BX)
  2788. popcx  (pop from stack into CX)
  2789. popdx  (pop from stack into DX)
  2790. movcd  (DX = CX)
  2791. movab  (BX = AX)
  2792. movii  (move from ram [BX] to ram [AX])
  2793.  
  2794. Calculation: 9
  2795.  
  2796. sub_ab (CX = AX - BX)
  2797. sub_ac (AX = AX - CX)
  2798. inc_a  (increment AX)
  2799. inc_b  (increment BX)
  2800. inc_c  (increment CX)
  2801. dec_c  (decrement CX)
  2802. zero   (zero CX)
  2803. not0   (flip low order bit of CX)
  2804. shl    (shift left all bits of CX)
  2805.  
  2806. Instruction Pointer Manipulation: 5
  2807.  
  2808. ifz    (if CX == 0 execute next instruction, otherwise, skip it)
  2809. jmp    (jump to template)
  2810. jmpb   (jump backwards to template)
  2811. call   (push IP onto the stack, jump to template)
  2812. ret    (pop the stack into the IP)
  2813.  
  2814. Biological and Sensory: 5
  2815.  
  2816. adr    (search outward  for template, put address in AX, template size in CX)
  2817. adrb   (search backward for template, put address in AX, template size in CX)
  2818. adrf   (search forward  for template, put address in AX, template size in CX)
  2819. mal    (allocate amount of space specified in CX)
  2820. divide (cell division)
  2821.  
  2822. Total: 32 instructions
  2823.  
  2824. The following array defines the associations of opcodes, mnemonics,
  2825. executable functions, and parsing functions (in that order) used to
  2826. implement instruction set #1.
  2827.  
  2828.     {0x00, "nop0", nop, pnop},
  2829.     {0x01, "nop1", nop, pnop},
  2830.     {0x02, "not0", not0, pnot0},
  2831.     {0x03, "shl", shl, pshl},
  2832.     {0x04, "zero", movdd, pzero},
  2833.     {0x05, "ifz", ifz, pifz},
  2834.     {0x06, "sub_ab", math, psub_ab},
  2835.     {0x07, "sub_ac", math, psub_ac},
  2836.     {0x08, "inc_a", math, pinc_a},
  2837.     {0x09, "inc_b", math, pinc_b},
  2838.     {0x0a, "dec_c", math, pdec_c},
  2839.     {0x0b, "inc_c", math, pinc_c},
  2840.     {0x0c, "pushax", push, ppushax},
  2841.     {0x0d, "pushbx", push, ppushbx},
  2842.     {0x0e, "pushcx", push, ppushcx},
  2843.     {0x0f, "pushdx", push, ppushdx},
  2844.     {0x10, "popax", pop, ppopax},
  2845.     {0x11, "popbx", pop, ppopbx},
  2846.     {0x12, "popcx", pop, ppopcx},
  2847.     {0x13, "popdx", pop, ppopdx},
  2848.     {0x14, "jmp", adr, ptjmp},
  2849.     {0x15, "jmpb", adr, ptjmpb},
  2850.     {0x16, "call", tcall, ptcall},
  2851.     {0x17, "ret", pop, pret},
  2852.     {0x18, "movcd", movdd, pmov_dc},
  2853.     {0x19, "movab", movdd, pmov_ba},
  2854.     {0x1a, "movii", movii, pmovii},
  2855.     {0x1b, "adr", adr, padr},
  2856.     {0x1c, "adrb", adr, padrb},
  2857.     {0x1d, "adrf", adr, padrf},
  2858.     {0x1e, "mal", malchm, pmal},
  2859.     {0x1f, "divide", divide, pdivide}
  2860.  
  2861. ******************************************************************************
  2862.  
  2863. Instset #2  Based on a design suggested by Kurt Thearling of Thinking Machines,
  2864.     and implemented by Tom Ray.  The novel feature of this instruction set
  2865.     is the ability to reorder the relative positions of the registers, using
  2866.     the AX, BX, CX and DX instructions.  There are in essence, two sets of
  2867.     registers, the first set contains the values that the instruction set
  2868.     operates on, the second set points to the first set, in order to determine
  2869.     which registers any operation will act on.
  2870.  
  2871.     Let the four registers containing values be called AX, BX, CX and DX.
  2872.     Let the four registers pointing to these registers be called R0, R1, R2
  2873.     and R3.  When a virtual cpu is initialized, R0 points to AX, R1 to BX,
  2874.     R2 to CX and R3 to DX.  The instruction "add" does the following:
  2875.     (R2 = R1 + R0).  Therefore CX = BX + AX.  However, if we execute the DX
  2876.     instruction, the R0 points to DX, R1 to AX, R2 to BX and R3 to CX.  Now
  2877.     if we execute the add instruction, we will perform: BX = AX + DX.  If we
  2878.     execute the DX instruction again, R0 points to DX, R1 to DX, R2 to AX,
  2879.     and R3 to BX.  Now the add instruction would perform: AX = DX + DX.
  2880.     Now the registers can be returned to their original configuration by
  2881.     executing the following three instructions in order: cx, bx, ax.
  2882.  
  2883.     This instruction set operates on a cpu based on the following definitions:
  2884.  
  2885. #define INSTBITNUM 5
  2886. #define INSTNUM 32       /* INSTNUM = 2 ^ INSTBITNUM */
  2887. #define INST 2
  2888. #define STACK_SIZE 10
  2889. #define ALOC_REG 8
  2890. #define NUMREG 4         /* NUMREG = ALOC_REG / 2 */
  2891. #define GETBUFSIZ 3
  2892. #define PUTBUFSIZ 3
  2893.  
  2894. typedef struct {         /* structure for registers of virtual cpu */
  2895.     Reg re[ALOC_REG];    /* array of registers */
  2896.     Reg sp;              /* stack pointer */
  2897.     Reg st[STACK_SIZE];  /* stack */
  2898.     Reg gb[GETBUFSIZ+3]; /* input buffer */
  2899.     Reg pb[PUTBUFSIZ+3]; /* output buffer */
  2900.     Reg ip;              /* instruction pointer */
  2901.     I8s fl;              /* flag */
  2902. } Cpu;
  2903.  
  2904. The eight registers in the re[] array are referred to as follows:
  2905. AX = re[0], BX = re[1], CX = re[2], DX = re[3],
  2906. R0 = re[4], R1 = re[5], R2 = re[6], R3 = re[7].
  2907.  
  2908. No Operations: 2
  2909.  
  2910. nop0
  2911. nop1
  2912.  
  2913. Memory Movement: 12
  2914.  
  2915. ax     (make AX R0, R1 = R0, R2 = R1, R3 = R2, R3 is lost)
  2916. bx     (make BX R0, R1 = R0, R2 = R1, R3 = R2, R3 is lost)
  2917. cx     (make CX R0, R1 = R0, R2 = R1, R3 = R2, R3 is lost)
  2918. dx     (make DX R0, R1 = R0, R2 = R1, R3 = R2, R3 is lost)
  2919.  
  2920. movdd  (move R1 to R0)
  2921. movdi  (move from R1 to ram [R0])
  2922. movid  (move from ram [R1] to R0)
  2923. movii  (move from ram [R1] to ram [R0])
  2924. push   (push R0 onto stack)
  2925. pop    (pop from stack into R0)
  2926. put    (write R0 to output buffer, three modes:
  2927.          #ifndef ICC: write R0 to own output buffer
  2928.          #ifdef ICC:  write R0 to input buffer of cell at address R1,
  2929.            or, if template, write R0 to input buffers of all creatures within
  2930.            PutLimit who have the complementary get template)
  2931. get    (read R0 from input port)
  2932.  
  2933. Calculation: 8
  2934.  
  2935. inc    (increment R0)
  2936. dec    (decrement R0)
  2937. add    (R2 = R1 + R0)
  2938. sub    (R2 = R1 - R0)
  2939. zero   (zero R0)
  2940. not0   (flip low order bit of R0)
  2941. shl    (shift left all bits of R0)
  2942. not    (flip all bits of R0)
  2943.  
  2944. Instruction Pointer Manipulation: 5
  2945.  
  2946. ifz  (if   R1 == 0 execute next instruction, otherwise, skip it)
  2947. iffl (if flag == 1 execute next instruction, otherwise, skip it)
  2948. jmp  (jump to template, or if no template jump to address in R0)
  2949. jmpb (jump back to template, or if no template jump back to address in R0)
  2950. call (push IP + 1 onto the stack; if template, jump to complementary templ)
  2951.  
  2952. Biological and Sensory: 5
  2953.  
  2954. adr    (search outward for template, put address in R0, template size in R1,
  2955.            and offset in R2, start search at offset +- R0)
  2956. adrb   (search backward for template, put address in R0, template size in R1,
  2957.            and offset in R2, start search at offset - R0)
  2958. adrf   (search forward for template, put address in R0, template size in R1,
  2959.            and offset in R2, start search at offset + R0)
  2960. mal    (allocate amount of space specified in R0, prefer address at R1,
  2961.            if R1 < 0 use better fit, place address of allocated block in R0)
  2962. divide (cell division, the IP is offset by R0 into the daughter cell, the
  2963.            values in the four CPU registers are transferred from mother to
  2964.            daughter, but not the stack.  If !R1, eject genome from soup)
  2965.  
  2966. Total: 32 instructions
  2967.  
  2968. The following array defines the associations of opcodes, mnemonics,
  2969. executable functions, and parsing functions (in that order) used to
  2970. implement instruction set #2.
  2971.  
  2972.     {0x00, "nop0", nop, pnop},
  2973.     {0x01, "nop1", nop, pnop},
  2974.     {0x02, "ax", regorder, pax},
  2975.     {0x03, "bx", regorder, pbx},
  2976.     {0x04, "cx", regorder, pcx},
  2977.     {0x05, "dx", regorder, pdx},
  2978.     {0x06, "movdd", movdd, pmovdd},
  2979.     {0x07, "movdi", movdi, pmovdi},
  2980.     {0x08, "movid", movid, pmovid},
  2981.     {0x09, "movii", movii, pmovii},
  2982.     {0x0a, "push", push, ppush},
  2983.     {0x0b, "pop", pop, ppop},
  2984.     {0x0c, "put", put, pput},
  2985.     {0x0d, "get", get, pget},
  2986.     {0x0e, "inc", math, pinc},
  2987.     {0x0f, "dec", math, pdec},
  2988.     {0x10, "add", math, padd},
  2989.     {0x11, "sub", math, psub},
  2990.     {0x12, "zero", movdd, pzero},
  2991.     {0x13, "shl", shl, pshl},
  2992.     {0x14, "not0", not0, pnot0},
  2993.     {0x15, "not", not, pnot},
  2994.     {0x16, "ifz", ifz, pifz},
  2995.     {0x17, "iffl", ifz, piffl},
  2996.     {0x18, "jmp", adr, ptjmp},
  2997.     {0x19, "jmpb", adr, ptjmpb},
  2998.     {0x1a, "call", tcall, ptcall},
  2999.     {0x1b, "adr", adr, padr},
  3000.     {0x1c, "adrb", adr, padrb},
  3001.     {0x1d, "adrf", adr, padrf},
  3002.     {0x1e, "mal", malchm, pmal},
  3003.     {0x1f, "divide", divide, pdivide}
  3004.  
  3005. ******************************************************************************
  3006.  
  3007. Instset #3  Based on a design suggested and implemented by Tom Ray.  This
  3008.     includes certain features of the RPN Hewlett-Packard calculator.
  3009.  
  3010.     This instruction set operates on a cpu based on the following definitions:
  3011.  
  3012. #define INSTBITNUM 5
  3013. #define INSTNUM 32       /* INSTNUM = 2 ^ INSTBITNUM */
  3014. #define INST 3
  3015. #define STACK_SIZE 10
  3016. #define ALOC_REG 4
  3017. #define NUMREG 4         /* NUMREG = ALOC_REG */
  3018. #define GETBUFSIZ 3
  3019. #define PUTBUFSIZ 3
  3020.  
  3021. typedef struct {         /* structure for registers of virtual cpu */
  3022.     Reg re[ALOC_REG];    /* array of registers */
  3023.     Reg sp;              /* stack pointer */
  3024.     Reg st[STACK_SIZE];  /* stack */
  3025.     Reg gb[GETBUFSIZ+3]; /* input buffer */
  3026.     Reg pb[PUTBUFSIZ+3]; /* output buffer */
  3027.     Reg ip;              /* instruction pointer */
  3028.     I8s fl;              /* flag */
  3029. } Cpu;
  3030.  
  3031. The four registers in the re[] array are referred to as follows:
  3032. AX = re[0], BX = re[1], CX = re[2], DX = re[3].
  3033.  
  3034. No Operations: 2
  3035.  
  3036. nop0
  3037. nop1
  3038.  
  3039. Memory Movement: 11
  3040.  
  3041. rollu  (roll registers up:   AX = DX, BX = AX, CX = BX, DX = CX)
  3042. rolld  (roll registers down: AX = BX, BX = CX, CX = DX, DX = AX)
  3043. enter  (AX = AX, BX = AX, CX = BX, DX = CX, DX is lost)
  3044. exch   (AX = BX, BX = AX)
  3045. movdi  (move from BX to ram [AX])
  3046. movid  (move from ram [BX] to AX)
  3047. movii  (move from ram [BX] to ram [AX])
  3048. push   (push AX onto stack)
  3049. pop    (pop from stack into AX)
  3050. put    (write AX to output buffer, three modes:
  3051.          #ifndef ICC: write AX to own output buffer
  3052.          #ifdef ICC:  write AX to input buffer of cell at address BX,
  3053.            or, if template, write AX to input buffers of all creatures within
  3054.            PutLimit who have the complementary get template)
  3055. get    (read AX from input buffer)
  3056.  
  3057. Calculation: 9
  3058.  
  3059. inc    (increment AX)
  3060. dec    (decrement AX)
  3061. add    (AX = BX + AX, BX = CX, CX = DX))
  3062. sub    (AX = BX - AX, BX = CX, CX = DX))
  3063. zero   (zero AX)
  3064. not0   (flip low order bit of AX)
  3065. not    (flip all bits of AX)
  3066. shl    (shift left all bits of AX)
  3067. rand   (place random number in AX)
  3068.  
  3069. Instruction Pointer Manipulation: 5
  3070.  
  3071. ifz  (if   AX == 0 execute next instruction, otherwise, skip it)
  3072. iffl (if flag == 1 execute next instruction, otherwise, skip it)
  3073. jmp  (jump to template, or if no template jump to address in AX)
  3074. jmpb (jump back to template, or if no template jump back to address in AX)
  3075. call (push IP + 1 onto the stack; if template, jump to complementary templ)
  3076.  
  3077. Biological and Sensory: 5
  3078.  
  3079. adr    (search outward for template, put address in AX, template size in BX,
  3080.            and offset in CX, start search at offset +- BX)
  3081. adrb   (search backward for template, put address in AX, template size in BX,
  3082.            and offset in CX, start search at offset - BX)
  3083. adrf   (search forward for template, put address in AX, template size in BX,
  3084.            and offset in CX, start search at offset + BX)
  3085. mal    (allocate amount of space specified in BX, prefer address at AX,
  3086.            if AX < 0 use better fit, place address of allocated block in AX)
  3087. divide (cell division, the IP is offset by AX into the daughter cell, the
  3088.            values in the four CPU registers are transferred from mother to
  3089.            daughter, but not the stack. If !CX genome will be ejected from
  3090.            the simulator)
  3091.  
  3092. Total: 32 instructions
  3093.  
  3094. The following array defines the associations of opcodes, mnemonics,
  3095. executable functions, and parsing functions (in that order) used to
  3096. implement instruction set #3.
  3097.  
  3098.     {0x00, "nop0", nop, pnop},
  3099.     {0x01, "nop1", nop, pnop},
  3100.     {0x02, "rollu", rollu, pnop},
  3101.     {0x03, "rolld", rolld, pnop},
  3102.     {0x04, "enter", enter, pnop},
  3103.     {0x05, "exch", exch, pnop},
  3104.     {0x06, "movdi", movdi, pmovdi},
  3105.     {0x07, "movid", movid, pmovid},
  3106.     {0x08, "movii", movii, pmovii},
  3107.     {0x09, "push", push, ppush},
  3108.     {0x0a, "pop", pop3, ppop},
  3109.     {0x0b, "put", put, pput},
  3110.     {0x0c, "get", get, pget},
  3111.     {0x0d, "inc", math, pinc},
  3112.     {0x0e, "dec", math, pdec},
  3113.     {0x0f, "add", math3, padd},
  3114.     {0x10, "sub", math3, psub},
  3115.     {0x11, "zero", movdd3, pzero},
  3116.     {0x12, "shl", shl, pshl},
  3117.     {0x13, "not0", not0, pnot0},
  3118.     {0x14, "not", not, pnot},
  3119.     {0x15, "rand", movdd3, prand},
  3120.     {0x16, "ifz", ifz, pifz},
  3121.     {0x17, "iffl", ifz, piffl},
  3122.     {0x18, "jmp", adr, ptjmp},
  3123.     {0x19, "jmpb", adr, ptjmpb},
  3124.     {0x1a, "call", tcall, ptcall},
  3125.     {0x1b, "adr", adr3, padr},
  3126.     {0x1c, "adrb", adr3, padrb},
  3127.     {0x1d, "adrf", adr3, padrf},
  3128.     {0x1e, "mal", malchm3, pmal},
  3129.     {0x1f, "divide", divide, pdivide}
  3130.  
  3131. ******************************************************************************
  3132.  
  3133. Instset #4 Based on a design suggested by Walter Tackett of Hughes Aircraft,
  3134.     and implemented by Tom Ray.  The special features of this instruction
  3135.     set are that all movement between registers of the cpu takes place via
  3136.     push and pop through the stack.  Also, all indirect addressing involves
  3137.     an offset from the address in the CX register.  Also, the CX register
  3138.     is where most calculations take place.
  3139.  
  3140.     This instruction set operates on a cpu based on the following definitions:
  3141.  
  3142. #define INSTBITNUM 5
  3143. #define INSTNUM 32       /* INSTNUM = 2 ^ INSTBITNUM */
  3144. #define INST 3
  3145. #define STACK_SIZE 10
  3146. #define ALOC_REG 4
  3147. #define NUMREG 4         /* NUMREG = ALOC_REG */
  3148. #define GETBUFSIZ 3
  3149. #define PUTBUFSIZ 3
  3150.  
  3151. typedef struct {         /* structure for registers of virtual cpu */
  3152.     Reg re[ALOC_REG];    /* array of registers */
  3153.     Reg sp;              /* stack pointer */
  3154.     Reg st[STACK_SIZE];  /* stack */
  3155.     Reg gb[GETBUFSIZ+3]; /* input buffer */
  3156.     Reg pb[PUTBUFSIZ+3]; /* output buffer */
  3157.     Reg ip;              /* instruction pointer */
  3158.     I8s fl;              /* flag */
  3159. } Cpu;
  3160.  
  3161. The four registers in the re[] array are referred to as follows:
  3162. AX = re[0], BX = re[1], CX = re[2], DX = re[3].
  3163.  
  3164. No Operations: 2
  3165.  
  3166. nop0
  3167. nop1
  3168.  
  3169. Memory Movement: 13
  3170.  
  3171. movdi  (move from BX to ram [AX + CX])
  3172. movid  (move from ram [BX + CX] to AX)
  3173. movii  (move from ram [BX + CX] to ram [AX + CX])
  3174. pushax (push AX onto stack)
  3175. pushbx (push BX onto stack)
  3176. pushcx (push CX onto stack)
  3177. pushdx (push DX onto stack)
  3178. popax  (pop from stack into AX)
  3179. popbx  (pop from stack into BX)
  3180. popcx  (pop from stack into CX)
  3181. popdx  (pop from stack into DX)
  3182. put    (write DX to output buffer, three modes:
  3183.          #ifndef ICC: write DX to own output buffer
  3184.          #ifdef ICC:  write DX to input buffer of cell at address CX,
  3185.            or, if template, write DX to input buffers of all creatures within
  3186.            PutLimit who have the complementary get template)
  3187. get    (read DX from input port)
  3188.  
  3189. Calculation: 7
  3190.  
  3191. inc    (increment CX)
  3192. dec    (decrement CX)
  3193. add    (CX = CX + DX)
  3194. sub    (CX = CX - DX)
  3195. zero   (zero CX)
  3196. not0   (flip low order bit of CX)
  3197. shl    (shift left all bits of CX)
  3198.  
  3199. Instruction Pointer Manipulation: 5
  3200.  
  3201. ifz    (if   CX == 0 execute next instruction, otherwise, skip it)
  3202. iffl   (if flag == 1 execute next instruction, otherwise, skip it)
  3203. jmp    (jump to template, or if no template jump to address in AX)
  3204. jmpb   (jump back to template, or if no template jump back to address in AX)
  3205. call   (push IP + 1 onto the stack; if template, jump to complementary templ)
  3206.  
  3207. Biological and Sensory: 5
  3208.  
  3209. adr    (search outward for template, put address in AX, template size in DX,
  3210.            and offset in CX, start search at offset +- CX)
  3211. adrb   (search backward for template, put address in AX, template size in DX,
  3212.            and offset in CX, start search at offset - CX)
  3213. adrf   (search forward for template, put address in AX, template size in DX,
  3214.            and offset in CX, start search at offset + CX)
  3215. mal    (allocate amount of space specified in CX, prefer address at AX,
  3216.            if AX < 0 use better fit, place address of allocated block in AX)
  3217. divide (cell division, the IP is offset by CX into the daughter cell, the
  3218.            values in the four CPU registers are transferred from mother to
  3219.            daughter, but not the stack.  If !DX genome will be ejected from
  3220.            the simulator)
  3221.  
  3222. Total: 32 instructions
  3223.  
  3224. The following array defines the associations of opcodes, mnemonics,
  3225. executable functions, and parsing functions (in that order) used to
  3226. implement instruction set #4.
  3227.  
  3228.     {0x00, "nop0", nop, pnop},
  3229.     {0x01, "nop1", nop, pnop},
  3230.     {0x02, "movdi", movdi, pmovdi},
  3231.     {0x03, "movid", movid, pmovid},
  3232.     {0x04, "movii", movii, pmovii},
  3233.     {0x05, "pushax", push, ppushax},
  3234.     {0x06, "pushbx", push, ppushbx},
  3235.     {0x07, "pushcx", push, ppushcx},
  3236.     {0x08, "pushdx", push, ppushdx},
  3237.     {0x09, "popax", pop, ppopax},
  3238.     {0x0a, "popbx", pop, ppopbx},
  3239.     {0x0b, "popcx", pop, ppopcx},
  3240.     {0x0c, "popdx", pop, ppopdx},
  3241.     {0x0d, "put", put, pput},
  3242.     {0x0e, "get", get, pget},
  3243.     {0x0f, "inc", math, pinc},
  3244.     {0x10, "dec", math, pdec},
  3245.     {0x11, "add", math, padd},
  3246.     {0x12, "sub", math, psub},
  3247.     {0x13, "zero", movdd, pzero},
  3248.     {0x14, "shl", shl, pshl},
  3249.     {0x15, "not0", not0, pnot0},
  3250.     {0x16, "ifz", ifz, pifz},
  3251.     {0x17, "iffl", ifz, piffl},
  3252.     {0x18, "jmp", adr, ptjmp},
  3253.     {0x19, "jmpb", adr, ptjmpb},
  3254.     {0x1a, "call", tcall, ptcall},
  3255.     {0x1b, "adr", adr, padr},
  3256.     {0x1c, "adrb", adr, padrb},
  3257.     {0x1d, "adrf", adr, padrf},
  3258.     {0x1e, "mal", malchm, pmal},
  3259.     {0x1f, "divide", divide, pdivide}
  3260.  
  3261. ******************************************************************************
  3262.  
  3263.   8.2) Details of Set 1
  3264.  
  3265.      What follows is a more detailed documentation of instruction set 1:
  3266.  
  3267.      In general, the ax and bx registers are used to hold addresses, which
  3268. refer to locations in the soup.  Values contained in the ax and bx registers
  3269. are maintained as positive integers, modulus SoupSize.  The cx and dx
  3270. registers are generally used to hold numbers, which may be either positive or
  3271. negative.  Values contained in the cx and dx registers are forced to remain
  3272. in the range -SoupSize to SoupSize.  Any operation which causes the values
  3273. in the cx or dx registers to stray out of this range will cause the
  3274. instruction to fail and a flag to be set (in this case, the value in the
  3275. cx or dx register is reset to zero).
  3276.  
  3277.      Many of the instructions will fail under certain conditions, which are
  3278. specified for each instruction in the following discussion.  Any time an
  3279. instruction fails, it does nothing, other than to increment the instruction
  3280. pointer, decrement the instruction bank, and set the flag register (to the
  3281. value 1).  Any time and instruction does not fail, it clears the flag register
  3282. (to the value 0).  All instructions clear the flag on success, and set the
  3283. flag on failure.  Every instruction decrements the instruction bank by one,
  3284. regardless of success or failure.
  3285.  
  3286.      What follows is a list of the thirty-two instructions of INST == 1,
  3287. along with details of their behavior:
  3288.  
  3289. {0x00, "nop0", nop, pnop}, /* do nothing */
  3290. {0x01, "nop1", nop, pnop},
  3291.  
  3292.      These two instructions are no-ops, they do nothing, other than to
  3293. increment the instruction pointer one place.  There are no conditions under
  3294. which these instructions fail.
  3295.  
  3296. {0x02, "not0", not0, pnot0}, /* flip low order bit of cx */
  3297.  
  3298.      This instruction flips the low order bit of the cx register.  The only
  3299. condition under which it fails is if this operation causes the value in
  3300. the register to stray out of the range -SoupSize to SoupSize.  In this
  3301. case cx is set to zero and the flag is set.  In every case, the
  3302. instruction pointer is incremented by one.
  3303.  
  3304. {0x03, "shl", shl, pshl}, /* shift left all register of cx */
  3305.  
  3306.      This instruction shifts all bits of the cx register one position to
  3307. the left, replacing the rightmost (low order) bit with a zero (this is a
  3308. binary multiply by two).  The only condition under which it fails is if this
  3309. operation causes the value in the register to stray out of the range -SoupSize
  3310. to SoupSize.  In this case cx is set to zero and the flag is set.
  3311. In every case, the instruction pointer is incremented by one.
  3312.  
  3313. {0x04, "zero", movdd, pzero}, /* cx = 0 */
  3314.  
  3315.      This instruction sets the cx register to zero.  It also increments the
  3316. instruction pointer one place.  There are no conditions under which this
  3317. instruction fails.
  3318.  
  3319. {0x05, "ifz", ifz, pifz}, /* execute next instruction only if cx == 0 */
  3320.  
  3321.      This instruction will increment the instruction pointer by one if the
  3322. value in the cx register is zero, or by two if the cx register contains
  3323. any other value (this means that the instruction following this one will be
  3324. executed only if the value in the cx register is zero).  There are no
  3325. conditions under which this instruction fails.
  3326.  
  3327. {0x06, "sub_ab", math, psub_ab}, /* cx = ax - bx */
  3328.  
  3329.      This instruction subtracts the value in the bx register from the value
  3330. in the cx register, placing the result in the cx register.  This instruction
  3331. can fail only if the resultant value in the cx register would be outside of
  3332. the range -SoupSize to SoupSize, in which case the value in the cx register
  3333. is set to zero, and a flag is set.  In any case, the instruction pointer
  3334. is incremented by one.
  3335.  
  3336. {0x07, "sub_ac", math, psub_ac}, /* ax = ax - cx */
  3337.  
  3338.      This instruction subtracts the value in the cx register from the value
  3339. in the ax register, placing the result in the ax register.  It increments the
  3340. instruction pointer by one.  There are no conditions under which this
  3341. instruction fails.
  3342.  
  3343. {0x08, "inc_a", math, pinc_a}, /* ax++ */
  3344.  
  3345.      This instruction increments (adds one to) the value in the ax register,
  3346. placing the result in the ax register.  It increments the instruction pointer
  3347. by one.  There are no conditions under which this instruction fails.
  3348.  
  3349. {0x09, "inc_b", math, pinc_b}, /* bx++ */
  3350.  
  3351.      This instruction increments (adds one to) the value in the bx register,
  3352. placing the result in the bx register.  It increments the instruction pointer
  3353. by one.  There are no conditions under which this instruction fails.
  3354.  
  3355. {0x0a, "dec_c", math, pdec_c}, /* cx-- */
  3356.  
  3357.      This instruction decrements (subtracts one from) the value in the cx
  3358. register, placing the result in the cx register.  It increments the
  3359. instruction pointer by one.  This instruction can fail only if the resultant
  3360. value in the cx register would be outside of the range -SoupSize to SoupSize,
  3361. in which case the cx register is set to zero, and a flag is set.
  3362.  
  3363. {0x0b, "inc_c", math, pinc_c}, /* cx++ */
  3364.  
  3365.      This instruction increments (adds one to) the value in the cx register,
  3366. placing the result in the cx register.  It increments the instruction pointer
  3367. by one.  This instruction can fail only if the resultant value in the cx
  3368. register would be outside of the range -SoupSize to SoupSize, in which case
  3369. the cx register is set to zero, and a flag is set.
  3370.  
  3371. {0x0c, "pushax", push, ppushax}, /* push ax onto stack */
  3372.  
  3373.      This instruction causes the value in the ax register to be pushed onto
  3374. the stack, and the stack pointer to be incremented (modulus STACK_SIZE).
  3375. It increments the instruction pointer by one.  There are no conditions under
  3376. which this instruction fails.
  3377.  
  3378. {0x0d, "pushbx", push, ppushbx}, /* push bx onto stack */
  3379.  
  3380.      This instruction causes the value in the bx register to be pushed onto
  3381. the stack, and the stack pointer to be incremented (modulus STACK_SIZE).
  3382. It increments the instruction pointer by one.  There are no conditions under
  3383. which this instruction fails.
  3384.  
  3385. {0x0e, "pushcx", push, ppushcx}, /* push cx onto stack */
  3386.  
  3387.      This instruction causes the value in the cx register to be pushed onto
  3388. the stack, and the stack pointer to be incremented (modulus STACK_SIZE).
  3389. It increments the instruction pointer by one.  There are no conditions under
  3390. which this instruction fails.
  3391.  
  3392. {0x0f, "pushdx", push, ppushdx}, /* push dx onto stack */
  3393.  
  3394.      This instruction causes the value in the dx register to be pushed onto
  3395. the stack, and the stack pointer to be incremented (modulus STACK_SIZE).
  3396. It increments the instruction pointer by one.  There are no conditions under
  3397. which this instruction fails.
  3398.  
  3399. {0x10, "popax", pop, ppopax}, /* pop ax off of stack */
  3400.  
  3401.      This instruction causes the value at the top of the stack to be popped
  3402. into the ax register and the stack pointer to be decremented (modulus
  3403. STACK_SIZE).  It increments the instruction pointer by one.  There are no
  3404. conditions under which this instruction fails.
  3405.  
  3406. {0x11, "popbx", pop, ppopbx}, /* pop bx off of stack */
  3407.  
  3408.      This instruction causes the value at the top of the stack to be popped
  3409. into the bx register and the stack pointer to be decremented (modulus
  3410. STACK_SIZE).  It increments the instruction pointer by one.  There are no
  3411. conditions under which this instruction fails.
  3412.  
  3413. {0x12, "popcx", pop, ppopcx}, /* pop cx off of stack */
  3414.  
  3415.      This instruction causes the value at the top of the stack to be popped
  3416. into the cx register and the stack pointer to be decremented (modulus
  3417. STACK_SIZE).  It increments the instruction pointer by one.  This instruction
  3418. can fail only if the resultant value in the cx register would be outside of
  3419. the range -SoupSize to SoupSize, in which case the cx register is set to zero,
  3420. and a flag is set.
  3421.  
  3422. {0x13, "popdx", pop, ppopdx}, /* pop dx off of stack */
  3423.  
  3424.      This instruction causes the value at the top of the stack to be popped
  3425. into the dx register and the stack pointer to be decremented (modulus
  3426. STACK_SIZE).  It increments the instruction pointer by one.  This instruction
  3427. can fail only if the resultant value in the dx register would be outside of
  3428. the range -SoupSize to SoupSize, in which case the dx register is set to zero,
  3429. and a flag is set.
  3430.  
  3431. {0x14, "jmp", adr, ptjmp}, /* outward template jump */
  3432.  
  3433.      This instruction causes the instruction pointer to be redirected to the
  3434. instruction following the nearest occurrence of the template complementary
  3435. to the template that follows the jmp instruction.  The template is defined
  3436. as the group of consecutive nops (nop0 or nop1) that immediately follow the
  3437. jmp instruction.  The size of the template is just the number of consecutive
  3438. nops that follow the jmp instruction.  The size of the template is placed in
  3439. the dx register.
  3440.  
  3441.      This instruction is a bi-directional jump, which means that it will
  3442. search both forward and backward in memory for the complementary template.
  3443. Let a equal the address of the first instruction of the template, and let
  3444. s equal the size of the template.  The forward search starts at the address
  3445. a + s + 1, and the backward search starts at the address a - s - 1.  The
  3446. search looks in the forward direction first, then alternately looks ahead
  3447. or back one additional step until the complementary template is found, or
  3448. the search limit (Search_limit) is reached.  The template searches wrap around
  3449. the ends of the soup.
  3450.  
  3451.      The instruction will fail if the size of the template following the jmp
  3452. instruction is less than MinTemplSize, or greater than SoupSize, or if a
  3453. complementary template is not found within the search radius, Search_limit.
  3454. On failure, the instruction pointer is moved past the template used by the
  3455. jmp instruction: ce->c.ip = ce->c.ip + s + 1.
  3456.  
  3457. {0x15, "jmpb", adr, ptjmpb}, /* backward template jump */
  3458.  
  3459.      This instruction causes the instruction pointer to be redirected to the
  3460. instruction following the nearest occurrence (backwards in the soup) of the
  3461. template complementary to the template that follows the jmp instruction.  The
  3462. template is defined as the group of consecutive nops (nop0 or nop1) that
  3463. immediately follow the jmp instruction.  The size of the template is just the
  3464. number of consecutive nops that follow the jmp instruction.  The size of the
  3465. template is placed in the dx register.
  3466.  
  3467.      This instruction is a uni-directional jump, which means that it will
  3468. search in only one direction (in this case, only backward) in memory for the
  3469. complementary template.  Let a equal the address of the first instruction of
  3470. the template, and let s equal the size of the template.  The backward search
  3471. starts at the address a - s - 1.  The search looks in successive steps
  3472. backwards until the complementary template is found, or the search limit
  3473. (Search_limit) is reached.  The template searches wrap around the ends of the
  3474. soup.
  3475.  
  3476.      The instruction will fail if the size of the template following the jmp
  3477. instruction is less than MinTemplSize, or greater than SoupSize, or if a
  3478. complementary template is not found within the search radius, Search_limit.
  3479. On failure, the instruction pointer is moved past the template used by the
  3480. jmp instruction: ce->c.ip = ce->c.ip + s + 1.
  3481.  
  3482. {0x16, "call", tcall, ptcall}, /* push ip to stack, outward template jump */
  3483.  
  3484.      This instruction behaves identically to the jmp instruction, with the
  3485. one difference that the address following the tempate following the call
  3486. instruction is also pushed onto the stack (this is essentially the address
  3487. of the instruction pointer plus one meaningful instruction).  On failure, the
  3488. instruction pointer is moved past the template used by the jmp instruction:
  3489. ce->c.ip = ce->c.ip + s + 1, and the ip will not be pushed onto the stack.
  3490. If the call instruction is not followed by a template, it will push the
  3491. address of the instruction pointer + 1 onto the stack.
  3492.  
  3493. {0x17, "ret", pop, pret}, /* pop ip from stack */
  3494.  
  3495.      This instruction causes the value at the top of the stack to be popped
  3496. into the instruction pointer and the stack pointer to be decremented (modulus
  3497. STACK_SIZE).  There are no conditions under which this instruction fails.
  3498.  
  3499. {0x18, "movcd", movdd, pmov_dc}, /* dx = cx */
  3500.  
  3501.      This instruction copies the contents of the cx register into the dx
  3502. register, leaving the value in cx intact.  The flaw may cause the source
  3503. register to actually be bx or dx and the destination register to actually
  3504. be cx or ax.  This instruction could fail if the value placed in the dx
  3505. register would be outside of the range -SoupSize to SoupSize, in which case
  3506. the dx register is set to zero, and a flag is set.
  3507.  
  3508. {0x19, "movab", movdd, pmov_ba}, /* bx = ax */
  3509.  
  3510.      This instruction copies the contents of the ax register into the bx
  3511. register, leaving the value in ax intact.  The flaw may cause the source
  3512. register to actually be bx or dx and the destination register to actually
  3513. be cx or ax.  This instruction could fail if the value placed in the cx
  3514. register would be outside of the range -SoupSize to SoupSize, in which case
  3515. the cx register is set to zero, and a flag is set.
  3516.  
  3517. {0x1a, "movii", movii, pmovii},
  3518.  
  3519.      This instruction copies one instruction in the soup to another location
  3520. in the soup.  The source instruction is at the address contained in the
  3521. bx register, and the destination is the address contained in the ax register.
  3522.  
  3523.      This instruction could fail under the following circumstances:  a) if the
  3524. source and destination addresses are the same, b) if the destination address
  3525. is not owned by this creature and is write protected, c) if the source
  3526. address is not owned by this creature and is read protected, d) if either the
  3527. source or destination addresses are outside the soup.
  3528.  
  3529.      Also, if the destination address is in the daughter, it will perform the
  3530. following operation: ce->d.mov_daught++.  If the destination address is not
  3531. in the daughter cell, it will make a call to MutBookeep(is.dval), since this
  3532. could concievably make a genetic change in another creature (if the other
  3533. creature were not write protected, or if the ``other'' creature were actually
  3534. the one doing the writing).
  3535.  
  3536. {0x1b, "adr", adr, padr}, /* search outward for template, return adr in ax */
  3537.  
  3538.      This instruction causes the ax register to contain the address of the
  3539. instruction following the nearest occurrence of the template complementary
  3540. to the template that follows the adr instruction.  The template is defined
  3541. as the group of consecutive nops (nop0 or nop1) that immediately follow the
  3542. adr instruction.  The size of the template is just the number of consecutive
  3543. nops that follow the adr instruction.  The size of the template is placed in
  3544. the cx register.
  3545.  
  3546.      This instruction is a bi-directional search, which means that it will
  3547. search both forward and backward in memory for the complementary template.
  3548. Let a equal the address of the first instruction of the template, and let
  3549. s equal the size of the template.  The forward search starts at the address
  3550. a + s + 1, and the backward search starts at the address a - s - 1.  The
  3551. search looks in the forward direction first, then alternately looks ahead
  3552. or back one additional step until the complementary template is found, or
  3553. the search limit (Search_limit) is reached.  The template searches wrap around
  3554. the ends of the soup.  The instruction pointer is moved past the template used
  3555. by the adr instruction: ce->c.ip = ce->c.ip + s + 1.
  3556.  
  3557.      The instruction will fail if the size of the template following the adr
  3558. instruction is less than MinTemplSize, or greater than SoupSize, or if a
  3559. complementary template is not found within the search radius, Search_limit.
  3560. On failure and the cx register is not altered.
  3561.  
  3562. {0x1c, "adrb", adr, padrb}, /* search backward for template, rtrn adr in ax */
  3563.  
  3564.      This instruction causes the ax register to contain the address of the
  3565. instruction following the nearest occurrence (backwards in the soup) of the
  3566. template complementary to the template that follows the adrb instruction.
  3567. The template is defined as the group of consecutive nops (nop0 or nop1) that
  3568. immediately follow the adrb instruction.  The size of the template is just the
  3569. number of consecutive nops that follow the adrb instruction.  The size of the
  3570. template is placed in the cx register.
  3571.  
  3572.      This instruction is a uni-directional search, which means that it will
  3573. search in only one direction (in this case, only backward) in memory for the
  3574. complementary template.  Let a equal the address of the first instruction of
  3575. the template, and let s equal the size of the template.  The backward search
  3576. starts at the address a - s - 1.  The search looks in successive steps
  3577. backwards until the complementary template is found, or the search limit
  3578. (Search_limit) is reached.  The template searches wrap around the ends of the
  3579. soup.  The instruction pointer is moved past the template used by the adrb
  3580. instruction: ce->c.ip = ce->c.ip + s + 1.
  3581.  
  3582.      The instruction will fail if the size of the template following the adrb
  3583. instruction is less than MinTemplSize, or greater than SoupSize, or if a
  3584. complementary template is not found within the search radius, Search_limit.
  3585. On failure the cx register is not altered.
  3586.  
  3587. {0x1d, "adrf", adr, padrf}, /* search forward for template, rtrn adr in ax */
  3588.  
  3589.      This instruction causes the ax register to contain the address of the
  3590. instruction following the nearest occurrence (forwards in the soup) of the
  3591. template complementary to the template that follows the adrf instruction.
  3592. The template is defined as the group of consecutive nops (nop0 or nop1) that
  3593. immediately follow the adrf instruction.  The size of the template is just the
  3594. number of consecutive nops that follow the adrf instruction.  The size of the
  3595. template is placed in the cx register.
  3596.  
  3597.      This instruction is a uni-directional search, which means that it will
  3598. search in only one direction (in this case, only forward) in memory for the
  3599. complementary template.  Let a equal the address of the first instruction of
  3600. the template, and let s equal the size of the template.  The forward search
  3601. starts at the address a + s + 1.  The search looks in successive steps
  3602. forwards until the complementary template is found, or the search limit
  3603. (Search_limit) is reached.  The template searches wrap around the ends of the
  3604. soup.  The instruction pointer is moved past the template used by the adrf
  3605. instruction: ce->c.ip = ce->c.ip + s + 1.
  3606.  
  3607.      The instruction will fail if the size of the template following the adrf
  3608. instruction is less than MinTemplSize, or greater than SoupSize, or if a
  3609. complementary template is not found within the search radius, Search_limit.
  3610. On failure the cx register is not altered.
  3611.  
  3612. {0x1e, "mal", malchm, pmal}, /* allocate & chmod space for a new cell */
  3613.  
  3614.      This instruction requests memory space in the soup from the operating
  3615. system.  The amount of space requested is specified by the value in the cx
  3616. register.  The address of the allocated block is returned in the ax register.
  3617. The allocated block is chmoded (its memory is protected) according to the
  3618. condition specified by the soup_in variable MemModeProt, which has a default
  3619. value of 2 (write privelage protected, but read and execute privelages open).
  3620. In any case the owner of the space retains all privelages.  This instruction
  3621. will increment the instruction pointer by one.  If this instruction is
  3622. executed successfully, this creature will move down the reaper queue one
  3623. position.
  3624.  
  3625.      The operating system searches for a block of free memory of the size
  3626. requested, and will invoke the reaper if such a block is not available.
  3627. The block of memory may be located on a first fit basis by beginning the
  3628. search at the beginning of memory, or using a better fit method, or the
  3629. block may be located at a preferred location to within a tolerance (see
  3630. the MalMode, MalReapTol, and MalTol variables described in the section on
  3631. SOUP_IN PARAMETERS).  Note that the execution of this instruction usually
  3632. causes the reaper to kill in order to free space to meet the request.
  3633. However, the reaper will never kill the creature making the request.
  3634. The allocated block may not wrap around the end of the soup.
  3635.  
  3636.      This instruction can fail under the following circumstances: a) if the
  3637. amount of memory requested is less than or equal to zero (note that a request
  3638. of 1 may be converted into a request of 0 by a flaw), b) if the creature
  3639. already owns a second block of memory whose size is exactly the amount of
  3640. memory requested (in other words, if the creature makes two successive calls
  3641. to mal(), requesting the same amount of memory, without an intervening call
  3642. to divide()), c) if the amount of memory requested is more than MaxMalMult
  3643. times the size of the creature making the request (the default value of
  3644. MaxMalMult is 3).
  3645.  
  3646. {0x1f, "divide", divide, pdivide} /* give life to new cell, put in queues */
  3647.  
  3648.      This instruction causes the mother cell to loose her write privelages
  3649. on the space of the daughter cell, and causes the daughter cell to be
  3650. entered into both the reaper and slicer queues.  The daughter enters the
  3651. bottom of the reaper queue, and enters the slicer queue just behind the mother
  3652. (so the daughter will be the last cell to be reaped and to get another slice).
  3653. This instruction will increment the instruction pointer by one.  If this
  3654. instruction is executed successfully, this creature will move down the reaper
  3655. queue one position.
  3656.  
  3657.      This instruction can fail under the following circumstances: a) if the
  3658. size of the daughter cell is less than soup_in variable MinCellSize (default
  3659. value of 8), b) if the number of instructions written into the space of the
  3660. daughter cell by the mother cell (ce->d.mov_daught) is less than the soup_in
  3661. variable MovPropThrDiv times the size of the daughter cell, c) if the soup_in
  3662. variable DivSameSize is non-zero, and the daughter cell is not the same
  3663. size as the mother cell, d) if the soup_in variable DivSameGen is non-zero
  3664. and the daughter cell is not the same size, or does not have exactly the same
  3665. sequence as the mother cell.
  3666.  
  3667.   8.3) New Features in Sets 2 through 4
  3668.  
  3669.      Instruction sets two through four are essentially identical except for
  3670. the methods used to move data between the registers of the cpu.  Set two
  3671. allows the order of the registers to be freely rearranged, and provides
  3672. an instruction, movdd() to move data directly between two registers.  Set
  3673. three uses the reverse Polish notation method, in which the registers can
  3674. be rolled up or down, and the values in the lower two registers can be
  3675. exchanged.  Set four requires all inter-register moves to pass through the
  3676. stack.
  3677.  
  3678.      Each of the new sets includes a movdi() instruction to move data from
  3679. a register into the soup, and a movid instruction to move data from the soup
  3680. into a register.
  3681.  
  3682.      Each new set provides I/O functions in the form of put() and get()
  3683. instructions which write to or read from buffers.  The get() instruction
  3684. reads a value from the input buffer and moves it into a cpu register.  The
  3685. input buffer maintains a pointer to the next input value to be read from the
  3686. buffer, a pointer to the next input value to be written to the buffer,
  3687. and a count of unread input values:
  3688.  
  3689.  ce->c.gb[GETBUFSIZ]     == pointer to next input value to be read
  3690.  ce->c.gb[GETBUFSIZ + 1] == pointer to next input value to be written
  3691.  ce->c.gb[GETBUFSIZ + 2] == number of unread input values
  3692.  
  3693.      The output buffer maintains a pointer to the next output value to be
  3694. written to the buffer, a pointer to the next output value to be read from the
  3695. buffer, and a count of unread output values:
  3696.  
  3697.  ce->c.pb[PUTBUFSIZ]     == pointer to next output value to be written
  3698.  ce->c.pb[PUTBUFSIZ + 1] == pointer to next output value to be read
  3699.  ce->c.pb[PUTBUFSIZ + 2] == number of unread output values
  3700.  
  3701.      The put() instruction operates in two modes.  If ICC is defined
  3702. (inter-cellular communication), put() writes to the input buffer(s) of other
  3703. cell(s).  In this case, if the put() instruction is followed by a template,
  3704. put() will write to the input buffer(s) of any cells within the put radius,
  3705. PutLimit, which have a get instruction followed by a complementary template
  3706. (this is an analog to hormonal communication).  If put() is not followed by
  3707. a template, then it writes to the input buffer of the cell located at the
  3708. address specified in the relevant register of the cell executing the put().
  3709.  
  3710.      If ICC is not defined, put() writes to its own output buffer.  This
  3711. mode is provided so that the user can communicate with the cells.  This could
  3712. be used for example to get them to do useful work by giving them data by
  3713. writing to their input buffer, letting them get the data and compute on it,
  3714. then letting them write their results back to you in the output buffer (the
  3715. creatures can also use this facility to pray).  In order to assist with
  3716. communication between the user and the creatures, three additional functions
  3717. are provided in the instruct.c module:
  3718.  
  3719. I8s ReadFPut(ce, value)   /* for god to read the data in the output buffer */
  3720. void Write2Get(ce, value) /* place value in input buffer of cell ce */
  3721. void Broad2Get(value)     /* broadcast value to input buffer of all cells */
  3722.  
  3723.      Each new instruction set includes the basic calculations: inc(), dec(),
  3724. add() and sub().  The zero() instruction sets a register to zero.  The not0()
  3725. instruction flips the low order bit of a register, and the not() instruction
  3726. flips all bits of a register.  The shl() instruction shifts all bits of a
  3727. register one bit to the left, placing a zero in the low order bit (multiply
  3728. by two).  Set three also provides rand() which places a random number in
  3729. the AX register.
  3730.  
  3731.      In addition to ifz() which tests if a register is zero, the new sets
  3732. provide iffl() which tests it a flag is set.  This latter can be used to
  3733. test in an instruction has failed.
  3734.  
  3735.      In sets two through four, the jmp() and jmpb() instructions will
  3736. jump to a complementary template, if the jump instruction is followed by
  3737. a template, but if there is no template, they will jump to the address
  3738. specified in a register.  Similarly, the call instruction will push the
  3739. instruction pointer + 1 onto the stack, and if a template is present, will
  3740. jump to the nearest complementary template.
  3741.  
  3742.      In sets two through four, the address instructions adr(), adrb() and
  3743. adrf() have two new features:  1) they return the offset distance from the
  3744. source template to where they found the target template.  2) they start the
  3745. search at an offset from the source template, specified in a register.  This
  3746. provides the facility to repeatedly call the address instructions in order
  3747. to find target templates beyond the first matching one.
  3748.  
  3749.      In sets two through four, the mal() instruction has the option of
  3750. specifying the preferred address in a register, or of using a better fit
  3751. mode.
  3752.  
  3753.      In sets two through four, the divide instruction causes the contents
  3754. of the mother's cpu registers to be transferred to the daughter's cpu
  3755. registers.  Also, the instruction pointer of the daughter will start with
  3756. an offset into the daughter cell that is specified in a register of the
  3757. mother's cpu.  This allows the mother to force the daughter to express
  3758. a different sub-set of the genome from that which was expressed by the
  3759. mother (the mother can force the daughter cell to differentiate).  If a
  3760. certain register of the mother is not zero, the genome of the daughter cell
  3761. will be ejected from the soup.  This makes it possible for the daughter cell
  3762. to emmigrate to another soup, if there is one.  When ejected from the soup,
  3763. the space occupied by the daughter cell is freed, and the code is set to
  3764. zero in that space.
  3765.  
  3766. 9)  THE ANCESTOR & WRITING A CREATURE
  3767.  
  3768.   9.1) The Ancestor
  3769.  
  3770.      The ASCII assembler code file with comments, for the ancestor, is listed
  3771. below.  Below the listing I have some explanatory material.
  3772.  
  3773. **** begin genome file (note blank line at head of file)
  3774.  
  3775. format: 2  bits: 2156009669  EXsh    TCsh    TPs     MFs     MTd     MBh     
  3776. genotype: 0080aaa  parent genotype: 0666god
  3777. 1st_daughter:  flags: 0  inst: 827  mov_daught: 80          breed_true: 1
  3778. 2nd_daughter:  flags: 0  inst: 809  mov_daught: 80          breed_true: 1
  3779. Origin: InstExe: 0,0  clock: 0  Thu Jan 01 -5:00:00 1970
  3780. MaxPropPop: 0.8306  MaxPropInst: 0.4239 mpp_time: 0,0 
  3781. ploidy: 1  track: 0
  3782.  
  3783. track 0: prot
  3784.           xwr
  3785. nop1    ; 010 110 01   0 beginning marker
  3786. nop1    ; 010 110 01   1 beginning marker
  3787. nop1    ; 010 110 01   2 beginning marker
  3788. nop1    ; 010 110 01   3 beginning marker
  3789. zero    ; 010 110 04   4 put zero in cx
  3790. not0    ; 010 110 02   5 put 1 in first bit of cx
  3791. shl     ; 010 110 03   6 shift left cx (cx = 2)
  3792. shl     ; 010 110 03   7 shift left cx (cx = 4)
  3793. movcd   ; 010 110 18   8 move cx to dx (dx = 4)
  3794. adrb    ; 010 110 1c   9 get (backward) address of beginning marker -> ax
  3795. nop0    ; 010 100 00  10 complement to beginning marker
  3796. nop0    ; 010 100 00  11 complement to beginning marker
  3797. nop0    ; 010 100 00  12 complement to beginning marker
  3798. nop0    ; 010 100 00  13 complement to beginning marker
  3799. sub_ac  ; 010 110 07  14 subtract cx from ax, result in ax
  3800. movab   ; 010 110 19  15 move ax to bx, bx now contains start address of mother
  3801. adrf    ; 010 110 1d  16 get (forward) address of end marker -> ax
  3802. nop0    ; 010 100 00  17 complement to end marker
  3803. nop0    ; 010 100 00  18 complement to end marker
  3804. nop0    ; 010 100 00  19 complement to end marker
  3805. nop1    ; 010 100 01  20 complement to end marker
  3806. inc_a   ; 010 110 08  21 increment ax, to include dummy instruction at end
  3807. sub_ab  ; 010 110 06  22 subtract bx from ax to get size, result in cx
  3808. nop1    ; 010 110 01  23 reproduction loop marker
  3809. nop1    ; 010 110 01  24 reproduction loop marker
  3810. nop0    ; 010 110 00  25 reproduction loop marker
  3811. nop1    ; 010 110 01  26 reproduction loop marker
  3812. mal     ; 010 110 1e  27 allocate space (cx) for daughter, address to ax
  3813. call    ; 010 110 16  28 call template below (copy procedure)
  3814. nop0    ; 010 100 00  29 copy procedure complement
  3815. nop0    ; 010 100 00  30 copy procedure complement
  3816. nop1    ; 010 100 01  31 copy procedure complement
  3817. nop1    ; 010 100 01  32 copy procedure complement
  3818. divide  ; 010 110 1f  33 create independent daughter cell
  3819. jmp     ; 010 110 14  34 jump to template below (reproduction loop)
  3820. nop0    ; 010 100 00  35 reproduction loop complement
  3821. nop0    ; 010 100 00  36 reproduction loop complement
  3822. nop1    ; 010 100 01  37 reproduction loop complement
  3823. nop0    ; 010 100 00  38 reproduction loop complement
  3824. ifz     ; 010 000 05  39 dummy instruction to separate templates
  3825. nop1    ; 010 110 01  40 copy procedure template
  3826. nop1    ; 010 110 01  41 copy procedure template
  3827. nop0    ; 010 110 00  42 copy procedure template
  3828. nop0    ; 010 110 00  43 copy procedure template
  3829. pushax  ; 010 110 0c  44 push ax onto stack
  3830. pushbx  ; 010 110 0d  45 push bx onto stack
  3831. pushcx  ; 010 110 0e  46 push cx onto stack
  3832. nop1    ; 010 110 01  47 copy loop template
  3833. nop0    ; 010 110 00  48 copy loop template
  3834. nop1    ; 010 110 01  49 copy loop template
  3835. nop0    ; 010 110 00  50 copy loop template
  3836. moviab  ; 010 110 1a  51 move contents of [bx] to [ax] (copy one instruction)
  3837. dec_c   ; 010 110 0a  52 decrement cx (size)
  3838. ifz     ; 010 110 05  53 if cx == 0 perform next instruction, otherwise skip it
  3839. jmp     ; 010 110 14  54 jump to template below (copy procedure exit)
  3840. nop0    ; 010 110 00  55 copy procedure exit complement
  3841. nop1    ; 010 110 01  56 copy procedure exit complement
  3842. nop0    ; 010 110 00  57 copy procedure exit complement
  3843. nop0    ; 010 110 00  58 copy procedure exit complement
  3844. inc_a   ; 010 110 08  59 increment ax (address in daughter to copy to)
  3845. inc_b   ; 010 110 09  60 increment bx (address in mother to copy from)
  3846. jmp     ; 010 110 14  61 bidirectional jump to template below (copy loop)
  3847. nop0    ; 010 100 00  62 copy loop complement
  3848. nop1    ; 010 100 01  63 copy loop complement
  3849. nop0    ; 010 100 00  64 copy loop complement
  3850. nop1    ; 010 100 01  65 copy loop complement
  3851. ifz     ; 010 000 05  66 this is a dummy instruction to separate templates
  3852. nop1    ; 010 110 01  67 copy procedure exit template
  3853. nop0    ; 010 110 00  68 copy procedure exit template
  3854. nop1    ; 010 110 01  69 copy procedure exit template
  3855. nop1    ; 010 110 01  70 copy procedure exit template
  3856. popcx   ; 010 110 12  71 pop cx off stack (size)
  3857. popbx   ; 010 110 11  72 pop bx off stack (start address of mother)
  3858. popax   ; 010 110 10  73 pop ax off stack (start address of daughter)
  3859. ret     ; 010 110 17  74 return from copy procedure
  3860. nop1    ; 010 100 01  75 end template
  3861. nop1    ; 010 100 01  76 end template
  3862. nop1    ; 010 100 01  77 end template
  3863. nop0    ; 010 100 00  78 end template
  3864. ifz     ; 010 000 05  79 dummy instruction to separate creature
  3865. **** end genome file
  3866.  
  3867.      Each genome file begins with some header information.  Let me explain
  3868. each item:
  3869.  
  3870.      format: 2  because we occasionally change the format of the genome files,
  3871. this parameter is included for backwards compatibility.  It is used by the
  3872. assembler/disassembler to know how to read and write the files.  This variable
  3873. is now defunct.
  3874.  
  3875.      bits: 2156009669 this is the bit field associated with each genome in
  3876. the genebank.  If the genebanker is on and if any of the parameters: WatchExe,
  3877. WatchMov, or WatchTem are set to a non-zero value, then bits in this field
  3878. will be set to characterize the ecological characteristics of the genotype.
  3879. The definitions of the bits in the field are given in the tierra.h module,
  3880. and above in the description of the soup_in parameters.  For more specific
  3881. details, follow the Watch variables in the source modules to see exactly what
  3882. they are doing.
  3883.  
  3884.      EXsh TCsh TPs MFs MTd MBh this is an ASCII summary of the meaning of
  3885. the bits that are set in the bit field.  The meanings of these abbreviations
  3886. are given in the tierra.h file and above in the description of the soup_in
  3887. parameters.
  3888.  
  3889.      genotype: 0080aaa  This is the name of this genotype.  The name has two
  3890. parts.  The first part is numeric and must be equal to the size of the cell
  3891. of this creature (the size of its allocated block of memory).  The cell size
  3892. usually, but not always, corresponds to the size of the genome.  The second
  3893. part is a unique (and arbitrary) three letter code to distinguish this
  3894. particular genotype from others of the same size.
  3895.  
  3896.      parent genotype: 0666god  This is the name of the genotype of the
  3897. immediate ancestor of this genotype.  The immediate ancestor is the creature,
  3898. whose cpu gave rise to the first individual of this genotype.  The original
  3899. creature, 0080aaa was created by god and the devil.  This information is
  3900. deficient in three respects.  First, the creature whose cpu created the
  3901. offspring is not necessarily the genetic parent of the creature.
  3902. Hyper-parasites for example, force other creatures to replicate their genomes.
  3903. Second, the immediate ancestor of a creature may have gone extinct before it
  3904. crossed the threshold, so its genotype may not appear in the genebank.
  3905. Third, in the case where the immediate ancestor went extinct without being
  3906. saved in the genebank, its name becomes available for reuse.  This means
  3907. that even if you find another creature with the right name in the genebank,
  3908. there is no certainty that it is actually the ancestor you are looking for.
  3909. In short, this information is essentially useless.  This is the problem
  3910. that is most actively being worked on at the moment.  A seamless phylogeny
  3911. tracker is under development.
  3912.  
  3913.      1st_daughter:  flags: 0  inst: 827  mov_daught: 80  breed_true: 1
  3914. This is a set of metabolic data about what transpired during the production
  3915. of the first daughter by this genotype.  flags: 0  This tells us how many
  3916. errors (flags) were generated during the first reproduction.  The generation
  3917. of errors indicates invalid execution of instructions and causes the creature
  3918. to move up the reaper queue, closer to death.  inst: 827 This tells us how
  3919. many instructions were executed during the first reproduction, this is an
  3920. indication of metabolic costs and efficiency.  mov_daught: 80  This tells us
  3921. how many instructions were copied from the mother to the daughter during the
  3922. first reproduction.  breed_true: 1  This tells us if the first daughter ever
  3923. has the same genotype as the mother.
  3924.  
  3925.      2nd_daughter:  flags: 0  inst: 809  mov_daught: 80  breed_true: 1
  3926. This is a set of metabolic data about what transpired during the production
  3927. of the second daughter by this genotype.  The data are the same as those
  3928. from the first daughter.  The second daughter and those that follow generally
  3929. have the same metabolic data, but they also generally differ from the first
  3930. daughter, because the second time through, the parent often does not examine
  3931. itself again, and it does not start the algorithm from the same place.
  3932.  
  3933.      Origin InstExe: 0,0  clock: 0  Thu Jan 01 -5:00:00 1970
  3934.      InstExe: 0,0  At the time this genotype first appeared, the system had
  3935. executed this many of instructions.  The number to the left of the comma
  3936. is the number of millions of instructions, and the number to the right of the
  3937. comma is the remainder.  clock: 0  This is the system clock time at the first
  3938. origin of this genotype.  Wed Dec 26 22:56:08 1990  This is the system clock
  3939. time at the first origin of this genotype.
  3940.  
  3941.      MaxPropPop: 0.8306  MaxPropInst: 0.4239 mpp_time: 0,0 
  3942.      MaxPropPop: 0.8306  The maximum proportion of the population of adult
  3943. cells in the soup, attained by this genotype.  MaxPropInst: 0.4239  The
  3944. maximum proportion of space in the soup attained by adults of this genotype.
  3945. mpp_time: 0,0  The time at which this genotype achived its maximum proportion
  3946. of the population of cells (MaxPropPop).  Time here is measured in millions
  3947. of instructions (to the left of the comma) and the remainder (to the right
  3948. of the comma).
  3949.  
  3950.      ploidy: 1  track: 0
  3951.      ploidy: 1  The ploidy level of this genotype (i.e., this genotype
  3952. is haploid).  track: 0  Which copy of the genome will start executing at
  3953. birth.  This is only used when the ploidy level is greater than one
  3954. (i.e., diploid).
  3955.  
  3956. track 0: prot
  3957.           xwr
  3958. nop1   ; 010 110 01   0 beginning marker
  3959.  
  3960.      track 0: prot  This tells us that the assembler code that follows is
  3961. track one.  If the genotype has a ploidy of 2, a second assembler listing
  3962. will follow, and it will be labeled track 1.  The word prot refers to the
  3963. protection bits: xwr, or x = execute, w = write, r = read.
  3964.  
  3965. nop1   ; 010 110 01   0 beginning marker
  3966.  
  3967.      This is the first line of the actual genome.  The first word, nop1 is
  3968. the assembler mnemonic for one of the two no-operation instructions.  The
  3969. semicolon indicates the beginning of comments.
  3970.  
  3971.      The digits 010 tell us what protection this instruction will have at
  3972. birth.  Only the write bit is set, so this instruction will be write
  3973. protected, but open to reading or execution at birth.
  3974.  
  3975.      The digits 110 are a record of which instructions were executed by this
  3976. creature's own CPU (first digit), and the CPUs of other creatures' (second
  3977. digit), the third digit is not used at present.  These bits are set when the
  3978. WatchExe parameter is set.  That the first two digits are set to one indicates
  3979. that this instruction was executed both by its own CPU and by the CPU of
  3980. another creature (perhaps a parasite, or a lost instruction pointer).
  3981.  
  3982.      The digits 01 are the actual hexadecimal op code of the instruction.  It
  3983. is this value that will actually be stored in the soup.
  3984.  
  3985.      The digit 0 just before the words ``beginning marker'' is a count of
  3986. the Nth instruction in the genome.  This is the first instruction, so it is
  3987. numbered zero.
  3988.  
  3989.      The words ``beginning marker'' are a comment describing the intended
  3990. purpose of this instruction.
  3991.  
  3992.      If you study the code of the ancestor, you may be perplexed by the
  3993. reason for including the following instructions:
  3994.  
  3995. zero    ; 010 110 04   4 put zero in cx
  3996. not0    ; 010 110 02   5 put 1 in first bit of cx
  3997. shl     ; 010 110 03   6 shift left cx (cx = 2)
  3998. shl     ; 010 110 03   7 shift left cx (cx = 4)
  3999. mov_cd  ; 010 110 18   8 move cx to dx (dx = 4)
  4000.  
  4001.      In the original version of the simulator, the size of the templates
  4002. was determine by the value in the dx register.  These five instructions
  4003. loaded the dx register with the value 4, which is the size of the templates
  4004. in this creature.  Later, it was decided that this was a stupid way to
  4005. determine template sizes.  Now the parser just looks to see how many nops
  4006. follow any instruction using them, and the number of consecutive nops
  4007. determine the template size.  Therefore, these five instructions don't do any
  4008. useful work in the present model, but they have been left in place because
  4009. the code still works.
  4010.  
  4011.   9.2) Writing a Creature
  4012.  
  4013.      If you write your own creature, you must obey the following conventions:
  4014.  
  4015. **** begin genome file (note blank line at top of file)
  4016.  
  4017. format: 2  bits: 3
  4018. genotype: 0080aaa  parent genotype: 0666god
  4019.  
  4020. track 0: prot
  4021.           xwr
  4022. nop1    ; 010
  4023. nop1    ; 010
  4024. **** end genome file
  4025.  
  4026.      Yank the above lines into the file you are going to write, to use as
  4027. a template.  You must have the following:
  4028.  
  4029.      1) a blank line at the top of the file.
  4030.      2) a line declaring the format and bits, just use the line given.
  4031.      3) a line stating the genome size and three letter name, and that of
  4032.         the parent genotype.  The genome size must match the actual number
  4033.         of instructions in the genome.  The three letter name is arbitrary,
  4034.         you can make up any name, but I advise using a low letter name like
  4035.         aaa because these names are used in a base 26 numbering system by
  4036.         the genebanker, and the genebanker must allocate an array as big
  4037.         as the largest of these numbers.  You may make up the parent genotype
  4038.         size and name, it won't be used for anything, so its details don't
  4039.         matter, but it should have the format of four numeric digits followed
  4040.         by three letters.
  4041.      4) a blank line
  4042.      5) the line: track 0: prot, just use the line provided
  4043.      6) the line:           xwr, just use the line provided
  4044.      7) the listing of assembler mnemonics, followed by a semicolon and a
  4045.         three digit code indicating the protection at birth.  I recomment that
  4046.         you use the protection indicated.  The listing of the 32 assembler
  4047.         mnemonics can be found at the end of the soup_in.h file or in the
  4048.         opcode.map file.  For a description of what they actually do, study
  4049.         the comments on the code of the ancestor listed above, and study the
  4050.         corresponding parser and execute functions in the two modules in
  4051.         parse.c and instruct.c.
  4052.  
  4053. 10)  IF YOU WANT TO MODIFY THE SOURCE CODE
  4054.  
  4055.      If you make some significant improvements to Tierra, we would welcome
  4056. receiving the source code, so that we may integrate it into our version, and
  4057. then make it available to others.  We will credit you for your contributions.
  4058.  
  4059.      All lines of source code should be 78 characters or less, or it will
  4060. mess up the formatting of the code for distribution by mail.
  4061.  
  4062.      The simulator has been designed so that it can be brought down, and then
  4063. brought back up where it left off.  This means that there can be no static
  4064. local variables.  Any variables that hang around must be global.  They
  4065. are declared and defined in soup_in.h if they are also soup_in parameters.
  4066. Otherwise they are declared in declare.h, and all global variables are
  4067. declared as externals in extern.h.
  4068.  
  4069.      The code for bringing the simulator up and down is in the tsetup.c
  4070. module.  The system is brought up by GetSoup(), which calls GetAVar()
  4071. to read soup_in.  All soup_in variables are read by the GetAVar() function.
  4072. If a new simulation is being started, GetSoup() calls GetNewSoup().  If an
  4073. old simulation is being restarted, GetSoup() calls GetOldSoup().  GetOldSoup()
  4074. will read all global variables not contained in soup_in, and will also read
  4075. in all arrays, such as the soup, the cells array, and the free_mem array.
  4076. When the simulator goes down, and periodically during a run, all global
  4077. variables are written to a file soup_out, and all global arrays such as
  4078. soup, the cells array, the free_mem array, and the random number generator
  4079. array, and some structures, are written to a binary file called core_out.
  4080. Thus if you create any new global variables or arrays, be sure they are read
  4081. by GetOldSoup(), and written by WriteSoup().
  4082.  
  4083.      There are several obvious projects that I would like to comment on:
  4084.  
  4085.   10.1) Creating a Frontend
  4086.  
  4087.      All I/O to the console is routed through the frontend.c module, so that
  4088. it can be handled by a variety of frontends now under development.  The
  4089. simplest of these just uses printf to write to standard out.  If you
  4090. compile with #define FRONTEND BASIC, you will get the new frontend created
  4091. by Dan Pirone.  The Basic frontend consists of five data area:
  4092. The STATS area at the top two lines of the screen.
  4093. The PLAN area next for displaying simlation variable every million virtual
  4094.     instruction.
  4095. The MESSAGE area, for state changes, and Genebank data.
  4096. The ERROR area at the second to the last line of the screen.
  4097. The HELP area at the last line of the screen.
  4098.  
  4099. If your are going to work on the frontend, please observe the Basic code
  4100. as a template for changes, or get back to us for an updated version of 
  4101. the frontend.c module.  
  4102.  
  4103.   10.2) Creating New Instruction Sets
  4104.  
  4105.      If you want to create a new instruction set, more power to you.  The
  4106. relevant modules to study are: instruct.c, parse.c, soup_in.h, arginst.h,
  4107. configur.h, and opcode.map.  You will also need to study the definitions of
  4108. struct cpu, struct InstDef, and struct inst, all in the tierra.h module.
  4109. Note that the cpu structure includes an array of registers.  The idea is that
  4110. you may change the size of this array to make just about any changes you might
  4111. want to the CPU architecture.  You should avoid actually having to alter the
  4112. structure definitions in the tierra.h file.  You may alter the correspondence
  4113. between opcodes and instructions by editing the opcode.map file.
  4114.  
  4115.   10.3) Creating New Slicer Mechanisms
  4116.  
  4117.      If you want to experiment with artificial rather than natural selection,
  4118. consider that selection is both a carrot and a stick.  The carrot in this
  4119. model is CPU time which is allocated by the slicers.  The stick is the reaper.
  4120. If you want to try to evolve algorithms that do useful work, your evaluation
  4121. functions should be embedded into the slicer, and should allocate more CPU
  4122. time to creatures who rank high.  You can also do the same with the reaper.
  4123.  
  4124.   10.4) Creating a Sexual Model
  4125.  
  4126.      Sex emerges spontaneously in runs whenever parasites appear.  However,
  4127. this sex is primitive and disorganized.  I believe that the easiest way to
  4128. engineer organized sex is to work with diploid creatures.  The infrastructure
  4129. to allow multiple ploidy levels is already in place.  Notice that the
  4130. definition of Instruction, the type of which the soup is composed is:
  4131.  
  4132. typedef struct Inst  Instruction[PLOIDY];
  4133.  
  4134.      This means that if PLOIDY is defined as two, there are two parallel
  4135. tracks for genomes.  The instruction pointer will run down the track
  4136. specified by the ce->c.tr variable in the cpu structure.  We have not
  4137. implemented any other controls over the tracking of the instruction pointer
  4138. in diploid or higher models.  This is future work.
  4139.  
  4140.   10.5) Creating a Multi-cellular Model
  4141.  
  4142.      Multi-cellularity was the hallmark of the Cambrian explosion of
  4143. diversity, and thus is likely a biological feature worth including in Tierra.
  4144. Also, it is likely that a multi-cellular model is the appropriate one for
  4145. evolving large application programs on massively parallel machines.  How
  4146. can we implement multi-cellularity?  What does it mean in the context of
  4147. Tierran creatures?
  4148.  
  4149.      Consider that at the conceptual core, multi-cellularity means that the
  4150. mother cell determines what portion of the genome its daughter cell will
  4151. express.  For many daughter cells, the mother cells narrows their options
  4152. by preventing them from expressing (executing) large portions of their
  4153. genome (code).  In the organic world this is done by loading the daughter
  4154. cell with regulatory proteins which determine which genes will be expressed.
  4155.  
  4156.      In the Tierran world, the same result can be achieved by allowing the
  4157. mother cell to set the position of the instruction pointer in the daughter
  4158. cell, and also the initial values of the CPU registers.  These acts can
  4159. place the daughter cell into a portion of its code from which it may never
  4160. be able to reach certain other parts of its code.  In this way the mother
  4161. cell determines what parts of the code are executed by the daughter.
  4162.  
  4163.      To facilitate this process, the divide instruction has been broken into
  4164. three steps: 1) Create and initialize a CPU for the daughter.  2) Start the
  4165. daughter CPU running.  3) Become independent from the daughter by loosing
  4166. write privelages on the daughter space.  Now, between steps 1 and 2, the
  4167. mother can place values into the CPU registers and instruction pointer of
  4168. the daughter.  This will require and inter-CPU move instruction.  The divide
  4169. instruction takes an argument that determines which of the three steps is
  4170. being performed.  The divide instruction in the new instruction sets does
  4171. all three steps at once, but it also transfers the value from the mother's
  4172. cpu registers to the daughter's cpu registers, and it starts the daughter's
  4173. instruction pointer at some offset into the daughter's genome, as specified
  4174. by a value in one of the mothers cpu registers (this can cause
  4175. differentiation).
  4176.  
  4177. 11) CONFIGURATION AT COMPILE TIME (configur.h)
  4178.  
  4179.      The file configur.h is included by the file tierra.h, and thus is
  4180. included in all tierra source code modules.  Many definitions are made in
  4181. this file that control options that require recompilation to change.  The
  4182. number of these options has been growing, therefore the following is a
  4183. brief documentation of some of the parameters defined in this file.
  4184.  
  4185. #define INSTBITNUM 5
  4186. #define INSTNUM 32         /* INSTNUM = 2 ^ INSTBITNUM */
  4187.  
  4188.      INSTBITNUM defines the number of bits used by instructions in the soup.
  4189. All of the instruction sets that have been implemented use five bits.
  4190. INSTNUM is the number of distinct opcodes in the instruction set which
  4191. is always 2 ^ INSTBITNUM.
  4192.  
  4193. #define PLOIDY 1
  4194.  
  4195.      PLOIDY defines the number of parallel instruction tracks contained in
  4196. the soup.  Tierra is normally run as a haploid model, meaning that each
  4197. creature has one copy of the genome.  It is possible for creatures to
  4198. contain two or more copies of the genome (humans have two copies of each
  4199. chromosome), by defining ploidy to a number larger than one.  However,
  4200. it has been some time since this option has been used, and it may not work
  4201. at present.  The option will likely be exercised in the near future.
  4202.  
  4203. #ifndef INST
  4204. #define INST 1  /* 1, 2, 3 or 4 */
  4205. #endif
  4206.  
  4207.      INST defines which of the four instruction sets will be implemented.
  4208. This variable may be defined in the makefile.
  4209.  
  4210. #define STACK_SIZE 10
  4211.  
  4212.      Each of the four instruction sets includes a stack, whose size is defined
  4213. by this variable.
  4214.  
  4215. #define ALOC_REG 4
  4216. #define NUMREG 4
  4217.  
  4218.      Each of the four instruction sets uses an array of registers, whose size
  4219. is controlled with these variables.  The number of actual registers is defined
  4220. by NUMREG, but there may be additional virtual registers (as in INST == 2),
  4221. which can be allocated by settin ALOC_REG larger than NUMREG.
  4222.  
  4223. #define GETBUFSIZ 3
  4224. #define PUTBUFSIZ 3
  4225.  
  4226.      Instruction sets two through four include communication functions,
  4227. get() and put(), which read from the get buffer and write to the put buffer.
  4228. GETBUFSIZ and PUTBUFSIZ control the size of these buffers.
  4229.  
  4230. #ifndef FRONTEND
  4231. #define FRONTEND BASIC  /* BASIC or STDIO */
  4232. #endif
  4233.  
  4234.      There are two frontends.  The BASIC frontend provides the best
  4235. interface, but requires the use of the console.  In order to run Tierra in
  4236. the background (on unix systems) Tierra should be compiled with the STDIO
  4237. frontend whose output can be redirected to /dev/null.
  4238.  
  4239. /* #define CM5       */ /* CM5 the version for the CM5 */
  4240.  
  4241.      CM5 controls variations specific to the MIMD implementation of Tierra
  4242. on the CM5, the Connection Machine manufactured by Thinking Machines
  4243. Corporation.
  4244.  
  4245. #define MICRO        /* define for micro step debugging */
  4246.  
  4247.      MICRO implements the code required to use the virtual debugger.
  4248.  
  4249. /* #define HSEX      */ /* define for haploid, crossover sex */
  4250.  
  4251.      HSEX implements the code used to support haploid sex among creatures.
  4252.  
  4253. #define ICC          /* define for inter-cellular communication, != I/O */
  4254.  
  4255.      Instruction sets two through four have two communications options.
  4256. If ICC is defined, the put() and get() instructions cause communications
  4257. between cells.  In this case the put() function of one cell writes to the get
  4258. buffer(s) of other cell(s).  If ICC is not defined, put() and get() write and
  4259. read to the buffers of the active cell, and these communications are intended
  4260. for the user.
  4261.  
  4262. /* #define READPROT  */ /* define to implement read protection of soup */
  4263. #define WRITEPROT    /* define to implement write protection of soup */
  4264. /* #define EXECPROT  */ /* define to implement execute protection of soup */
  4265.  
  4266.      Instructions in the soup can be protected using the mal() instruction.
  4267. The status of protected and unprotected memory is determined by the two
  4268. soup_in variables: 
  4269.  
  4270. MemModeFree = 0  read, write, execute protection for free memory
  4271. MemModeProt = 2 rwx protect mem: 1 bit = execute, 2 bit = write, 4 bit = read
  4272.  
  4273. However, each of the three memory protection modes costs cpu time, therefore
  4274. they should not be compiled unless they are going to be used.  The
  4275. READPROT, WRITEPROT, and EXECPROT definitions control which protection modes
  4276. are implemented at compile time.
  4277.  
  4278. /* #define ERROR     */ /* use to include error checking code */
  4279.  
  4280.      ERROR turns on a large body of error checking and verification code.
  4281. It should only be used while debugging Tierra.
  4282.  
  4283. /* #define ALCOMM    */ /* define for socket communications */
  4284.  
  4285.      ALCOMM turns on the code used to communicate with the ALmond monitor
  4286. program (unix only).
  4287.  
  4288. /* #define MEM_PROF  */ /* profile dynamic memory usage */
  4289.  
  4290.      MEM_PROF turns on code that provides a summary of how dynamically
  4291. allocated memory is being used.  This is basically for debugging purposes.
  4292.  
  4293. 12) KNOWN BUGS
  4294.  
  4295.      Memory management for the DOS version is very tricky, and is not yet
  4296. air-tight.  During any run using the genebank, the demand for memory grows
  4297. as genomes accumulate in RAM.  Eventually the memory fills up, and the
  4298. memory management routines swap extinct genomes out to disk.  When a lot
  4299. of genomes are swapped to disk, the system thrashes in the swapping of
  4300. genomes between RAM and disk.  Eventually some memory request will fail due
  4301. to memory fragmentation or the accumulation of too many living genomes in
  4302. RAM, and the system will come down.  At this point just bring the system
  4303. back up by typing: tierra soup_out.  Bringing the system down and back up
  4304. should eliminate the memory fragmentation, and effect some garbage collection,
  4305. freeing up more memory.  It is actually a good idea to bring the system
  4306. up and down on DOS machines before they run out of memory, just to clear
  4307. the memory.  You can tell if you are running out of memory by selecting the
  4308. i-info option from the menu.  At the upper left of the screen you will then
  4309. see a message like: Coreleft = 4400.  This tells you that the system is out
  4310. of memory (Tierra is not allowed to use the last 4K of memory).
  4311.  
  4312. 13) IF YOU HAVE PROBLEMS
  4313.  
  4314.   13.1) Problems with Installation
  4315.  
  4316.      Read the installation instructions carefully.  Where we present
  4317. alternative methods, try them all.  If it still doesn't work, please
  4318. let us know.  We would like to help people with installation, and make
  4319. sure that our instructions are clear.  If you are using a compiler or
  4320. machine we have not tested, we may not be able to help you, but we want
  4321. to accomodate these additional conditions.  We would like to help you
  4322. find a solution and incorporate the solution in future releases.
  4323.  
  4324.   13.2) Problems Running Tierra
  4325.  
  4326.      Read all of the .doc files.  You may find the answer there.  If a
  4327. problem still persists, and you have ftp access, get a new copy of the
  4328. source code out of the ftp site.  It is likely that the source code will be
  4329. updated on a roughly monthly or bimonthly basis as we continue to improve
  4330. the program.  By the time you are sure there is a problem, we may already
  4331. have fixed it and placed a fix in the ftp site.
  4332.  
  4333.      If the problem still persists after you have tested the latest version
  4334. of the software, let us know about the problem.  We would like to fix it.
  4335. If you do not have ftp access, and you identify a bug, we will fix it and
  4336. send you a free upgrade if you return you original distribution disk in
  4337. a disk mailer.
  4338.  
  4339. 14) REGISTRATION & MAILING LISTS
  4340.  
  4341.      The reason you might want to register your copy of the software is so
  4342. that we can contact you if we discover a bug, or we can let you know when
  4343. new versions of the program are ready for distribution.  If you obtained
  4344. Tierra on disk, send your name, address and the serial number of your
  4345. distribution disk to Virtual Life at the address listed below.  If you
  4346. obtained Tierra from the ftp site, send you email address to:
  4347.  
  4348. tierra-request@life.slhs.udel.edu
  4349.  
  4350.      There is a mailing list for Tierra users. (actually 2, but you only want
  4351. to be on one of them).  The first list is for people who only want to get the
  4352. official announcements, updates and bug-fixes.  The other will carry the 
  4353. official postings, and are intended for discussion of Tierra by users.
  4354. This one is distributed in digest form, when there is enough material.
  4355. The lists are:
  4356.  
  4357. tierra-announce    official updates, patches and announcements only
  4358. tierra-digest      discussion, updates, etc. (digest form)
  4359.  
  4360. The addresses are: 
  4361.  
  4362. tierra-request@life.slhs.udel.edu   the list administrator. to be added,
  4363.                                     removed, or complain about problems with
  4364.                                     any of these lists.
  4365.  
  4366. tierra-digest@life.slhs.udel.edu    to post to the list.
  4367.  
  4368. tierra-bug@life.slhs.udel.edu       for bug-reports or questions about the
  4369.                                     code or installation.
  4370.  
  4371.      You may also be interested in the Artificial Life mailing list.
  4372. Subscribe to the list by sending a message to:
  4373.  
  4374. alife-request@cognet.ucla.edu
  4375.  
  4376.      Post to the list by sending a message to:
  4377.  
  4378. alife@cognet.ucla.edu
  4379.  
  4380. Tom Ray
  4381. Virtual Life
  4382. P.O. Box 625
  4383. Newark, DE 19715
  4384.  
  4385. From January through August, we will be at:
  4386.  
  4387. Tom Ray
  4388. Santa Fe Institute
  4389. 1660 Old Pecos Trail, Suite A
  4390. Santa Fe, NM 87501
  4391. ray@santafe.edu
  4392. 505-984-8800
  4393. 505-982-0565 (FAX)
  4394.  
  4395. From September through December, we will be at:
  4396.  
  4397. Tom Ray
  4398. University of Delaware
  4399. School of Life & Health Sciences
  4400. Newark, Delaware  19716
  4401. ray@udel.edu
  4402. 302-831-2753
  4403. 302-831-2281 (FAX)
  4404.