dirk@laplace (dirksen bussiere) (05/29/91)
Around two years ago in SCIENTIFIC AMERICAN there was an article on a
programming "game" known as CORE WARS. The object seemed to be the creation of
sentient programs that went around trying to trash one another. Has anyone
heard of this "game"? If so, do you know where I can get ahold of the rules
and the programs used to create the "programming environment". My E-mail
address is DIRK%HHVMS8@VENUS.YCC.YALE.EDU . Thank a lot.
-Dirk Bussieregray@s5000.rsvl.unisys.com (Bill Gray x2128) (05/30/91)
dirk@laplace (dirksen bussiere) writes: >Around two years ago in SCIENTIFIC AMERICAN there was an article on a >programming "game" known as CORE WARS. . . Has anyone heard of this "game"? > -Dirk Bussiere I read about it once a long time ago. . . I think Nixon was president. You have (at least) two small code warriors. They alternate turns. On each turn, a code warrior a.) writes a prescribed amount of garbage into any core location(s) it desires, and b.) copies itself into another location (if it thinks that is a good tactical move). Game is over when one code warrior overwrites enough of the other to disable it. The consequences of play on a production system are left as an exercise for the reader. Bill -- : gray@rsvl.unisys.com : If you think the Brady Bill : : : will reduce crime, I have a : : Unisys has enough problems without being : trout farm in Death Valley you : : blamed for my personal opinions. : may be interested in. :
michaelb@wshb.csms.com ( WSHB Operations Eng) (05/31/91)
In article <194@s5000.rsvl.unisys.com> gray@s5000.rsvl.unisys.com (Bill Gray x2128) writes: >dirk@laplace (dirksen bussiere) writes: > >>Around two years ago in SCIENTIFIC AMERICAN there was an article on a >>programming "game" known as CORE WARS. . . Has anyone heard of this "game"? > >> -Dirk Bussiere > >I read about it once a long time ago. . . I think Nixon was president. I saw another article about Core Wars about 5 months ago for something called a "Core Wars Standard" which was to be compiled and made available. I kept a copy of the article for a while and sent mail to the address, but nothing was ever forthcoming. (Sorry, I can't find the address now.) I seem to remember that the idea was a standardized set of op codes for a virtual CPU. The fact that the opponants were supposed to write their code in the machine language of the virtual CPU attests to the age of the idea. (I suppose there isn't any reason that an assembler for the opcodes couldn't be written. Then someone could write a c++ compiler for the thing, also. After that we could use the c++ compiler to port SVR4 to the virtual CPU. .... Guess that's getting a little carried away :-)) Anyway, the idea was that a standard would exist so I could develop my code on a Motorola box, you could develop yours on an Intel box, and someone could have a contest on just any old box with everyone's entry working correctly. This is beginning to sound like the chess program tournaments. Michael -- Michael Batchelor--Systems/Operations Engineer #compliments and complaints WSHB - An International Broadcast Station of # letterbox@csms.com The Christian Science Monitor Syndicate, Inc. #technical questions and reports michaelb@wshb.csms.com +1 803 625 5552 # letterbox-tech@csms.com
kells@daimi.aau.dk (Kell S|nnichsen) (06/01/91)
dirk@laplace (dirksen bussiere) writes: >Around two years ago in SCIENTIFIC AMERICAN there was an article on a >programming "game" known as CORE WARS. The object seemed to be the creation of >sentient programs that went around trying to trash one another. Has anyone >heard of this "game"? If so, do you know where I can get ahold of the rules >and the programs used to create the "programming environment". My E-mail >address is DIRK%HHVMS8@VENUS.YCC.YALE.EDU . Thank a lot. > -Dirk Bussiere Your E-mail address doesn't work!! In february someone posted an article about COREWARS. I stored it and for Dirk and other people interested, here it is: -----------------------------oOo---------------------------------- Foreword: In a Core War battle two programs written in the pseudo-assembly language REDCODE are run against each other on a simulation enviroment called MARS (Memory Array Redcode Simulator). The aim of each program is to bomb its opponent. Obviously the Warrior that survives and kills its foe first is the winner. The thrill of the game is, that many possible strategies such as defensive, self-repairing, small-but-quick and others can be programmed and of course it's great fun to compare your own warriors with those of your friends! Disclaimer: Core War is not in the slightest way viruslike! The Core War Standards '88 Proposed by The International Core War Society July 30, 1990 (Draft) From the Redcode programmer's point of view, MARS is composed of four primary units: a read/write memory (RAM), a computing unit (ALU), two process cues (FIFO's), and the control unit (CU). There are no registers visible to the programmer; that is, memory is the only storage available for both instructions and data. RAM: All Redcode instructions occupy exactly one memory location. Adressing in Redcode is relative, so it is best to think of memory as being composed as a circular list; an instructions that references memory adress zero is referring to itself. Every RAM location is initialised to the data pattern which corresponds to the instruction 'DAT 0 0' before loading any Core War Programs (elsewhere referred to as "warriors"). FIFO: A game of Core War is played by pitting two Redcode programs against eachother. Each attempts to force the other to fail by causing it to execute a "halt" instruction, (the DAT). During each machine cycle one instruction from each program is executed, always in the same order. It is thus necessary to maintain a program counter for each side. This is the purpose of the process queues. As will be seen, each side may consist of more than one process. This is why a FIFO and not a single register is necessary for each side. There are no upper or lower limits to the size of the FIFO's, save the minimum of one each, as battles cannot occur with less than two Core War programs. ALU: The computing unit performs all the arithmetic and logical operations required by the Redcode instruction set, and the Control Unit, such as adding two operands or incrementing a program counter. CU: As in any processor, the control unit has the responsibility of fetching, decoding and executing instructions. The control unit must also provide an interface to the MARS supervisor function (ZEUS). The supervisor may provide various support functions such as a Redcode debugger, graphics display, parameter control, etc., and is highly implementation specific. Instruction Format: A Redcode instruction has three fields: the opcode field and two operand fields, denoted as A and B. the contents of the opcode field specify the operation to be performed, and the adressing modes to be used in evaluating the operands. The operand fields may contain any number from zero to the memory size minus one. Currently, eleven Redcode instructions are defined. They are listed below, with a mnemonic and a short description for each. DAT A B : remove executing process from process queue MOV A B : move A to B ADD A B : add A to B SUB A B : subtract A from B JMP A B : jump to A JMZ A B : jump to A if B is zero JMN A B : jump to A if B is not zero CMP A B : if A equals B then skip the next instruction SLT A B : if A is less than B then skip next instruction DJN A B : decrement B; if B is not zero then jump to A SPL A B : place A in the process queue Adressing Modes: There are currently four adressing modes defined: immediate, direct, indirect, and predecrement-indirect. The default mode is direct. If no modifier symbol precedes an operand, the value of the operand is used as an offset from the memory location from which it was fetched. The resulting memory location is the source and/or destination of the data to be used by the instruction, or else is the destination for branching instructions. An octothorpe (#) is used to introduce an immediate operand. The commemcial at sign (@) is used to introduce an indirect operand. The value of the operand is used as an offset, as it is with direct adressing. The B operand of the resulting memory adress is then used as an offset from the memory location from which it was fetched. The less than sign (<) is used to introduce a predecrement indirect operand. The action is the same as with @ with the difference that the specified memory location is first decremented and then afterwards used as a pointer. All theory is grey, here are some REDCODE examples: (Mostly 8000 or 8192 is used as Core size and 20000-30000 as instruction maximum) ; Warrior Gnom l: MOV p @p ADD #4 p JMP l p: DAT p ; Warrior KISS l: MOV b1 <p MOV b2 <p JMN l p MOV #-16 p z: MOV k <p JMN z p MOV #-16 p JMP l b1: JMP -1 b2: SPL 0 k: DAT #0 p: DAT #-16 ; Warrior PLAGUE SPL k SPL k l: ADD #24 p JMZ l @p MOV b @p MOV a <p ADD #1 p JMP l DAT #1 DAT #2 DAT #3 DAT #4 p: DAT #5 k: MOV z <z JMP k z: DAT #-16 b: JMP -1 a: SPL 0 -------------------------------oOo----------------------------- ``````````````````````````````````````''''''''''''''''''''''''''''''''''''''''' Kell S|nnichsen Computer Science Dept. Aaboulevarden 59, 2. th. University of Aarhus. DK-8000 Aarhus C. Denmark eMail: kells@daimi.aau.dk tlf.: 86 13 33 34 Problems: 1) Things will never get back to normal. 2) They already have... ``````````````````````````````````````'''''''''''''''''''''''''''''''''''''''''
tczarnik@cup.portal.com (Tom A Czarnik) (06/02/91)
I have an address, but the International Core War Society may have
moved.
Attn: William Buckley
5712 Kern Drive
Huntington Beach, CA 92649-4535
From the reference source I have:
Does the concept of worms and viruses fascinate you? There is a society
of computer programmers just like you called the International Core Wars
Society (ICWS). They pit their programming skills in a game called Core
Wars. CW is an outgrowth of a game called "Darwin" originally developed
in AT&T Bell Labs.
CW works something like this: Two competitors write their own "warrior"
programs. These programs are loaded into a computer arena, or CW Coliseum.
The computer starts the game by equally dividing computer time between
the two competitors.The two programs then compete for more computer time.
A winner is declared when one program forces the computer to allot all of
its time to that program. The other competitor is then "dead".
In this anything-goes format, the software can reproduce, grab memory,
overwrite the other program or do just about anything it can to force the
other competitor out. These characteristics have direct analogies to worm
and virus programs.
Does this sound like a childish game? Both the Soviet Academy of Science
and the Central Intelligence Agency don't think so; they are two in a long
and distinguished list of members. Annual competions are held that pit the
skills of some of the best programmers in the world
BTW: Bill Buckley is an expert on worms and viruses. He wrote the first worm
in 1985. And continues to write them for their educational value.
Tom Czarnik
tczarnik@cup.portal.comasylvain@felix.UUCP (Alvin "the Chipmunk" Sylvain) (06/06/91)
Written in article <1991May29.150606.25121@cs.yale.edu>
by dirk@laplace (dirksen bussiere):
> Around two years ago in SCIENTIFIC AMERICAN there was an article on a
> programming "game" known as CORE WARS. The object seemed to be the creation of
> sentient programs that went around trying to trash one another. Has anyone
> heard of this "game"? If so, do you know where I can get ahold of the rules
> and the programs used to create the "programming environment". My E-mail
> address is DIRK%HHVMS8@VENUS.YCC.YALE.EDU . Thank a lot.
Heard of it, yes. If no one else can help you, you can look up the
article in a library somewhere. Get help from the Librarian if you have
to. I wouldn't go so far as to call these programs "sentient," tho.
Some of the most effective ones proved to be the simplest, if I remember
the article correctly.
I also wouldn't quote "game," because that's precisely what it is. It
is not, as some would have you believe, the precursor to "viruses."
First off, the code is written in a pseudo-code, so real damage to the
machine or it's software is impossible. This is natural, because how
else do you determine the winner? Secondly, the game is played between
multiple players. They write the software in the pseudo-code and load
it in the machine. The player's who's entry grabs up the most core is
the winner. Therefore, it's definately a game.
There are other versions available. I know of one call "P-bots" or
something like that, where the players program the "robots" to destroy
each other in a software simulation. The code for the "robots" is
similar to Pascal. If you want to know where you can buy this, let
me know.
--
Alvin ===== asylvain@felix.UUCP ===== hplabs!felix!asylvain =====
"hplabs!felix!asylvain"@uunet.uu.net
(I always try to respond to mail, if possible. If you don't hear back
from me, try changing "hplabs" to "ccicpg," "spsd," or "lawnet.")
DISCLAIMER: It's all in fun, folks, no flames intended. Any similarity
between my opinion and that of my employer is purely coincidental and
sufficient reason to change my opinion, although I'll still be right.