[net.games] DOC for COREWARS

ejb@think.ARPA (Erik Bailey) (10/29/85)

***
*   Here is the doc for the PC version of COREWAR. [Do people want
*   the code posted?]. Hope it helps you understand the game...
***

---------------------------Fold, Staple, Mutilate----------------------

     Core War is a computer game played both with and BY  compu-
ters.  In Core War,  two player-written computer programs operate
concurrently in a "circular"  memory  array.  A program "loses" 
when it hits an instruction it cannot execute. 
 
     Core War is described more fully by A. K. Dewdney in the 
"Computer Recreations" column of Scientific  American, May 1984.
A short synopsis follows:
 
     Core War battle programs are written in a special assembler-
style  language called Redcode,  which defines only 9  operations.
Unlike  regular  assembly code,  any arguments  that  an 
instruction  may  have are considered to be contained in a single 
memory location,  so addressing is very simple.  For example, 
the instruction JMP -2 simply means jump back 2 locations  before 
this  one -- JMP 0 would be an endless loop on that one location, 
and  JMP 1 simply moves to the next  location  -- essentially,  a 
"No-operation" Instruction.
 
     Neither  program originally knows where in memory the  other 
is,  or even where the program itself has started -- however, the 
memory array  used by Core War is "circular," and all addressing
is relative, so absolute memory addresses are not important.
 
     The nine Redcode instructions are:
 
     Instr:    Arguments:     Description/Result:
 
     MOV       A    B         B will equal A (A is unchanged)
 
     ADD       A    B         B will equal B + A (A unchanged)
 
     SUB       A    B         B will equal B - A (A unchanged)
 
     JMP       A              Program will jump to A
 
     JMZ       A    B         Program will jump to A if B is zero
 
     JMG       A    B         Program will jump to A if B > 0
 
     DJZ       A    B         B will equal B - 1; if this is 
                              zero, program jumps to A
 
     CMP       A    B         Skip the next instruction unless A = B
 
     DAT            B         B is data.  A PROGRAM LOSES WHEN IT TRIES
                              TO EXECUTE A "DAT" STATEMENT.
                              
     There  are  also three addressing modes,  or ways  in  which 
arguments  can  be presented.  They  are  Direct,  Indirect,  and 
Immediate.  In Direct mode, the argument is taken as an offset to 
the current address.  This is the default mode.  Thus, the state-
ment DJZ 12 -1 would decrement the previous location, and if that 
result  were  zero,  would jump forward 12 locations (or  if  not 
zero, it would move ahead one, normally).
 
     In Indirect mode,  denoted by the "@" symbol,  the indicated 
relative  address contains a further relative  address.  Consider 
the four-statement sequence:  JMP   @1
                                  DAT           1
                              JMP    12
                              CMP   -10    -11 
      The first  jump statement will look for its argument in 
relative address  +1.  In this example, it finds a 1,  which
RELATIVE TO THAT ADDRESS is 1 -- it points to the statement JMP 12.
Had it been a 2,  it would have  pointed to the CMP instruction.
A -1 would have pointed to 
the original JMP @1, and been an endless loop (assuming the enemy 
program never changes either location).  Had it been 0,  the pro-
gram  would  have jumped to the DAT ststement  and  been  halted, 
having "committed suicide."
 
     Finally,  Immediate  mode takes the argument as an  absolute 
number,  and is denoted by the "#" sign.  CMP #2 -3 will check to 
see  if the value at offset -3 is equal to 2.  Immediate mode has 
two special cases which are very important to Core Wars -- first, 
a MOV statement with an Immediate argument in the first  argument 
will  cause  the  argument addressed in the  second  argument  to 
become  a  DAT instruction. (Had the argument not been  Immediate, 
MOV would instead have copied everything,  arguments and instruc-
tions.  Thus, a battle program can move itself around in memory.)
This  is a very handy way of planting "bombs" in the  enemy  pro-
gram's code.
 
     The  second  important thing to realize is that you can  NOT 
have an Immediate,  or absolute, address. If the operating system 
sees an Immediate-mode argument as an offset,  it will automatic-
ally assume an offset of zero, which can have disastrous results.
 
     Which argument is which?   The second,  or "B" argument,  is 
the one that contains data for ADD, SUB, CMP, and the conditional 
jump  instructions.  Thus,  when  the first  instruction  of  the 
Redcode sequence ADD #2   1
                 CMP  3  15 is performed, the second line will be 
changed to compare locations 3 and 17. The first, or "A" argument 
is almost never altered by Redcode operations (except for MOV).
     Both battle programs are executed by the Core War operating 
system,  MARS.  In  the version presented here,  MARS is also the 
program  loader;  programs may be loaded either from the keyboard 
or from disk (when you give the program a name, it will check the 
directory for that name -- if it finds it,  it will load it  from 
disk,  assuming the program to be an ASCII file). The MARS inter-
preter  simply keeps switching its program counter from one  pro-
gram  to another -- ABABABABABABAB....  until either one  program 
loses,  some maximum number of instruction cycles have been  per-
formed  (as a safeguard against endless loops),  or until you hit 
<ESC> to abort.
 
     Here is the shortest possible battle program, called "Imp":
 
                         MOV  0    1
 
     Imp  just copies the current location to the next  location, 
then  advances  to the next location,  etc.  While  the  original 
program  is  short,  it  will eventually gobble up  every  memory 
location if unchecked,  thus becoming the largest possible battle 
program as well.  It can even spread to its opponent,  since  any 
program  that  jumps to a location written by Imp will become  an 
identical clone of Imp.
 
     Here is another program, "Anti.Imp":
 
                         MOV  #0   -5
                         CMP  #0   -6
                         JMP  -1
                         MOV  #0   -5
                         MOV  #0   -6
                         MOV  #0   -7
                         MOV  #0   -8
                         JMP  -7
 
     Anti.Imp sets up a "marker" byte at -5 relative to its first 
byte,  then waits for Imp to come along. When the marker changes, 
it bombards the area that Imp is movinbg into with DAT 0 instruc-
tiomns, which Imp can't execute and thus bites it.
 
     Here is "AntiAnti.Imp":
 
                         MOV   4   @3
                         ADD  #1    2
                         JMP  -2
                         DAT        2
                         MOV   0    1
 
     AntiAnti.Imp writes a block of code that LOOKS like Imp into 
progressively higher memory locations.  When Anti.Imp senses this 
"drone" Imp,  it will attack it, but to no avail -- it will still 
get over-written,  and then become a clone of Imp (at which point 
it  turns around and wreaks havoc on AntiAnti.Imp,  which has  no 
protection against Imp itself as shown here....).
     Other examples are given in Dewdney's article,  such 
as Dwarf:       dat             -1
                        add     #5      -1
                        mov     #0      @-2
                        jmp     -2
which fires "Zero Bombs" in a fashion similar to Anti-
Anti.Imp;  Gemini,  which simply runs away;  or Raidar,  which is 
able  to "leapfrog" over advancing attacks. 
 
     COREWARS.C was written by Kevin A. Bjorke 5/25/84, in Small-C 
version 2.03 (M80),  which is  available  to the public domain
through RCP/M's as well as MicroCornucopia. The addition 
of  a few << and >> operations will speed it up a bit. 
 
        A C86 version of the original Small-C (CPM) program has been 
written by R. Green for use with MS-DOS, and a DeSmet C version
with an optional split-screen "picture" of core has been written
by R. Sawyer.
-- 
Erik Bailey
_  _  _  _  _  _  _  _  _  _  _  _  _  _  _  _  _  _  _  _  _  _  _  _
 -_ -_ -_ -_ -_ -_ -_ -_ -_ -_ -_ -_ -_ -_ -_ -_ -_ -_ -_ -_ -_ -_ -_ -_

Erik Bailey        -- 7 Oak Knoll                (USENET courtesy of
ihnp4!godot!ejb       Arlington, MA  02174        Thinking Machines Corp.
ejb@think.com.arpa    (617) 643-0732              Cambridge, MA)

"I was walking in a forest one day and a tree fell in front of me,
 and I didn't hear it."
  _  _  _  _  _  _  _  _  _  _  _  _  _  _  _  _  _  _  _  _  _  _  _  _
_- _- _- _- _- _- _- _- _- _- _- _- _- _- _- _- _- _- _- _- _- _- _- _-