home *** CD-ROM | disk | FTP | other *** search
/ ftp.uni-stuttgart.de/pub/systems/acorn/ / Acorn.tar / Acorn / acornet / fun / games / corewars.spk / !CoreInfo / Info / Intro < prev   
Text File  |  1990-11-03  |  7KB  |  131 lines

  1.  
  2.  
  3.    CORE WARS INTRODUCTION AND GUIDE 
  4.    --------------------------------
  5.  
  6.  This file is an extract from a rather dated corewars instruction manual.
  7. Changes have been documented where appropriate, and outdated or incorrect
  8. information deleted.
  9.  
  10.  
  11.  PREFACE
  12.  
  13. Core Wars is a game played by two programs in a computer called "MARS". The
  14. programs are written in an assembly language called "REDCODE". It is based
  15. on an article by a. K. Dewdney that appears in the May, 1984 SCIENTIFIC
  16. AMERICAN. The object of the game is to cause the opposing player to terminate
  17. abnormally.
  18.  
  19. MARS and REDCODE were invented solely for the purpose of playing Core Wars,
  20. and are not based on any one existing computer or language. No actual MARS 
  21. hardware has been created as far as we know, so MARS is simulated by software
  22. that can run on a standard personal computer.
  23.  
  24.                                
  25.  
  26.  
  27.  THE CORE WARS PHILOSOPHY
  28.  
  29.  The "MARS" System consists of the MARS simulator and the REDCODE assembler.
  30. The REDCODE assembler processes the REDCODE "source code" of the competing
  31. programs, producing "object code" which can be loaded into MARS and executed.
  32. The MARS simulator loads the competing programs, program "A" and program "B"
  33. into simulated "Core", or memory, then begins executing them alternately. The
  34. first instruction of program "A" is executed, then the first instruction,
  35. etc. Both programs try to continue executing longer than the other program.
  36. For example, a program might try to store invalid instructions overlaying
  37. their opponents' good instructions. A program stops running if it tries to
  38. execute an invalid instruction. The winner is the program that continues to
  39. run after its opponent stops. A draw occurs in either of two cases: If both
  40. programs continue forever, or if both programs execute the same number of 
  41. valid instructions before stopping.
  42.  
  43. *** Note ***
  44.  In the archimedes corewars program, there is a seperate program, !CoreDebug
  45. which will process a text file as if compiling it, and provide information
  46. on any errors present, if any, but do nothing more. The main program,
  47. !CoreWars, contains the same assembler, but programs are compiled only at 
  48. run-time, thereby removing the need for an intermediate object code.
  49.  With the enhanced capabilities of the archimedes, as opposed to the machines
  50. being used at the time of creation of Corewars, a different scheme of labell-
  51. ing is used, whereby the different sides are called green and red, with a
  52. corresponding colour scheme in the run mode. Look for more details in the
  53. file called 'colours'.
  54.  There is an option called 'timeout no win'; when enabled, this means that
  55. when the allotted time limit has been reached, or the user aborts the battle,
  56. the game will be considered a draw (or timeout). Otherwise, as is the case
  57. with the Mac version of corewars, the longest program is considered the
  58. winner.
  59. ************
  60.  
  61.  The instruction set of REDCODE must remain simple. The tendency of advanced
  62. programmers to try and add complicated instructions to the REDCODE instruc-
  63. tion set must be thwarted. This is important for two reasons: First, we want
  64. to interest inexperienced programmers in Core wars. Second, we want to reduce
  65. the complexity of MARS. Even though the instruction set is simple, it should
  66. encourage richness and variety in programming techniques, while at the same
  67. time encouraging brevity. That is, the kind of program that should succeed
  68. at Core wars is short and clever.
  69.  
  70.  The memory size is the number of different 'cells' or 'locations' which can
  71. be accessed in the MARS memory. It can be any size from 2048 locations up,
  72. depending on the implementation.
  73.  
  74. *** Note ***
  75.  In the archimedes version of Corewars, the memory size has been set at
  76. 32000 cells, quite a high value compared to the 2048 minimum both because the
  77. archimedes is capable at executing at high speeds, and to give room to longer
  78. programs. The value 32000 was also chosen because it is a multiple of 8000,
  79. the memory size of the Mac version of corewars (thereby giving compatibility)
  80. and has many different prime factors (ie 2,4,5,8,10..) which can be exploited
  81. when writing non-self-destructing dwarf programs etc.
  82. ************
  83.  
  84.  All addressing in REDCODE is always relative to the current instruction,
  85. modulo memory size. Thus, memory location "+1" contains the next instruction
  86. to be executed. Also note that if an instruction refers to memory location
  87. "+5", and the following instruction refers to memory location "+4", they are
  88. referring to the same memory location! This way of referencing data is
  89. crucial to the philosophy of REDCODE, because it is the way we ensure that
  90. programs are "relocatable" -- that is, that they will execute properly no
  91. matter where in core they are loaded.  
  92.  
  93.  For every cell in MARS memory, there is an opcode (which instruction), add-
  94. ressing mode flags for each operand (ie. is it immediate or direct etc.) and
  95. two operands reserved (holding the data for the instruction), although only
  96. one of these may be used by some instructions.
  97.  
  98.  Data representation in REDCODE also requires some explanation. All data that
  99. can be represented in REDCODE is considered modulo memory size, just as add-
  100. resses are. In fact, the set of values that can be represented can be con-
  101. sidered in one-to-one correspondence with MARS memory locations. There are no
  102. "positive" numbers or "negative" numbers. All arithmetic is "clock" arith-
  103. metic, module memory size. This view of data may seem restrictive, but in
  104. fact it simplifies address calculations, which are the bulk of calculations
  105. usually performed in a REDCODE program.
  106.  
  107. *** Note ***
  108.  In the archimedes version of corewars, there is a slight alteration to the
  109. method of storing numbers. Data, ie 'dat -4' is stored as described above.
  110. Any negative numbers in instructions, however, such as 'mov -2,-3', are
  111. stored with a bit set aside to indicate sign. This is so that when in any of
  112. the debug modes, the previous example would be disassembled as 'mov -2,-3'
  113. not 'mov 31998,31997', which looks a little messy. This makes absolutely no
  114. difference in the operation of the program, and so need not be considered.
  115. ************
  116.  
  117.  A program must be able to address ANY word in core at any given time. There
  118. is no range limitation other than that imposed by the size of CORE itself.
  119. Internal representation of address is left up to a given implementer. The
  120. only assumption that should be made is that it will always be possible to
  121. address the entire range of core.
  122.  
  123.  Whether the core size is variable at run time or assembly time may vary with
  124. the implementation. Core size must never change after the programs begin to
  125. execute. The number of words in core may be any number not less than 2048,
  126. and may be even or odd, or even prime.
  127.  
  128.  The actual instruction set is detailed in the file called 'commands'; the
  129. archimedes implementation of corewars is discussed in the file '!CoreWars',
  130. and the colour scheme used in the archimedes version is detailed in the file
  131. called 'colours'.