- Core War Frequently Asked Questions -

These are the Frequently Asked Questions (and answers) for the programming game Core War.

Table of Contents

  1. What is Core War
  2. Is it "Core War", "Core Wars" or "Corewar"?
  3. Where can I find more information about Core War?
  4. Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set?
  5. What is ICWS'94?
  6. What is the ICWS?
  7. What is Core Warrior?
  8. Where are the Core War archives?
  9. Where can I find a Core War system?
  10. Where can I find warrior code?
  11. I do not have access to Usenet. How can I read the Core War newsgroup?
  12. Are there any Core War related WWW sites?
  13. What is KotH? How do I enter?
  14. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core under ICWS'88 rules?
  15. How does SLT (Skip if Less Than) work?
  16. What is the difference between in-register and in-memory evaluation?
  17. What is P-space?
  18. What does "Missing ;assert" in my message from KotH mean?
  19. How should I format my code?

1. What is Core War?

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 the address 0. The next instruction is 1, and the previous one obviously -1. However, all numbers are treated as positive, and are in the range 0 to CORESIZE-1 where 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. 3218 + 7856 = (3218 + 7856) mod CORESIZE. Many people get confused by this, and it is particularly important when using the SLT instruction. Note that the source code of a program can still contain negative numbers, but if you start using instructions like 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 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 MOV, DIV or even 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 SPL instruction are added to the task queue after the creating process is put back into the task queue.

2. Is it "Core War", "Core Wars" or "Corewar"?

All three terms are used. A. K. Dewdney used Core War. Other early references use Core Wars. Lately, people seem to prefer "Corewar".

3. Where can I find more information about Core War?

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
Dewdney, A. K. The Armchair Universe:
An Exploration of Computer Worlds		 New York: W. H. Freeman © 1988 0-7167-1938-X (Hardcover)
0-7167-1939-8 (Paperback)
Dewdney, A. K. The Magic Machine:
A Handbook of Computer Sorcery		 New York: W. H. Freeman © 1990 0-7167-2125-2 (Hardcover)
0-7167-2144-9 (Paperback)

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.

5. What is ICWS'94?

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.

6. What is the ICWS?

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.

7. What is Core Warrior?

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.

8. Where are the Core War archives?

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.

9. Where can I find a Core War system?

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:

10. Where can I find warrior code?

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).

11. I do not have access to Usenet. How can I read the Core War newsgroup?

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

to listproc@koth.org. You can send mail to corewar-l@koth.org to post even if you are not a member of the list.

Google Groups provides a gateway to Usenet and rec.games.corewar at https://groups.google.com/group/rec.games.corewar.

12. Are there any Core War related WWW sites?

You bet. The following websites offer convenient access to software, tutorials, past newsletters and warrior code:

13. What is KotH? How do I enter?

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

Sample Entry

;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 "foo v1.0" on the hill, adding the line ";kill foo" to a new program will automatically bump 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.

Popular Hills

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 (";redcode") 20 8000 8000 80000 100 100 250 ICWS '88
KOTH.org's '94 Standard Hill (";redcode-94") 20 8000 8000 80000 100 100 250 Extended ICWS '94
KOTH.org's '94 No Pspace Hill (";redcode-94nop") 20 8000 8000 80000 100 100 250 ICWS '94
KOTH.org's '94 Big Hill (";redcode-94x") 20 55440 10000 500000 200 200 250 Extended ICWS '94
KOTH.org's '94 Multiwarrior Hill (";redcode-94m") 10 8000 8000 80000 100 100 500 Extended ICWS '94
SAL's Beginner's Hill (";redcode-94b") 25 8000 8000 80000 100 100 6 × 250 Extended ICWS '94
SAL's Tiny Hill (";redcode-tiny") 25 800 800 8000 20 20 6 × 250 Extended ICWS '94
SAL's Nano Hill (";redcode-nano") 50 80 80 800 5 5 30 × 250 Extended ICWS '94
SAL's Limited Process (LP) Hill (";redcode-lp") 25 8000 8 80000 200 200 6 × 250 Extended ICWS '94

Note: Warriors on the beginner's hill are retired at age 50.

14. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core under ICWS'88 rules?

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 comparison.

Note: under ICWS'94 rules DAT 0, 0 is a legal instruction and '94 standard assemblers will assemble DAT 0, 0.

15. How does SLT (Skip if Less Than) work?

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, -1 becomes CORESIZE-1.

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.

16. What is the difference between in-register and in-memory evaluation?

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 MOV, ADD, SUB, MUL, DIV and MOD where 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 L2 instruction is saved in a buffer before the L2 memory location is decremented by evaluation of the B-operand of L1. The saved DAT #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 L1, L2 changes to DAT #0,#0.

17. What is P-space?

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. P-space address 1 is always 1 regardless of where the instruction is referenced from.

P-space can only be accessed by two special instructions, LDP and STP. 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 MOV. So STP.AB #Q, #R would put the number Q into the P-space cell R mod PSPACESIZE. Similarly,

        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:

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 PSPACESIZE. All cells in P-space (except for cell 0) are initialized to 0.

18. What does "Missing ;assert" in my message from KotH mean?

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:

;assert CORESIZE==8000

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:

;assert 1

in your code, which means it will compile unconditionally.

19. How should I format my code?

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:

Credits

Additions, corrections, etc. to this document are solicited. Thanks in particular to the following people who have contributed major portions of this document:

Copyright © 1991–2022 the Core War FAQ Contributors. Content of the FAQ is available under the GNU Free Documentation License, version 1.3.