- Core War
These are the Frequently Asked Questions (and answers) for the programming game Core War.
- What is Core War
- Is it "Core War", "Core Wars" or "Corewar"?
- Where can I find more information about Core War?
- Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set?
- What is ICWS'94?
- What is the ICWS?
- What is Core Warrior?
- Where are the Core War archives?
- Where can I find a Core War system?
- Where can I find warrior code?
- I do not have access to Usenet. How can I read the Core War newsgroup?
- Are there any Core War related WWW sites?
- What is KotH? How do I enter?
- Is it
DAT 0, 0or
DAT #0, #0? How do I compare to core under ICWS'88 rules?
- How does
SLT(Skip if Less Than) work?
- What is the difference between in-register and in-memory evaluation?
- What is P-space?
- What does "Missing ;assert" in my message from KotH mean?
- How should I format my code?
Core War is a game played by two or more programs (and vicariously by their authors) written in an assembly language called Redcode and run in a virtual computer called MARS (for Memory Array Redcode Simulator). The object of the game is to cause all processes of the opposing program to terminate, leaving your program in sole posession of the machine.
There are Core War systems available for most computer platforms. Redcode has been standardized by the ICWS, and is therefore transportable between all standard Core War systems.
The system in which the programs run is quite simple. The core (the memory of the simulated computer) is a continuous array of instructions, empty except for the competing programs. The core wraps around, so that after the last instruction comes the first one again.
There are no absolute addresses in Core War. All addresses are
relative. That is, the address
0 doesn't mean the
first instruction in the memory, but the instruction that contains
0. The next instruction is
and the previous one obviously
-1. However, all numbers are treated as positive, and
are in the range
CORESIZE is the amount of memory locations in the core
- this means that
-1 would be treated as
CORESIZE-1 in any arithmetic operations, e.g.
7856 = (3218 + 7856) mod CORESIZE. Many
people get confused by this, and it is particularly important when
SLT instruction. Note that the source code of a program
can still contain negative numbers, but if you start using
DIV #-2, #5 it is
important to know what effect they will have when executed.
The basic unit of memory in Core War is one instruction. Each Redcode instruction contains three parts:
- the opcode
- the source address (a.k.a. the A-field)
- the destination address (a.k.a. the B-field)
The execution of the programs is equally simple. The MARS executes
one instruction at a time, and then proceeds to the next one in the
memory, unless the instruction explicitly tells it to jump to
another address. If there is more than one program running, (as is
usual) the programs execute alternately, one instruction at a time.
The execution of each instruction takes the same time, one cycle,
whether it is
DAT (which kills the process).
Each program may have several processes running. These processes
are stored in a task queue. When it is the program's turn to
execute an instruction it dequeues a process and executes the
corresponding instruction. Processes that are not killed during the
execution of the instruction are put back into the task queue.
Processes created by a
are added to the task queue after the creating process is
put back into the task queue.
All three terms are used. A. K. Dewdney used Core War. Other early references use Core Wars. Lately, people seem to prefer "Corewar".
Core War was first described in the Core War Guidelines of March, 1984 by D. G. Jones and A. K. Dewdney of the Department of Computer Science at The University of Western Ontario (Canada). Dewdney wrote several "Computer Recreations" articles in Scientific American which discussed Core War, starting with the May 1984 article. Those articles are contained in two anthologies:
|Author||Title||Published||ISBN||Library of Congress Call Number|
|Dewdney, A. K.||The Armchair Universe:
An Exploration of Computer Worlds
|New York: W. H. Freeman © 1988||0-7167-1939-8||QA76.6 .D517 1988|
|Dewdney, A. K.||The Magic Machine:
A Handbook of Computer Sorcery
|New York: W. H. Freeman © 1990||0-7167-2125-2 (Hardcover)
|QA76.6 .D5173 1990|
A.K. Dewdney's articles are still the most readable introduction to Core War, even though the Redcode dialect described in there is no longer current. You can view a scanned version of the articles at http://www.koth.org/info/sciam/. For those who are interested, Dewdney has a home page at https://www.csd.uwo.ca/~akd/.
4. Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set?
A draft of the official standard (ICWS'88) is available at https://corewar.co.uk/standards/icws88.txt. This document is formatted awkwardly and contains ambiguous statements. For a more approachable intro to Redcode, take a look at Mark Durham's tutorials, http://www.koth.org/info/tutorial1.html and http://www.koth.org/info/tutorial2.html.
Steven Morrell has prepared a more practically oriented Redcode tutorial that discusses different warrior classes with lots of example code. This and various other tutorials can be found at http://www.koth.org/info.html.
Even though ICWS'88 is still the "official" standard, you will find that most people are playing by ICWS'94 draft rules and extensions.
In 1992 work began on a draft proposal for a new Core War standard, dubbed ICWS'94, to be submitted to the ICWS for evaluation. Unfortunately, the ICWS became inactive and the proposal was never officially adopted. The draft proposal has become widely accepted as the de facto Core War standard.
A major change is the addition of "instruction modifiers" that allow instructions to modify A-field, B-field or both. Also new are new addressing modes and unrestricted opcode and addressing mode combination ("no illegal instructions"). ICWS'94 is backwards compatible; i.e. ICWS'88 warriors will run correctly on an ICWS'94 system. The ICWS'94 draft is available at http://www.koth.org/info/icws94.html.
The "International Core Wars Society" (ICWS) was established in 1985, the year after Core War first appeared in Scientific American. The ICWS was responsible for the creation of two Core War standards (ICWS'86 and ICWS'88) and the running of eight annual Core War tournaments. The ICWS is no longer active.
Following in the tradition of The Core War News Letter, Push Off, and The 94 Warrior, Core Warrior was a newsletter covering strategies and current standings in Core War. Started in October 1995, back issues of Core Warrior are available at https://corewar.co.uk/cw. The final issue of Core Warrior was published in May 2007. There is a Core Warrior index at http://www.shadowmagic.org.uk/corewar/warrior.html which has a summary of the contents of each issue. Many of the earlier issues contain useful information for beginners.
Many documents such as the guidelines, the ICWS standards, previous tournament Redcode entries and Core War systems are available via ftp from ftp://ftp.koth.org/pub/corewar.
Past rec.games.corewar postings (including Redcode source listings) are archived at https://corewar.co.uk/rgc.htm.
CAUTION! There are many Core War systems available which are not ICWS'94 (or ICWS'88) compatible. Generally, the older the program - the less likely it will be ICWS compatible. The three most popular systems which support ICWS'94 are pMARS, CoreWin and ARES.
pMARS (with binaries for Windows) is available from:
CoreWin is a full-featured, GUI-based Core War simulator for Windows:
ARES is an IDE and Core War simulator for Windows with some experimental features:
There are several notable MARS suitable for embedding or use in an evolver. Joonas Pihlaja wrote exhaust which Martin Ankerl later rewrote as exMARS:
PyCorewar is simple Python library for debugging and benchmarking Core War programs:
corewar.io is an online interactive Core War simulator and debugger:
To learn the game it is a good idea to study previously posted warrior code. Damien "Planar" Doligez has a well organized library of the warriors published before 2002 at http://para.inria.fr/~doligez/corewar/ (mirror).
The most up-to-date collection of warrior code is available on Christoph C. Birk's Koenigstuhl infinite hills at https://users.obs.carnegiescience.edu/birk/COREWAR/koenigstuhl.html (mirror).
To receive rec.games.corewar articles by email, join the COREWAR-L list run on the KOTH.org list processor. To join, send the message
SUB COREWAR-L FirstName LastName
Google Groups provides a gateway to Usenet and rec.games.corewar at https://groups.google.com/group/rec.games.corewar.
You bet. The following websites offer convenient access to software, tutorials, past newsletters and warrior code:
King Of The Hill (KotH) is an ongoing Core War tournament available to anyone with email. You enter by submitting a Redcode program (warrior) with special comments via plain text email. You will receive a reply indicating how well your program did against the current top programs "on the hill".
There are two styles of KotH tournaments, "classical" and "multi-warrior". The "classical" KotH is a one-on-one tournament, that is your warrior will play a set number of battles against each of the programs currently on the Hill. You normally receive 3 points for each win and 1 point for each tie. All scores are updated to reflect your battles and the programs on the hill are ranked from high to low. If you are in last place you are pushed off the hill, otherwise someone else is pushed off.
In "multi-warrior" KotH, all warriors on the hill fight each other at the same time. Score calculation is a bit more complex than for the one-on-one tournament. Briefly, points are awarded based on how many warriors survive until the end of a round. A warrior that survives by itself gets more points than a warrior that survives together with other warriors. The pMARS documentation has more information on multi-warrior scoring.
The idea for an email-based Core War server came from David Lee. The original KotH was developed and run by William Shubert at Intel starting in December 1991 and discontinued after almost three years of service.
Currently, KotHs offering a wide variety of hills are are running at two sites: KOTH.org is maintained by Scott J. Ellentuch and sal.discontinuity.info by Barkley Vowk. The way you submit warriors to both KotHs is pretty much the same.
Entry Rules for King of the Hill Core War
- Write a Core War program. KotH is fully ICWS '94 compatible, EXCEPT that a comma (",") is required between two arguments.
- Put a line starting with "
;redcode" (or "
;redcode-94", etc., see below) at the top of your program. This MUST be the first line. Anything before it will be lost. Additionally, a "
;name <program name>" and "
;author <your name>" are required. You can also describe the algorithm you use if you have lines beginning with "
- Email this file as plain text to email@example.com or firstname.lastname@example.org.
- Within a few minutes you should receive an email telling you whether your program assembled correctly or not. If it did assemble, sit back and wait; if not, make the change required and re-submit.
- In 15 minutes or so you should get more mail telling you how your program performed against the current top programs. If no news arrives during that time, don't worry; entries are put in a queue and run through the tournament one at a time. A backlog may develop. Be patient.
;redcode ;name Imp ;author A. K. Dewdney ;strategy the simplest Redcode program able to relocate itself imp mov imp, imp+1 end ; nothing after the end instruction will be assembled
If your program makes it onto the hill, you will get mail every time a new program makes it onto the hill. If this is too much mail you can switch to quiet mode. See the KotH information at http://www.koth.org/koth.html or https://sal.discontinuity.info/help.html for more details.
Often programmers want to try out slight variations in their
programs. If you already have a program named "
v1.0" on the hill, adding the line "
;kill foo" to a new program will automatically
foo v1.0 off the hill. Just "
;kill" will remove all of your programs when you
submit the new one. The server kills programs by assigning an
impossibly low score; it may therefore take another successful
challenge before a killed program is actually removed from the
|Hill Name||Hill Size||Core Size||Max. Processes||Cycles Before Tie||Max. Length||Min. Distance||Rounds Fought||Instr. Set|
|KOTH.org's '88 Standard Hill ("
|KOTH.org's '94 Standard Hill ("
||20||8000||8000||80000||100||100||250||Extended ICWS '94|
|KOTH.org's '94 No Pspace Hill ("
|KOTH.org's '94 Big Hill ("
||20||55440||10000||500000||200||200||250||Extended ICWS '94|
|KOTH.org's '94 Multiwarrior Hill ("
||10||8000||8000||80000||100||100||500||Extended ICWS '94|
|SAL's Beginner's Hill ("
||25||8000||8000||80000||100||100||6 × 250||Extended ICWS '94|
|SAL's Tiny Hill ("
||25||800||800||8000||20||20||6 × 250||Extended ICWS '94|
|SAL's Nano Hill ("
||50||80||80||800||5||5||30 × 250||Extended ICWS '94|
|SAL's Limited Process (LP) Hill ("
||25||8000||8||80000||200||200||6 × 250||Extended ICWS '94|
Note: Warriors on the beginner's hill are retired at age 50.
Core is initialized to
DAT 0, 0.
Under ICWS'88 rules this is an illegal instruction and
'88 standard assemblers will not assemble it, only
DAT #0, #0. This begs the question,
how to compare something to see if it is empty core under
ICWS'88 rules? The answer is, the instructions before your
warrior's first instruction and after your warrior's last
instruction are most likely
DAT 0, 0.
So you can use them, or any other unmodified instructions, for
Note: under ICWS'94 rules
DAT 0, 0 is a legal instruction
and '94 standard assemblers will assemble
DAT 0, 0.
SLT skips the next instruction if
the value of the A-operand is less than value of the B-operand.
SLT can sometimes cause confusion
because of the way modular arithmetic works. It is important to
note that all negative numbers are converted to positive numbers
before a battles begins. For example,
Once you realize that all numbers are treated as positive, it is clear what is meant by "less than". It should also be clear that no number is less than zero.
These terms refer to the way instruction operands are evaluated.
The '88 Redcode standard ICWS'88 is unclear about whether a
simulator should "buffer" the result of A-operand evaluation before
the B-operand is evaluated. Simulators that do buffer are said to
use in-register evaluation, those that don't, in-memory evaluation.
ICWS'94 clears this confusion by
mandating in-register evaluation. Instructions that execute
differently under these two forms of evaluation are
the effective address of the A-operand is modified by evaluation of
the B-operand. This is best illustrated by an example:
L1 mov L2, <L2 L2 dat #0, #1
Under in-register evaluation, the
instruction is saved in a buffer before the
location is decremented by evaluation of the B-operand of
L1. The saved
#0,#1 instruction is then written to
L2, leaving it unchanged.
Under in-memory evaluation, the
L2 instruction is not buffered and thus
decremented by evaluation of the B-operand. After execution of
L2 changes to
P-space is a separate area of memory which only your program's
processes can access. The contents of each P-space cell are
preserved between rounds in a multi-round match. Unlike core memory
each P-space cell can only store one number, not a whole
instruction. Also the addressing in P-space is absolute, i.e.
1 is always
of where the instruction is referenced from.
P-space can only be accessed by two special instructions,
The syntax of these two instructions is a bit unusual.
STP has an ordinary number in
core as its source which is put into the P-space cell pointed
to by the destination. The P-space cell isn't determined by
the destination address, but by its value, i.e.
the value that would be overwritten if this were a
STP.AB #Q, #R
would put the number Q into the P-space cell R
stp.b 2, 3 dat 0, 0 dat 0, 9 dat 0, 7
would put the number 9 into the P-space cell 7.
LDP works the same way, except
the source is a P-space cell and the destination is a field in core.
The P-space cell
0 is a special
cell. It is initialized to a special value before each round.
This value is:
CORESIZE-1) at the beginning of the first round
0if the program died in the previous round
- The number of surviving programs if the program did not die in the previous round
This means that for one-on-one matches, loss=0, win=1 and tie=2.
The default size of P-space is 1/16 of the core size. This size
is the value of the predefined variable
All cells in P-space (except for cell
0) are initialized
This means you have omitted an "
;assert" line in your submission. "
;assert" is used to specify which environments
your code will work under or was designed for. For example, if your
warrior was written for the '94 draft hill then you can put:
in your code, meaning that an error will occur if you attempt to
compile the code for a different core size. If you don't want to
use the features of "
;assert" and you
want to get rid of the annoying warning just put:
in your code, which means it will compile unconditionally.
The way you format your code is really your own choice. If you are new to the game then use the style you feel most comfortable with. However, using a common format helps others to understand your code quicker. Most players tend to use the following conventions when writing code:
- use meaningful label names
EQUate expressions in parentheses, e.g.
step equ (2430+5)
- use lower case for label names and opcodes
- don't add opcode modifiers if you don't need to, e.g.
add.ab #1, #2is the same as
add #1, #2
- use whitespace after every comma
- use tabs to align the opcodes, the instruction field(s) and any comments
- do not use $ (direct addressing mode) or : (suffix of some labels)
Additions, corrections, etc. to this document are solicited. Thanks in particular to the following people who have contributed major portions of this document:
- Mark Durham (wrote the original version of the FAQ)
- Paul Kline
- Randy Graham
- Stefan Strack
- Anton Marsden
- Barkley Vowk
- John Metcalf
Copyright © 1991–2018 the Core War FAQ Contributors. Content of the FAQ is available under the GNU Free Documentation License, version 1.3.