Core War Frequently Asked Questions (rec.games.corewar FAQ)
-----------------------------------------------------------
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 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 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 The Armchair Universe: New York, 1988 0-7167-1938-X (Hardcover)
A. K. An Exploration of W. H. Freeman 0-7167-1939-8 (Paperback)
Computer Worlds
Dewdney The Magic Machine: New York, 1990 0-7167-2125-2 (Hardcover)
A. K. A Handbook of W. H. Freeman 0-7167-2144-9 (Paperback)
Computer Sorcery
-----------------------------------------------------------------------------
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:
*
https://corewar.co.uk/pmars.htm
*
http://www.koth.org/pmars
*
https://sourceforge.net/projects/corewar
*
https://corewar.co.uk/pihlaja/pmars-sdl
CoreWin is a full-featured, GUI-based Core War simulator for
Windows:
*
https://corewar.co.uk/wendell
ARES is an IDE and Core War simulator for Windows with some
experimental features:
*
https://harald.ist.org/sites/ares/
There are several notable MARS suitable for embedding or use in
an evolver. Joonas Pihlaja wrote exhaust which Martin Ankerl
later rewrote as exMARS:
*
https://corewar.co.uk/pihlaja/exhaust
*
https://corewar.co.uk/ankerl/exmars.htm
PyCorewar is simple Python library for debugging and benchmarking
Core War programs:
*
https://corewar.co.uk/gutzeit/pycorewar
corewar.io is an online interactive Core War simulator and
debugger:
*
https://www.corewar.io
____________________________________________________________
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/
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
____________________________________________________________
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:
*
https://users.obs.carnegiescience.edu/birk/COREWAR
*
http://para.inria.fr/~doligez/corewar
*
http://www.koth.org
*
https://corewar.co.uk
*
http://newton.freehostia.com/net/corewar
*
http://www.corewar.info
____________________________________________________________
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
* 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 ";strategy".
* Email this file as plain text to
koth@koth.org or
koth@sal.discontinuity.info.
* 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.
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 Core Max Max Min Instr
Hill Name Size Size Proc Cycles Len Dis Rounds Set
-------------------------- ------ ------- ------- -------- ----- ----- -------- --------
KOTH.org's '88 Standard 20 8000 8000 80000 100 100 250 ICWS '88
Hill (";redcode")
KOTH.org's '94 Standard 20 8000 8000 80000 100 100 250 Extended
Hill (";redcode-94") ICWS '94
KOTH.org's '94 No Pspace 20 8000 8000 80000 100 100 250 ICWS '94
Hill (";redcode-94nop")
KOTH.org's '94 Big 20 55440 10000 500000 200 200 250 Extended
Hill (";redcode-94x") ICWS '94
KOTH.org's '94 Multiwar 10 8000 8000 80000 100 100 500 Extended
Hill (";redcode-94m") ICWS '94
SAL's Beginner's 25 8000 8000 80000 100 100 6x250 Extended
Hill (";redcode-94b") ICWS '94
SAL's Tiny 25 800 800 8000 20 20 6x250 Extended
Hill (";redcode-tiny") ICWS '94
SAL's Nano 50 80 80 800 5 5 30x250 Extended
Hill (";redcode-nano") ICWS '94
SAL's Limited Process 25 8000 8 80000 200 200 6x250 Extended
Hill (";redcode-lp") 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:
* -1 (or CORESIZE-1) at the beginning of the first round
* 0 if 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 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:
* use meaningful label names
* enclose 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, #2 is 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)
____________________________________________________________
Credits
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–2022 the Core War FAQ Contributors. Content of
the FAQ is available under the GNU Free Documentation License,
version 1.3.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)