ftp.uni-stuttgart.de/pub/systems/acorn//Acorn.tar/Acorn/acornet/fun/games/corewars.spk/!CoreInfo/Info/Intro

Text File | 1990-11-03 | 7KB | 131 lines

   CORE WARS INTRODUCTION AND GUIDE
   --------------------------------

 This file is an extract from a rather dated corewars instruction manual.
Changes have been documented where appropriate, and outdated or incorrect
information deleted.


 PREFACE

Core Wars is a game played by two programs in a computer called "MARS". The
programs are written in an assembly language called "REDCODE". It is based
on an article by a. K. Dewdney that appears in the May, 1984 SCIENTIFIC
AMERICAN. The object of the game is to cause the opposing player to terminate
abnormally.

MARS and REDCODE were invented solely for the purpose of playing Core Wars,
and are not based on any one existing computer or language. No actual MARS
hardware has been created as far as we know, so MARS is simulated by software
that can run on a standard personal computer.




 THE CORE WARS PHILOSOPHY

 The "MARS" System consists of the MARS simulator and the REDCODE assembler.
The REDCODE assembler processes the REDCODE "source code" of the competing
programs, producing "object code" which can be loaded into MARS and executed.
The MARS simulator loads the competing programs, program "A" and program "B"
into simulated "Core", or memory, then begins executing them alternately. The
first instruction of program "A" is executed, then the first instruction,
etc. Both programs try to continue executing longer than the other program.
For example, a program might try to store invalid instructions overlaying
their opponents' good instructions. A program stops running if it tries to
execute an invalid instruction. The winner is the program that continues to
run after its opponent stops. A draw occurs in either of two cases: If both
programs continue forever, or if both programs execute the same number of
valid instructions before stopping.

*** Note ***
 In the archimedes corewars program, there is a seperate program, !CoreDebug
which will process a text file as if compiling it, and provide information
on any errors present, if any, but do nothing more. The main program,
!CoreWars, contains the same assembler, but programs are compiled only at
run-time, thereby removing the need for an intermediate object code.
 With the enhanced capabilities of the archimedes, as opposed to the machines
being used at the time of creation of Corewars, a different scheme of labell-
ing is used, whereby the different sides are called green and red, with a
corresponding colour scheme in the run mode. Look for more details in the
file called 'colours'.
 There is an option called 'timeout no win'; when enabled, this means that
when the allotted time limit has been reached, or the user aborts the battle,
the game will be considered a draw (or timeout). Otherwise, as is the case
with the Mac version of corewars, the longest program is considered the
winner.
************

 The instruction set of REDCODE must remain simple. The tendency of advanced
programmers to try and add complicated instructions to the REDCODE instruc-
tion set must be thwarted. This is important for two reasons: First, we want
to interest inexperienced programmers in Core wars. Second, we want to reduce
the complexity of MARS. Even though the instruction set is simple, it should
encourage richness and variety in programming techniques, while at the same
time encouraging brevity. That is, the kind of program that should succeed
at Core wars is short and clever.

 The memory size is the number of different 'cells' or 'locations' which can
be accessed in the MARS memory. It can be any size from 2048 locations up,
depending on the implementation.

*** Note ***
 In the archimedes version of Corewars, the memory size has been set at
32000 cells, quite a high value compared to the 2048 minimum both because the
archimedes is capable at executing at high speeds, and to give room to longer
programs. The value 32000 was also chosen because it is a multiple of 8000,
the memory size of the Mac version of corewars (thereby giving compatibility)
and has many different prime factors (ie 2,4,5,8,10..) which can be exploited
when writing non-self-destructing dwarf programs etc.
************

 All addressing in REDCODE is always relative to the current instruction,
modulo memory size. Thus, memory location "+1" contains the next instruction
to be executed. Also note that if an instruction refers to memory location
"+5", and the following instruction refers to memory location "+4", they are
referring to the same memory location! This way of referencing data is
crucial to the philosophy of REDCODE, because it is the way we ensure that
programs are "relocatable" -- that is, that they will execute properly no
matter where in core they are loaded.

 For every cell in MARS memory, there is an opcode (which instruction), add-
ressing mode flags for each operand (ie. is it immediate or direct etc.) and
two operands reserved (holding the data for the instruction), although only
one of these may be used by some instructions.

 Data representation in REDCODE also requires some explanation. All data that
can be represented in REDCODE is considered modulo memory size, just as add-
resses are. In fact, the set of values that can be represented can be con-
sidered in one-to-one correspondence with MARS memory locations. There are no
"positive" numbers or "negative" numbers. All arithmetic is "clock" arith-
metic, module memory size. This view of data may seem restrictive, but in
fact it simplifies address calculations, which are the bulk of calculations
usually performed in a REDCODE program.

*** Note ***
 In the archimedes version of corewars, there is a slight alteration to the
method of storing numbers. Data, ie 'dat -4' is stored as described above.
Any negative numbers in instructions, however, such as 'mov -2,-3', are
stored with a bit set aside to indicate sign. This is so that when in any of
the debug modes, the previous example would be disassembled as 'mov -2,-3'
not 'mov 31998,31997', which looks a little messy. This makes absolutely no
difference in the operation of the program, and so need not be considered.
************

 A program must be able to address ANY word in core at any given time. There
is no range limitation other than that imposed by the size of CORE itself.
Internal representation of address is left up to a given implementer. The
only assumption that should be made is that it will always be possible to
address the entire range of core.

 Whether the core size is variable at run time or assembly time may vary with
the implementation. Core size must never change after the programs begin to
execute. The number of words in core may be any number not less than 2048,
and may be even or odd, or even prime.

 The actual instruction set is detailed in the file called 'commands'; the
archimedes implementation of corewars is discussed in the file '!CoreWars',
and the colour scheme used in the archimedes version is detailed in the file
called 'colours'.