Subject: what are "Core Wars"...
From: osan@cbnewsb.cb.att.com (Mr. X)
Organization: Twilight Zone
Date: 11 Nov 91 19:41:05 GMT
Message-ID: <1991Nov11.194105.7710@cbfsb.att.com>


>From a posting of last February...

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




   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.


*****************  End of Feb post *********************


Well that's about it.

	-X

	This is your CPU,
	This is your CPU on Core Wars,
	Any questions?



Subject: What the heck corewars IS. (long) (was: is anyone out there?)
From: hunky@matt.ksu.ksu.edu (Dudley...Suave')
Organization: Kansas State University
Date: 12 Nov 91 07:52:59 GMT
Message-ID: <khv22rINNnrt@matt.ksu.ksu.edu>

felixc@cbnewsj.cb.att.com (felix.cabral) writes:

>Yep I got it. I just subscribd to check it out. I guess the first thing
>that should be posted is an answer to "What the heck is corewars"?!?

>If its good I'll bite! :-):-)

ooOO! ooOO! I know!

From: _Scientific_American_, May 1984. pg 14.
--------------------------------------------------------------------------
"Computer Recreations"
	- In the game called Core Ware hostile programs engage in a battle 
	  of bits
by A. K. Dewdney

	Two computer programs in their native habitat -- the memory chips
of a digital computer -- stalk each other from address to address.
Sometimes they go scouting for the enemy; sometimes they lay down a
barrage of numeric bombs; sometimes they copy themselves out of danger or
stop to repair damage. It is unlike almost all other computer games in
that people do not play at all!  The contending programs are written by
people, of course, but once a battle is under way the creator of a
program can do nothing but watch helplessly as the product of hours spent
in design and implementation either lives or dies on the screen. The
outcome depends entirely on which program is hit first in a vulnerable
area.

[...skipping history of where the name, Core War, comes from...]

[...skipping explanation of what machine language is...]

	Comparatively little programming is done in assembly languages
because the resulting programs are longer and harder to understand or
modify than their high-level counterparts.  There are some tasks, however,
for which an assembly language is ideal.  When a program must occupy as
little space as possible or be made to run as fast as possible, it is
generally written in assembly language.  Furthermore, some things can be
done in an assembly language that are all but impossible in a high-level
language.  For example, an assembly-language program can be made to modify
its own instructions or to move itself to a new position in memory.

[...skipping story of a self-duplicating program (much like a virus)
that spread through a closed network and was eventually erradicated by
another self-duplicating program (which destroyed itself in the end)...]

	I set up an initial version of Core War and, assisted by David
Jones, a student in my department at the University of Western Ontario,
got it working.  Since then we have developed the game to a fairly
interesting level.

	Core War has four main componenets:  a memory array of 8,000
addresses, the assembly language Redcode, an executive program called MARS
(an acronym for Memory Array Redcode Simulator) and the set of contending
battle programs.  Two battle programs are entered into the memory array at
randomly chosen position; neither program knows where the other one is.
MARS executes the programs in a simple version of time-sharing, a
technique for allocating the resources of a computer among numerous users
The two programs take turns: a single instruction of the first program is
executed, then a single instruction of the second, and so on.

	What a battle program does during the execution cycles alloted to
it is entirely up to the programmer.  The aim, of course, is to destroy
the other program by ruining its instructions.  A defensive strategy is
also possible:  a program might undertake to repair any damage it has
received or to move out of the way when it comes under attack.  The battle
ends when MARS comes to an instruction in one of the programs that cannot
be executed.  The program with the faulty instruction -- which presumably
is a casualty of war -- is declared the loser.

[...Dewdney goes into greater detail of the workings of Core War over the
remainder of the article...]
--------------------------------------------------------------------------

So the article is 7 years old...There's an address where you can request
the guidelines for setting up your own Core War battlefield, but I would
not imagine that it would be as reliable as other various Core War sources
that exist currently (none of which I have addresses or info handy).

The size of the array (core) is insignificant. Obviously the larger arrays
provide more room to play with and likewise tend to be a bit more
involved :)

I haven't kept up with Core War lately and am glad to see this group
started. To get those who are unfamiliar with how a typical battle might
go, it might be nice to see some of the first posts concentrating on some
general battle strategies and scenarios. I myself would like to direct
some questions to those who are up on the current state of corewars, like:

	- What simulators are out there and for what type of machines?
	- Are there any conventions that seem to be generally accepted?
	  (along the lines of Core War terminology and the simulators)

-- 
!!! Use ELECTRONIC MAIL, and give the finger to the U.S. Postmaster General !!!



Subject: Corewar Code
From: steveh@devildog.att.com (Steve Hendershott)
Organization: AT&T IMS - Piscataway, NJ (USA)
Date: Mon, 11 Nov 1991 14:46:38 GMT
Message-ID: <1991Nov11.144638.13878@devildog.att.com>

I was hooked on corewars for a year or two when the Scientific American
article came out in 1984 (I think that's when). I implemented a version
on a UNIVAC 1100 and got a few co-workers to write some programs to fight
it out. We started out with examples like "imp" and moved on to some 
fancier fighters. It died out I think because I had not used a graphical
display for the output. Of course we had no graphical output to use in
those days. All we did was start it with two programs and wait a few
seconds to find out who won. We had trace and dump routines to follow
the thread of the logic, but it wasn't quite enough. I know that alot
has been done since then and I haven't followed it. I look forward to
hearing about any new improvements in the game. I would probably put it
up on my 386 if there is code available.

Steve Hendershott
steveh@devildog.att.com
-- 
Stephen W. Hendershott
steveh@devildog.att.com



Subject: Re: Found COREWAR, and a question
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: Wed, 13 Nov 1991 08:19:48 GMT
Message-ID: <91317.02:20:08.761164.DURHAM@ricevm1.rice.edu>

> Also, there are two programs called probots and crobots in
> which you program robots in pascal and c respectively, and
> let them fight it out against other robots.
> What would be the proper newsgroup to discuss these two programs?

Discussion of Robots and other games for programmers belongs HERE
until such time as they have their own newsgroups or a more general
recreational programming newsgroup is established.

Also, AI, Artificial Life, and automata discussions are all welcome
here and/or as cross postings.  Core War is a very diverse game!
MAD



Subject: MAD FAQs
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: Wed, 13 Nov 1991 08:41:27 GMT
Message-ID: <91317.02:41:27.843718.DURHAM@ricevm1.rice.edu>

TABLE OF CONTENTS
-----------------

1. What are MAD FAQs?

2. Who is Mark A. Durham?  What does he have to do with Core War?

3. What is Core War?

4. Is it Core War or Core Wars?

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

6. What is the ICWS?

7. What is TCWN?

8. How do I join?

9. Are back issues of TCWNs available?

10. What is the EBS?

11. Where is the Core War archive?

12. Where can I find a Core War system for . . . ?

13. When is the next tournament?

14. What is Core War notation?

15. Is there a Core War directory?

16. Can I help?

17. Other questions?

---------------------------------------------------------------------

Q1: What are "MAD FAQs"?
A1: MAD FAQs are those Frequently Asked Questions about Core War
which I (Mark A. Durham) maintain and am able to answer to some
extent.  If you have a particular concern or question not addressed
by this posting, please ask me

   Mark A. Durham
   P.O. Box 301173
   Houston, TX 77230-1173
   BITNET:     DURHAM@RICEVM1
   INTERNET:   DURHAM@RICEVM1.RICE.EDU

and I will try to help you as much as possible.

-----------------------------------------------------------------------

Q2: Who is Mark A. Durham and what does he have to do with Core War?
A2: I have been involved with Core War since it first appeared in
A. K. Dewdney's "Computer Recreations" article in the May 1984 issue
of Scientfic American.  I helped to formulate both ICWS (see below)
standards.  I have written numerous articles for "The Core War
Newsletter" (also, see below), and I currently serve as editor of the
newsletter.  Lately, I have been organizing the Electronic Branch
Section of the ICWS (see below, of course) which sponsored the
creation of rec.games.corewar.  If you have a Core War question or
problem, I am usually your best first contact.

----------------------------------------------------------------------

Q3: What is Core War?
A3: 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 of the opposing programs to
terminate, leaving your program in sole possesion 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.

----------------------------------------------------------------------

Q4: Is it "Core War" or "Core Wars"?
A4: Both terms are used.  Early references were to Core War.  Later
references seem to use Core Wars.  I prefer "Core War" to refer to
the game in general, "core wars" to refer to more than one specific
battle.

----------------------------------------------------------------------

Q5: Where can I find more information about Core War?
A5: 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 an anthology:

Author: Dewdney, A. K.
Title: The Armchair Universe: An Exploration of Computer Worlds
Published: New York: W. H. Freeman (c) 1988
Library of Congress Call Number: QA76.6 .D517 1988

---------------------------------------------------------------------

Q6: What is the ICWS?
A6: About one year after Core War first appeared in Sci-Am, the
"International Core War Society" (ICWS) was established.  Since that
time, the ICWS has been responsible for the creation and maintenance
of Core War standards and the running of Core War tournaments.  There
have been five annual tournaments and two standards (ICWS'86 and
ICWS'88).  The ICWS is currently in a state of flux, but should
stabilize soon.

---------------------------------------------------------------------

Q7: What is TCWN?
A7: Since March of 1987, "The Core War Newsletter" (TCWN) has been the
official newsletter of the ICWS.  It is supposed to be published quarterly,
but has appeared sporadically instead.  This should change soon as TCWN
is changing publishers.  In fact, it may be available through this
newsgroup in the near future.

---------------------------------------------------------------------

Q8: How do I join?
A8: For more information about joining the ICWS and/or subscribing to TCWN,
contact:

   Jon Newman
   12901 NE 78th Place
   Kirkland, WA 98033
   EMail: jonn@microsoft.com

The ICWS and TCWN are in a transitional period (as of November 1991).
Please be patient with them.

If you wish to contribute an article, cartoon, letter, joke, rumor, etc.
to TCWN, please send it to me and clearly indicate its destination.
My addresses are at the beginning of this posting.

----------------------------------------------------------------------

Q9: Are back issues of TCWN available?
A9: Arrangements are being made to make TCWN back issues available.  This
will probably involve a $4.00(US) fee to be sent to the Copyright Clearance
Center as well as an additional postage and handling charge.  Check out
the synopses available on another posting.

---------------------------------------------------------------------

Q10: What is the EBS?
A10: The Electronic Branch Section (EBS) of the ICWS is a group of
Core War enthusiasts with access to electronic mail.  There are no fees
associated with being a member of the EBS, and members do reap some of
the benefits of full ICWS membership without the expense.  For instance,
the ten best warriors submitted to the EBS tournament will be entered
into the annual ICWS tournament.  Now that rec.games.corewar has been
created, the EBS will move most of its business to the newsgroup.

The current goal of the EBS is to be at the forefront of Core War by
writing and implementing new standards and test suites in preparation for
the tenth anniversary of Core War in May of 1994.  Its immediate business
will be to set up a Charter and establish its officers.

If you wish to be placed on the EBS mailing list, send your EMail
address to me (my address is at the beginning of this posting).  The
EBS mail will mostly consist of synopses of newsgroup postings.

----------------------------------------------------------------------

A11: Where is the Core War archive?
Q11: Many documents such as the guidelines and the ICWS standards
along with previous tournament Redcode entries and complete Core War
systems are available via anonymous ftp from soda.berkeley.edu in the
pub/corewar directories.

----------------------------------------------------------------------

Q12: Where can I find a Core War system for . . . ?
A12: First, check out the Core War systems available via anonymous ftp
from soda.berkeley.edu.  Currently, there is an X-Window Core War system
available there.  Others should start appearing soon.  The following
suppliers have ICWS'88 compatible systems for

IBM PC compatibles:
   The Core War Colosseum
   AMRAN
   5712 Kern Drive
   Huntington Beach, CA 92649-4535
   Price: $39.95

   CoreMaster(TM)
   THINK Software
   524 Paige Drive
   Birmingham, AL 35226
   (205)979-9475
   Price: $34.95 + $3.00 S&H

Apple Macintosh computers:
   Core!
   Jon Newman
   12901 NE 78th Place
   Kirkland, WA 98033
   EMail: jonn@microsoft.com (Note: Core! is NOT a Microsoft product.)
   Price: $14.00 registration fee, plus $3.00 S&H.  S&H fee waived
            if you send 800k disk and stamped, self-addressed envelope.

Commodore Amiga computers:
   The MADgic Core
   P.O. Box 301173
   Houston, TX 77230-1173
   EMail: durham@ricevm1.rice.edu
   Price: $40.00 for complete system, or we can work something out.

   CoreWars (German language version)
   UNICORN systems
   Bernstrasse 67
   CH-4852 Rothrist
   Switzerland
   Price: sFr 45.--

Commodore 64/128 computers:
   Barry Cohen
   65 West 90th Street, #23E
   New York, NY 10024
   Price: Not Available

My apologies to those of you who have Core War systems which are not
listed here or are incorrectly listed here.  Please send me information
about the systems (base system, ICWS standards compatibility, extensions,
price, etc.) and I will be sure to include it in next months MAD FAQs.

CAUTION!  There are many, many Core War systems available which are NOT
ICWS'88 (or even ICWS'86) compatible available at various archive sites.
If you have questions about compatibility, please feel free to ask me.

Reviews of Core War systems would be greatly appreciated in the newsgroup
and in the newsletter.  Please post or EMail to me any review of any
Core War system you have tried out so that others may learn from your
experience.

----------------------------------------------------------------------

Q13: When is the next tournament?
A13: The EBS will be having a preliminary tournament November 15th.  The
ICWS may hold its annual tournament December 15th.  Send warriors to
durham@ricevm1.rice.edu before November 15th for inclusion in the EBS
tournament.  Remember, the top ten finishers of the EBS tournament will
be automatically sent to the annual ICWS tournament.

The EBS will hold a tournament for its own sake sometime in late winter
or early spring.  Make your tournament date preferences known now!

----------------------------------------------------------------------

Q14: What is Core War notation?
A14: There are some important notational conventions which should be
followed when writing about Core War.  Before we discuss them, you
need to understand Redcode syntax.

Redcode consists of assembly language instructions of the form

   <label>   <opcode> <A-mode><A-field>, <B-mode><B-field> ; <comment>

The <label> is optional.  <opcode> is DAT, MOV, ADD, SUB, JMP, JMZ,
JMN, DJN, CMP, SLT, SPL, SPACE (obsolete), or END.  <A/B-mode>
indicators are $ (obsolete), #, @, or <.  A missing <mode> indicator is
considered the same as $.  <A/B-field>s are integers or expressions.
A missing <mode><field> and comma is considered the same as #0.
Which field is considered missing depends on the opcode.
The "; <comment>" is optional and can appear on a line by itself.

When discussing Redcode, one often wants to talk about whole families
of instructions.  Example:

   ??? A, B

describes all possible Redcode statements.  The "???" indicates any
opcode, the capital A indicates any combination of A-mode and A-field,
and similarly for B.  "???" is rarely used.  Most people just put in
any arbitrary opcode, usually MOV.

The capitalization of A and B is important!!!

   MOV A, B
and
   MOV a, B

mean two different things.  MOV A, B means the family { MOV $a, B;
MOV #a, B; MOV @a, B; and MOV <a, B} whereas MOV a, B means the same
thing as MOV $a, B.  Capital 'A' indicates any combination of A-mode and
A-field.  Lowercase 'a' stands for the A-field only.  Similarly for
capital 'B' and lowercase 'b'.

When discussing running code in situ, indicate the cycle with

   T = cycle

at the top.  Indicate the currently executing statement with the number
of the program followed by "-->" if on the left of the code or "<--"
followed by the number of the program if on the right of the code.  The
instruction(s) which will execute next for the opposing player(s) should
be labelled with the pointer only.  Examples:

   T = 0

        MOV  0,  1   <--
   1--> MOV #0, -1
        JMP -1
............................
   T = 0.5

        MOV  0,  0   <--2
        MOV #0, -1
    --> JMP -1


A Note About Commas:  Some systems do not accept or insist on commas
in between operands.  It is a good idea to insist on commas between
operands however to distinguish

   DAT 0 - 1
as either
   DAT 0, -1
or
   DAT (0-1)   ;  Same as DAT -1

----------------------------------------------------------------------

Q15: Is there a Core War directory?
A15: We are trying to establish a directory of Core War enthusiasts to
be placed at the Core War archive site.  If you wish for other Core War
enthusiasts to be able to contact you, send your name and any other
information you would like listed to me.

----------------------------------------------------------------------

Q16: Can I help?
A16: You most certainly can.  As you may be able to tell, I am currently
doing much of this work myself.  I would be more than happy to let you
handle one or more of the above duties.  Just tell me what you would
like to do.

----------------------------------------------------------------------

Q17: Other questions?
A17: Ask me.  At the above addresses or in this newsgroup.  I will do my
best to answer it, or get you in contact with someone else who can.

Mark A. Durham
MAD



Subject: PROTECT instruction can foil single imp.
From: mjd@saul.cis.upenn.edu (Last of the Giants)
Organization: Eaters of Wisdom
Date: 13 Nov 91 17:52:08 GMT
Message-ID: <MJD.91Nov13125208@saul.cis.upenn.edu>


    Some versions of redcode support a PCT (`protect') instruction which
write-protects a certain memory address; an attempt to write to a
protected address will remove the protection but will not change the
contents.  A program can protect itself against single imps by placing a
garbage instruction just ahead of its code, and protecting the garbage
instruction.  When an imp tries to come through the garbage instruction,
its MOV 0,1 fails, its control passes to the garbage instruction, and it
dies.  Such an instruction is called a `roadblock'.  Note that a
roadblock won't stop two or more imps that are in the same place--the
first one will remove the protection, the second will write its MOV 0,1
instruction over the garbage, then the first one will continue executing
with MOV 0,1 as usual. 

    A friend of mine wrote a program that did the following:

	Make four roadblocks, equally spaces in memory.
	Make four MOV 0,1 instructions, each positioned just after a roadblock.
	Spin off four imps, one at each MOV 0,1 instruction.
	Terminate.

    The idea is this: The imps will chew their way through memory,
eventually running down any stationary program.  The most likely result
of this is that the enemy program will be subverted, turn into an imp
itself, speed away and crash into a roadblock.  The enemy program will
go faster than the four-imp team because four imps travel four times
slower than one imp.

    In practice, this didn't work very well, but it seems like the idea
has some merit and perhaps could be patched up.  Does anyone have any
good ideas?

--

   Nihil tam absurde dici potest, quod non dicatur ab aliquo philosophorum.
Mark-Jason Dominus 	  			    mjd@central.cis.upenn.edu 



Subject: RE: Archived Redcode
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: Thu, 14 Nov 1991 01:37:36 GMT
Message-ID: <91317.19:37:36.925508.DURHAM@ricevm1.rice.edu>

I should point out that the Redcode programs from old ICWS tournaments
available from soda.berkeley.edu (currently) all run under ICWS'86 -
the old standard - NOT ICWS'88 - the new standard.  Most ICWS-compatible
systems will support both standards, but the standards do have some
incompatible differences.  So you should run these programs in the
ICWS'86 mode.

We are trying to get Redcode from the last ICWS tournament onto the
archive site.  The last tournament was run under ICWS'88 rules and
therefore all of the code is ICWS'88 compatible.

I will post a summary of ICWS'86, ICWS'88, and the differences RSN.

In addition, we are trying to establish a "test suite" of Redcode
programs for validating Redcode systems.  I will post, and I encourage
those in-the-know to post, heavily documented, short example Redcode
programs which demonstrate ONE (1) feature of standard Redcode.

MAD



Subject: rec.games.corewar
From: cdixon@eagle.wesleyan.edu
Organization: Wesleyan University
Date: 14 Nov 91 04:52:14 GMT
Message-ID: <1991Nov13.235214.57852@eagle.wesleyan.edu>

For those of you interested in finding a CoreWars implementation for PCs
(or MS-DOS whatever) I wrote what I think is a pretty decent one.  I didn't
have the official specifications, instead I based the program on A.K. Dewdney's
articles (which sometimes contradicted each other when listing the Redcode
operations).  Here is a little run down of the features:
	o 256-color VGA mode (with optional crappy text mode)
 	o up to six battle programs simulataneously
	o supports everything in the official Redcode specification 
		(also has indirect addressing with increment)
	o allows labels to be used
	o has cool explosions
Anyways if anyone wants a copy I'd be happy to give them one, although I'm
not sure of the best way to get it to them (any suggestions?).

Also I have a CoreWars issue I'd like to mention:
	I found that the techinique of bombing with SPL 0 commands can be
very deadly (as I'm sure many of you know) but I think it may be so deadly
that it should be outlawed.  I wrote a battle program called NUKE which very 
quickly covers most of the screen with SPL 0's (disabling all enemies) and
then makes a second pass through memory with DAT 0's.  It beats every program
95% of the time (including MICE from A.K. Dewdney's article).  For me it kind
of ruined CoreWars since it seems to be the ultimate killing program.  The only
program which could even beat it would be one which does the same thing but
slightly more efficient.  Anyone have any solutions short of outlawing SPL 0?
(which would actually be futile since people could use SPL 1 followed by SPL -1
or something like that in its place).  What do they do about this problem in
the tournaments?

-Chris Dixon
Wesleyan University



Subject: IMP stomping
From: blojo@xcf.berkeley.edu (Jon Blow)
Organization: WINDOM BIFF FAN CLUB!!!!!!!!
Date: 14 Nov 91 06:05:51 GMT
Message-ID: <9apq28y98ha3ty98qh4ty98h2g@xcf>

This is a little discussion about how to build better IMP STOMPERs.  I would
suggest that one be basically familiar with the way Core War works (especially
the IMP STOMPER) before trying to deeply understand this.


The IMP instruction is, of course:

    MOV 0 1

This program is very simple; it is the canonical Redcode example.  The
following is the program usually displayed side-by-side with the IMP as
a way of combatting it:

;;; A very simple IMP STOMPER.
;;;

start   mov #0, -1
        jmp start


Even though this program is commonly heralded as THE IMP SOLUTION, note that
it only spends half its time shielding itself from IMPs; the other half of
the time, it is jumping.  That means that if the enemy is only executing one
process and that process is an imp, the IMP STOMPER will be destroyed 50% of
the time; this isn't so good.  I found this fact glossed over by the A.K.
Dewdney columns in _The Armchair Universe_.

The next program is an obvious step at a more effective stomper:

;;; SUPER IMP STOMPER

;;; Because an IMP STOMPER spends only half its time stomping (and the other
;;; half executing a JMP instruction), it has a good chance of being overrun
;;; by an assaulting IMP.  The more time we spend stomping, the better our
;;; chances are (as illustrated in the program below.)  We become much more
;;; vulnerable to bombs, though, due to size increase.

;;; See also: IMP STOMPER

stomp   dat #0
start   mov #0, stomp
        mov #0, stomp
        mov #0, stomp
        jmp start


This program will succeed 75% of the time versus a single imp; this is because
it spends 3 instructings writing zeroes to its head, and one jumping back to
continue the loop.  Generally, this program has a success rate of N/(N+1),
where N is the number of times we repeat the instruction "mov #0, stomp".

Note that the more stomping instructions we insert, however, the more
susceptible this program becomes to bombing.  As the success rate approaches
unity, this stomper becomes an infinitely large target.

By the engagement of a clever trick, we develop the following program:


;;; IMP HOSER
;;;
;;; A smarter IMP STOMPER.

target  dat     0
        dat     0
start   djn     start,  target
        jmp     start


This program uses the DJN ("Decrement and Jump if Nonzero") instruction.
We eliminate most of the problems we had with the earlier stompers because
of the simple fact that DJN alters a memory location and jumps during the
same cycle.
What happens when an IMP is passing through location 'target' and is hit
by this program?  The IMP is 'decremented', but what exactly does that mean?
An IMP instruction looks like this:

INST    A       B
----    -       -
MOV     0       1

DJN decrements the data field, which is, by definition, the number in column
B.  The imp is, therefore, instantly turned into "MOV 0 0".  The instruction
remains in the same place, and, next cycle, the IMP's program counter tries
to execute the next address after 'target': a DAT 0.  The IMP dies.

The fourth instruction, "jmp start", is there for the occasion when the
DJN decrements 'target' to 0.  When this happens, IMP HOSER wastes a
cycle jumping back up to 'start'.  This is obviously a vast improvement
over the SUPER IMP STOMPER; specifically, the success rate of IMP HOSER
is (N-1)/N, where N is the number of integers representable by the data
element of an instruction in your MARS system.

This is the most successful IMP-stomper-type program I have ever implemented.
I have never tested it, and, indeed, am a bit fuzzy on the rules, but I think
that the new Redcode standard allows one to create a "perfect" IMP STOMPER:

start: jmp start, <1

Might someone verify if this is so?



Subject: Re: SPL
From: blojo@xcf.berkeley.edu (Jon Blow)
Organization: WINDOM BIFF FAN CLUB!!!!!!!!
Date: 14 Nov 91 06:13:47 GMT
Message-ID: <10apq28y98ha3ty98qh4ty98h2g@xcf>

cdixon@eagle.wesleyan.edu writes:

>         I found that the techinique of bombing with SPL 0 commands can be
> very deadly (as I'm sure many of you know) but I think it may be so deadly
> that it should be outlawed....

It sounds like you're running this on a simulator that does not follow
ICWS '88 process initiation specifications.  '88 specifies that new streams
of execution created by SPL are placed at the end of the process queue and
take effect at the end of the *next* stream of execution.  This means that
a single SPL0 will only have the same effect as trapping a process without
it spawning; at the very least, one requires "SPL 0; JMP -1", and even this
is not all as effective as one might imagine.



Subject: Oops
From: blojo@xcf.berkeley.edu (Jon Blow)
Organization: WINDOM BIFF FAN CLUB!!!!!!!!
Date: 14 Nov 91 06:15:45 GMT
Message-ID: <ki454hINN1mc@agate.berkeley.edu>

In article <9apq28y98ha3ty98qh4ty98h2g@xcf>, I goofed and suggested that a perfect
IMP STOMPER would be:

>> start: jmp start, <1

The correct suggestion, of course, should have been:

start: jmp start, <-1




Subject: Re: Simulators/First Post
From: cpbeaure@descartes.waterloo.edu (Chris Beauregard)
Organization: University of Waterloo
Date: 14 Nov 91 17:12:33 GMT
Message-ID: <1991Nov14.171233.2557@descartes.waterloo.edu>

In article <1991Nov14.083703.8987@microsoft.com> w-ethanh@microsoft.com (Ethan HENRY) writes:
>I am curious as to what sort of simulators people out there
>use... especially with reference to the PC(only machine I have
>access to...)

  Anything with programming invoved.  Core Wars, Crobots, P-Robots, Omega, 
RoboWars (Mac) RobotWars (apple ][), they're all fun, and somewhat challenging.
  I mean, they beat the hell out of the old Eye-Hand coordination games, and 
they improve programming skills (I first learnt C structure playing CROBOTS) 

>Has anyone written their own simulator ??

  I've written a Core Wars system for the PC, and I've created my own games 
based on a lot of these things, using programmed drone aircraft, and a BASIC
like language (no line number though...rest assured, I'll never go back to line
numbers)  It's still in development though.  I'm probably going to rewrite it
in C++ when I get time (Christmas Vacation, say...)
  I'll probably be developing the thing for the next few years.  I mean, I'm
just starting university level study, so I expect I'll be picking up ideas to
improve it faster than I can actually do it.  I'm already behind in the ideas
area...
    
>And does anyone run CoreWars on a raw system ??? 
>If you have an old mainframe lying around, mabye it's worth a 
>try...

  We were kicking around the idea at the Waterloo Computer Science Club of
resurrecting our HP-xxxx system with something like that.  I think the 
executive nuked it though.  It would have been fun.

-------------------------------------------+-------------------------------+  
Chris Beauregard                           |Any ideas and/or opinions      |
cpbeaure@descartes.waterloo.edu            |expressed here are solely mine.|
"If you can't beat 'em, take 'em with ya!" +-------------------------------+



Subject: Re: Oops - Perfect Imp Stomper
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: Thu, 14 Nov 1991 09:21:34 GMT
Message-ID: <91318.03:21:44.480002.DURHAM@ricevm1.rice.edu>

>>The correct suggestion (for a perfect Imp stomper), of course,
>>should have been:
>>start: jmp start, <-1

Close, but not quite.  It is necessary to leave a DAT statement
between you and the Imp, otherwise you will have successfully kept
the Imp from overwriting you, but the Imp will now be running your
code.  Example:

T = 0
        MOV 0,   1   <--Opponent
x       ??? A,   B
    --> JMP 0, <-1
--------------------------------
T = 0.5
        MOV 0,   1
x       MOV 0,   1   <--
 You--> JMP 0, <-1
--------------------------------
T = 1
        MOV 0,   1
x       MOV 0,   0   <--Opponent
    --> JMP 0, <-1
--------------------------------
T = 1.5
        MOV 0,   1
x       MOV 0,   0
 You--> JMP 0, <-1   <--
--------------------------------

So now you and your opponent are both executing at x+1.
If you write instead

; Perfect Imp Stomper
        DAT #0,  #0
start   JMP  0, <-2

The Imp will fall into the DAT and die.



Subject: Intro to Redcode Part I
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: Thu, 14 Nov 1991 09:41:37 GMT
Message-ID: <91318.03:41:37.183033.DURHAM@ricevm1.rice.edu>

Introduction to Redcode
-----------------------

  I. Preface - Reader Beware!    { Part I }

 II. Notation                    { Part I }

III. MARS Peculiarities          { Part I }

 IV. Address Modes               { Part II }

  V. Instruction Set             { Part II }


----------------------------------------------------------------------


I. Preface - Reader Beware!

   The name "Core War" arguably can be claimed as public domain.
Thus, any program can pass itself off as an implementation of Core
War.  Ideally, one would like to write a Redcode program on one system
and know that it will run in exactly the same manner on every other
system.  Alas, this is not the case.
   Basically, Core War systems fall under one of four catagories:
Non-ICWS, ICWS'86, ICWS'88, or Extended.  Non-ICWS systems are usually
a variant of Core War as described by A. K. Dewdney in his "Computer
Recreations" articles appearing in Scientific American.  ICWS'86 and
ICWS'88 systems conform to the standards set out by the International
Core War Society in their standards of 1986 and 1988, respectively.
Extended systems generally support ICWS'86, ICWS'88, and proprietary
extensions to those standards.  I will discuss frequently common
extensions as if they were available on all Extended systems (which
they most certainly are not).
   I will not describe Non-ICWS systems in this article.  Most Non-
ICWS systems will be easily understood if you understand the systems
described in this article however.  Although called "standards",
ICWS'86 and ICWS'88 (to a lesser extent) both suffer from ambiguities
and extra-standard issues which I will try to address.
   This is where the reader should beware.  Because almost any
interpretation of the standard(s) is as valid as any other, I
naturally prefer MY interpretation.  I will try to point out other
common interpretations when ambiguities arise though, and I will
clearly indicate what is interpretation (mine or otherwise) as such.
You have been warned!


----------------------------------------------------------------------


II. Notation

   "86:" will indicate an ICWS'86 feature.  "88:" will indicate an
ICWS'88 feature.  "X:" will indicate an Extended feature.  "Durham:"
will indicate my biased interpretation.  "Other:" will indicate
interpretations adhered to by others.  "Commentary:" is me explaining
what I am doing and why.  "Editorial:" is me railing for or against
certain usages.  Items without colon-suffixed prefaces can be
considered universal.

   Redcode consists of assembly language instructions of the form

<label>   <opcode> <A-mode><A-field>, <B-mode><B-field>   <comment>

An example Recode program:

; Imp
; by A. K. Dewdney
;
imp     MOV imp, imp+1      ; This program copies itself ahead one
        END                 ; instruction and moves through memory.


The <label> is optional.
86: <label> begins in the first column, is one to eight characters
    long, beginning with an alphabetic character and consisting
    entirely of alphanumerals.  Case is ignored ("abc" is equivalent
    to "ABC").
88: <label> as above, except length is not limited and case is not
    addressed.  Only the first eight characters are considered
    significant.
X: <label> can be preceded by any amount of whitespace (spaces, tabs,
    and newlines), consists of any number of significant alphanumerals
    but must start with an alphabetic, and case is significant ("abc"
    is different from "ABC").
Commentary: I will always use lowercase letters for labels to
    distinguish labels from opcodes and family operands.

The <opcode> is separated from the <label> (if there is one) by
    whitespace.  Opcodes may be entered in either uppercase or
    lowercase.  The case does not alter the instruction.  DAT, MOV,
    ADD, SUB, JMP, JMZ, JMN, DJN, CMP, SPL, and END are acceptable
    opcodes.
86: SPACE is also recognized as an opcode.
88: SLT and EQU are recognized as opcodes.  SPACE is not.
X: All of the above are recognized as opcodes as well as XCH and PCT,
    plus countless other extensions.
Commentary: END, SPACE, and EQU are known as pseudo-ops because they
    really indicate instructions to the assembler and do not produce
    executable code.  I will always capitalize opcodes and pseudo-ops
    to distinguish them from labels and text.

The <A-mode> and <A-field> taken together are referred to as the
    A-operand.  Similarly, the <B-mode><B-field> combination is known
    as the B-operand.  The A-operand is optional for some opcodes.
    The B-operand is optional for some opcodes.  Only END can go
    without at least one operand.
86: Operands are separated by a comma.
88: Operands are separated by whitespace.
X: Operands are separated by whitespace and/or a comma.  Lack of a
    comma can lead to unexpected behaviour for ambiguous constructs.
Commentary: The '88 standard forces you to write an operand without
    whitespace, reserving whitespace to separate the operands.  I like
    whitespace in my expressions, therefore I prefer to separate my
    operands with a comma and will do so here for clarity.

<mode> is # (Immediate Addressing), @ (Indirect Addressing), or <
    (86: Auto-Decrement Indirect, 88: Pre-Decrement Indirect).  A
    missing mode indicates Direct Addressing.
86: $ is an acceptable mode, also indicating Direct Addressing.
88: $ is not an acceptable mode.
X: $ is an acceptable mode as in 86:.
Commentary: The distinction between Auto-Decrement Indirect Addressing
    and Pre-Decrement Indirect Addressing is semantic, not syntactic.

<field> is any combination of labels and integers separated by the
    arithmetic operators + (addition) and - (subtraction).
86: Parentheses are explicitly forbidden.  "*" is defined as a special
    label symbol meaning the current statement.
88: Arithmetic operators * (multiplication) and / (integer division)
    are added.  "*" is NOT allowed as a special label as in 86:.
X: Parentheses and whitespace are permitted in expressions.
Commentary: The use of "*" as meaning the current statement may be
    useful in some real assemblers, but is completely superfluous in a
    Redcode assembler.  The current statement can always be referred
    to as 0 in Redcode.

<comment> begins with a ; (semicolon), ends with a newline, and can
    have any number of intervening characters.  A comment may appear
    on a line by itself with no instruction preceding it.
88: Blank lines are explicitly allowed.


   I will often use "A" to mean any A-operand and "B" to mean any
B-operand (capitalization is important).  I use "a" to mean any  A-
field and "b" to mean any B-field.  For this reason, I never use "a"
or "b" as an actual label.
   I enclose sets of operands or instructions in curly braces.  Thus
"A" is equivalent to "{ a, #a, @a, <a }". I use "???" to mean any
opcode and "x" or "label" as an arbitrary label.  Thus, the complete
family of acceptable Redcode statements can be represented as

x    ??? A, B   ; This represents all possible Redcode statements.

"???" is rarely used as most often we wish to discuss the behaviour of
a specific opcode.  I will often use labels such as "x-1" (despite its
illegality) for the instruction before the instruction labelled "x",
for the logically obvious reason.  "M" always stands for the integer
with the same value as the MARS memory size.


----------------------------------------------------------------------


III. MARS Peculiarities

   There are two things about MARS which make Redcode different from
any other assembly language.  The first of these is that there are no
absolute addresses in MARS.  The second is that memory is circular.
   Because there are no absolute addresses, all Redcode is written
using relative addressing.  In relative addressing, all addresses are
interpreted as offsets from the currently executing instruction.
Address 0 is the currently executing instruction.  Address -1 was the
previously executed instruction (assuming no jumps or branches).
Address +1 is the next instruction to execute (again assuming no jumps
or branches).
   Because memory is circular, each instruction has an infinite number
of addresses.  Assuming a memory size of M, the current instruction
has the addresses { ..., -2M, -M, 0, M, 2M, ... }.  The previous
instruction is { ..., -1-2M, -1-M, -1, M-1, 2M-1, ... }.  The next
instruction is { ..., 1-2M, 1-M, 1, M+1, 2M+1, ... }.

Commentary: MARS systems have historically been made to operate on
   object code which takes advantage of this circularity by insisting
   that fields be normalized to positive integers between 0 and M-1,
   inclusive.  Since memory size is often not known at the time of
   assembly, a loader in the MARS system (which does know the memory
   size) takes care of field normalization in addition to its normal
   operations of code placement and task pointer initialization.

Commentary: Redcode programmers often want to know what the memory
    size of the MARS is ahead of time.  This is not always possible.
    Since normalized fields can only represent integers between 0 and
    M-1 inclusive, we can not represent M in a normalized field.  The
    next best thing?  M-1.  But how can we write M-1 when we do not
    know the memory size?  Recall from above that -1 is equivalent to
    M-1.  Final word of caution: -1/2 is assembled as 0 (not as M/2)
    since the expression is evaluated within the assembler as -0.5 and
    then truncated.

86: Only two assembled-Redcode programs (warriors) are loaded into
    MARS memory (core).
88: Core is initialized to (filled with) DAT 0, 0 before loading any
    warriors.  Any number of warriors may be loaded into core.

Commentary: Tournaments almost always pit warrior versus warrior with
    only two warriors in core.

   MARS is a multi-tasking system.  Warriors start as just one task,
but can "split" off additional tasks.  When all of a warriors tasks
have been killed, the warrior is declared dead.  When there is a sole
warrior still executing in core, that warrior is declared the winner.
86: Tasks are limited to a maximum of 64 for each warrior.
88: The task limit is not set by the standard.


----------------------------------------------------------------------



Subject: Intro to Redcode Part II
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: Thu, 14 Nov 1991 09:45:13 GMT
Message-ID: <91318.03:45:13.729002.DURHAM@ricevm1.rice.edu>

IV. Address Modes

   Addressing modes subtly (sometimes not-so-subtly) alter the
behaviour of instructions.  A somewhat brief description of their
general properties is given here.  Specifics will be left to the
instruction set section.
   An octothorpe (#) is used to indicate an operand with an Immediate
Address Mode.  Immediate mode data is contained in the current
instruction's field.  If the A-mode is immediate, the data is in the
A-field.  If the B-mode is immediate, the data is in the B-field.
   If no mode indicator is present (86: or the US dollar sign '$' is
present), Direct Address Mode is used.  Direct addresses refer to
instructions relative to the current instruction.  Address 0 refers to
the current instruction.  Direct address -1 refers to the (physically)
previous instruction.  Direct address +1 refers to the (physically)
next instruction.
   The commercial-at (@) is used to indicate Indirect Address Mode.
In indirect addressing, the indirect address points to an instruction
as in direct addressing, except the target is not the instruction to
which the indirect address points but rather the instruction pointed
to by the B-field of the instruct pointed to by the indirect address.
Example:

x-2     DAT  #0,  #0   ; Target instruction.
x-1     DAT  #0, #-1   ; Pointer instruction.
x       MOV   0, @-1   ; Copies this instruction to location x-2.

   The less-than (<) is used to indicate (86: Auto-, 88: Pre-)
Decrement Indirect Address Mode.  Its behaviour is just like that of
Indirect Address Mode, except the pointer is decremented before use.
Example:

x-2     DAT  #0,  #0   ; Target instruction
x-1     DAT  #0,  #0   ; Pointer instruction.  Compare to @ example.
x       MOV   0, <-1   ; Copies this instruction to location x-2.


Commentary: Although Decrement Indirect addressing appears to be a
    simple extension of Indirect addressing, it is really very tricky
    at times - especially when combined with DJN.  There are sematic
    differences between the '86 and '88 standards, thus the change in
    name from Auto-Decrement to Pre-Decrement.  These differences are
    discussed below.  This discussion is non-essential for the average
    Redcode programmer.  I suggesting skipping to the next section for
    the weak-stomached.

86: Durham: Instructions are fetched from memory into an instruction
    register.  Each operand is evaluated, storing a location (into an
    address register) and an instruction (into a value register) for
    each operand.  After the operands have been evaluated, the
    instruction is executed.
   Operand Evaluation: If the mode is immediate, the address register
    is loaded with 0 (the current instruction's address) and the value
    register is loaded with the current instruction.  If the mode is
    direct, the address register is loaded with the field value and
    the value register is loaded with the instruction pointed to by
    the address register.  If the mode is indirect, the address
    register is loaded with the sum of the field value and the B-field
    value of the instruction pointed to by the field value and the
    value register is loaded with the instruction pointed to by the
    address register.  If the mode is auto-decrement, the address
    register is loaded with a value one less than the sum of the field
    value and the B-field value of the instruction pointed to by the
    field value and the value register is loaded with the instruction
    pointed to by the address register.  AFTER the operands have been
    evaluated (but before instruction execution), if either mode was
    auto-decrement, the appropriate memory location is decremented.
    If both modes were auto-decrement and both fields pointed to the
    same pointer, that memory location is decremented twice.  Note
    that this instruction in memory then points to a different
    instruction than either operand and also differs from any copies
    of it in registers.
86: Other: As above, except there are no registers.  Everything is
    done in memory.
Commentary: ICWS'86 clearly states the use of an instruction register,
    but the other operand address and value registers are only
    implied.  Ambiguities and lack of strong statements delineating
    what takes place in memory and what takes place in registers
    condemned ICWS'86 to eternal confusion and gave birth to ICWS'88.
88: As above except everything is done in memory and Pre-Decrement
    Indirect replaces Auto-Decrement Indirect.  Pre-Decrement Indirect
    decrements memory as it is evaluating the operands rather than
    after.  It evaluates operand A before evaluating operand B.


----------------------------------------------------------------------


V. Instruction Set

DAT A, B
   The DAT (data) instruction serves two purposes.  First, it allows
you to store data for use as pointers, offsets, etc.  Second, any task
which executes a DAT instruction is removed from the task queue.  When
all of warrior's tasks have been removed from the queue, that warrior
has lost.
86: DAT allows only one operand - the B-operand.  The A-field is left
    undefined (the example shows #0), but comparisons of DAT
    instructions with identical B-operands must yield equality.
88: DAT allows two operands but only two modes - immediate and
    pre-decrement.
X: DAT takes one or two operands and accepts all modes.  If only one
    operand is present, that operand is considered to be the B-operand
    and the A-operand defaults to #0.
Commentary: It is important to note that any decrement(s) WILL occur
    before the task is removed from the queue since the instruction
    executes only after the operand evaluation.

MOV A, B
   The MOV (move) instruction either copies a field value (if either
mode is immediate) or an entire instruction (if neither mode is
immediate) to another location in core (from A to B).
86: Durham: MOV #a, #b changes itself to MOV #a, #a.
Commentary: There is a clear typographical error in ICWS'86 which
    changes the interpretation of MOV #a, B to something non-sensical.
    For those with a copy of ICWS'86, delete the term "B-field" from
    the next-to-last line of the second column on page 4.
88: No immediate B-modes are allowed.
X: Immediate B-modes are allowed and have the same effect as a
    B-operand of 0.  (See 86: Durham: above).

ADD A, B
86: The ADD instruction adds the value at the A-location to the value
    at the B-location, replacing the B-location's old contents.
88: If the A-mode is immediate, ADD is interpreted as above.  If the
    A-mode is not immediate, both the A-field and the B-field of the
    instruction pointed to by the A-operand are added to the A-field
    and B-field of the instruction pointed to by the B-operand,
    respectively.  The B-mode can not be immediate.
X: Immediate B-modes are allowed and have the same effect as in 86:.
    Example: ADD #2, #3 becomes ADD #2, #5 when executed once.

SUB A, B
   The SUB (subtract) instruction is interpreted as above for all
three cases, except A is subtracted from B.

JMP A, B
   The JMP (jump) instruction changes the instruction pointer to point
to the instruction pointed to by the A-operand.
86: JMP allows only one operand - the A-operand.  The B-operand is
    shown as #0.
88: JMP allows both operands, but the A-mode can not be immediate.
X: JMP allows both operands and the A-mode can be immediate.  An
    immediate A-mode operand is treated just like JMP 0, B when
    executed.

JMZ A, B
   The JMZ (jump if zero) instruction jumps to the instruction pointed
to by the A-operand only if the B-field of the instruction pointed to
by the B-operand is zero.
88: Immediate A-modes are not allowed.

JMN A, B
   The JMN (jump if non-zero) instruction jumps to the instruction
pointed to by the A-operand only if the B-field of the instruction
pointed to by the B-operand is non-zero.
88: Immediate A-modes are not allowed.

DJN A, B
   The DJN (decrement and jump if non-zero) instruction causes the
B-field of the instruction pointed to by the B-operand to be
decremented.  If the decremented values is non-zero, a jump to the
instruction pointed to by the A-operand is taken.
88: Immediate A-modes are not allowed.

CMP A, B
   The CMP (compare, skip if equal) instruction compares two fields
(if either mode is immediate) or two entire instructions (if neither
mode is immediate) and skips the next instruction if the two are
equivalent.
Commentary: There is a clear typographical error in ICWS'86 which
    changes the interpretation of CMP #a, B to something non-sensical.
    For those with a copy of ICWS'86, delete the term "B-field" from
    the fifth line from the bottom of the second column on page 5.
    Also, the comments to the example on page 6 have been switched
    (equal is not equal and vice versa).  The labels are correct
    though.
88: Immediate B-modes are not allowed.

SPL A, B
   The SPL (split) instruction splits the execution between this
warrior's currently running tasks and a new task.  Example: A battle
between two warriors, 1 and 2, where warrior 1 has two tasks (1 and
1') and warrior 2 has only one task would look like this: 1, 2, 1', 2,
1, 2, 1', 2, etc.
86: SPL allows only one operand - the B-operand.  The A-operand is
    shown as #0.  After executing the SPL, the next instruction to
    execute for this warrior is that of the newly added task (the new
    task is placed at the front of the task queue).  A maximum of 64
    tasks is allowed for each warrior.
88: SPL splits the A-operand, not the B-operand.  After executing the
    SPL, the next instruction to execute for this warrior is the same
    instruction which would have executed had another task not been
    added (the new task is placed at the back of the task queue).
    There is no explicit task limit on warriors.  Immediate A-operands
    are not allowed.
X: Immediate A-operands are allowed and behave as SPL 0, B when
    executed.

88: SLT A, B: The SLT (skip if less than) instruction skips the next
    instruction if A is less than B.  No Immediate B-modes are
    allowed.
X: Immediate B-modes are allowed.

X: XCH A, B: The XCH (exchange) instructions exchanges the A-field and
    the B-field of the instruction pointed to by the A-operand.

X: PCT A, B: The PCT (protect) instruction protects the instruction
    pointed to by the A-operand until the protection is removed by an
    instruction attempting to copy over the protected instruction.


Pseudo-Ops: Instructions to the Assembler
-----------------------------------------

END
    The END pseudo-op indicates the end of the Redcode source program.
86: END takes no operands.
88: If END is followed by a label, the first instruction to be
    executed is that with the label following END.
X: ORG A (origin) takes over this initial instruction function from
    END.
Commentary: If no initial instruction is identified, the first
    instruction of your program will be the initial instruction.  You
    can accomplish the same effect as "END start" or "ORG start" by
    merely starting your program with the instruction "JMP start".

86: SPACE A, B: The SPACE pseudo-op helps pretty-up Redcode source
    listings.  SPACE A, B means to skip A lines, then keep B lines on
    the next page.  Some assemblers do not support SPACE, but will
    treat it as a comment.

88: label EQU A: The EQU (equate) pseudo-op gives the programmer a
    macro-like facility by replacing every subsequent occurrence of
    the label "label" with the string "A".
Commentary: A normal label is a relative thing.  Example:

x       DAT  #0,  #x   ; Here x is used in the B-field
x+1     DAT  #0,  #x   ; Each instruction's B-field gives
x+2     DAT  #0,  #x   ;    the offset to x.

is the same as

x       DAT  #0,  #0   ; Offset of zero
x+1     DAT  #0, #-1   ;    one
x+2     DAT  #0, #-2   ;    two

but

x!      EQU   0        ; Equate label like #define x! 0
        DAT  #0,  #x!  ; Exclamation points can be used
        DAT  #0,  #x!  ;    in labels (in Extended systems)
        DAT  #0,  #x!  ; I use them exclusively to indicate
                       ;    immediate equate labels.

is the same as

        DAT  #0,  #0   ; A direct text replacement
        DAT  #0,  #0   ;    appears the same on every
        DAT  #0,  #0   ;    line it is used.

----------------------------------------------------------------------



Subject: RND instruction?
From: tazzzzz@caen.engin.umich.edu (Kevin Dangoor)
Organization: caen
Date: 14 Nov 91 12:23:42 GMT
Message-ID: <jvh_b_-@engin.umich.edu>

I saw a version of Core War for the IBM awhile back that had a RND
instruction that produced a random address... I used it to code a
rather nasty program called Hydra that copied itself to a random
location then split off to the new copy... soon, you had dozends
of Hydrae running, each one copying itself, overwriting everything
in its path. Is RND supported by any standard versions of Redcode?

Also, does anyone know where I can get a good version of Core War
for my Amiga?



Subject: Re: PROTECT instruction can foil single imp.
From: orb@ccwf.cc.utexas.edu (Norman Richards)
Organization: The University of Texas at Austin, Austin TX
Date: 14 Nov 91 14:21:48 GMT
Message-ID: <61807@ut-emx.uucp>

In article <MJD.91Nov13125208@saul.cis.upenn.edu> mjd@saul.cis.upenn.edu (Last of the Giants) writes:
>
>    Some versions of redcode support a PCT (`protect') instruction which
>write-protects a certain memory address; an attempt to write to a
>protected address will remove the protection but will not change the
>contents....

 How is a protected block flagged?  Does it mess with the data that is 
allready there.  If it is seperate then a more permanent all-purpose imp
protection might be:
   roadblock:   PCT   roadblock
                DAT   $0
   begin:       [rest of program]

 If an IMP type came along and hit the roadblock with a mov 0 1 then it
would be deprotected.  But then, it would execute the reprotection command
and die at the next step.  
 Is there any way to to tell if a memory has been protected besides writing
to it to see if it has been changed?   What about read protection?  A protect
could be like a cloak.  If someone tried to read from that location then
it would get a background DAT type thing, but then the "cloaking" would be 
off and it would be as normal.  Think of ir - stealth core war!  You could
hide an "invisible" piece of code out in memory and then all of a sudden
activate it by reading over it once the running it.

______________________________________________________________________________
orb@ccwf.cc.utexas.edu              "Two roads diverged in the forest
                                     And I - I chose to climb the nearest tree.
                                     And that has made all the difference."



Subject: Re: rec.games.corewar
From: cpbeaure@descartes.waterloo.edu (Chris Beauregard)
Organization: University of Waterloo
Date: 14 Nov 91 17:03:20 GMT
Message-ID: <1991Nov14.170320.1332@descartes.waterloo.edu>

In article <1991Nov13.235214.57852@eagle.wesleyan.edu> cdixon@eagle.wesleyan.edu writes:
>Also I have a CoreWars issue I'd like to mention:
>	I found that the techinique of bombing with SPL 0 commands can be
>very deadly (as I'm sure many of you know) but I think it may be so deadly
>that it should be outlawed.  I wrote a battle program called NUKE which very 
>quickly covers most of the screen with SPL 0's (disabling all enemies) and
>then makes a second pass through memory with DAT 0's.  It beats every program
>95% of the time (including MICE from A.K. Dewdney's article).  For me it kind

  I find that's pretty tame.  I wrote a program I call Broadsword.  It sends
out bombs that look like
		SPL 0
		JMP -1
  When one of these things are hit, the program splits off at exponential rates
(powers of two).  I think the figure is roughly 2^(turn elapsed/2).  So after
40 turns, there will be about a million programs out there.  Not only can
nothing possibly survive this, you could crash a MARS system with it.  I put
a limit of 10000 programs per side when I implemented my version, but some
people might not think of that...

>of ruined CoreWars since it seems to be the ultimate killing program.  The only

  Yup, any Absolute Killer of All Oposition type program will do that.

>program which could even beat it would be one which does the same thing but
>slightly more efficient.  Anyone have any solutions short of outlawing SPL 0?
>(which would actually be futile since people could use SPL 1 followed by SPL -1
>or something like that in its place).  What do they do about this problem in
>the tournaments?

  Put a limit on the number fo programs, say 100.  That makes things like MICE
and CHANG1 kind of limited, but it makes things more challenging.     

-------------------------------------------+-------------------------------+  
Chris Beauregard                           |Any ideas and/or opinions      |
cpbeaure@descartes.waterloo.edu            |expressed here are solely mine.|
"If you can't beat 'em, take 'em with ya!" +-------------------------------+



Subject: Redcode assembler, simulator pseudocode?
From: cmeyer@milton.u.washington.edu (Colin Meyer)
Organization: University of Washington
Date: 15 Nov 91 00:12:14 GMT
Message-ID: <1991Nov15.001214.4899@milton.u.washington.edu>

Does any one have pseudocode (or in code in some common language) for
a redcode assembler & simulator?

I want to implement Corewar on the hp48sx calculator, and it would be 
nice if I did not have to start from scratch...

Thank you,
--Colin.

-- 
"When one reflects upon what consciousness really is, one is profoundly 
 impressed by the extreme wonder of the fact that an event which takes place 
 outside in the cosmos simultaneously produce an internal image, so to speak,
 inside as well, which is to say: becomes conscious."  -C.G. Jung



Subject: Example Redcode Program
From: blojo@xcf.berkeley.edu (Jon Blow)
Organization: WINDOM BIFF FAN CLUB!!!!!!!!!!!!
Date: 15 Nov 91 01:34:34 GMT
Message-ID: <as0t92498h49h8aeogha348g2h8@xcf>

This program is the most successful application of SPL0 that I have conjured
up.  A brief description of how it works:

MARS FLYTRAP picks an address to bomb; it then calculates the distance
between that address and the target location 'maw'.  It calculates a jump
instruction that leads to 'maw' and then drops that instruction in the bomb
slot.  The 'maw' address is, of course, yet another incarnation of SPL0.

The FLYTRAP then copies itself up the core and continues.  Each time it copies
itself, it drops a zero-bomb five lengths behind itself-- where it was before
it jumped five times.  This zero bomb will land in a maw five generations old,
causing all processes looping inside it to die.

The basic idea at work here is that the MARS FLYTRAP attempts to keep processes
occupied by having them spawn indefinitely, but it eventually kills the enemy
off.  Since there is more than one maw active (hopefully) at once, when one of
them is destroyed, the processes inside the other ones will replicate enough
to once again fill the process limit, if there is at least one process in some
maw.  If there is no process limit, then, well, we don't have to worry about
the enemy getting too much faster when we destroy a maw because they will have
spent more of their time splitting than they would were they to run into a 
process limit and fail to split.

This program was written in Redcode '86 and translated into '88.  If it
used the full features of '88, it could probably be written more efficiently.
Note also the arithmetic acrobatics it performs to compute the jump bomb;
this is because the simulator I wrote this on adds all 3 numerical slots
of an address (INSTRUCTION, A, and B) when executing ADD and SUB operands.
I believe that the new standard says that only the data field (B) should
be affected, which would also make this program simpler.

;;; MARS FLYTRAP
;;;
;;; Performs somewhat well against MICE.
;;; Makes pretty patterns versus CHANG1.
;;;
;;;   - blojo@soda.berkeley.edu


safety  equ 64                  ; So we don't hit ourselves
step    equ 16                  ; Distance between bomb targets
jumpd   equ 813                 ; How far we jump per step
len     equ last - index        ; Length of the necessary program

start   sub jmpmsk, delta
        jmp loop
jmpmsk  jmp 0
bomb    jmp maw                 ; This is the expendable part of the flytrap,
target  dat #-1                 ; which we do not need to copy, and so we
index   dat 0                   ; don't.

delta   jmp 16
orgjmp  jmp maw-bomb            ; dist. from BOMB to MAW
        mov #-1, target         ; must be = to target's initial value
        mov orgjmp, bomb
loop    sub #step, target
        add delta, bomb
        mov bomb, @target
        slt target, #safety
        jmp loop
        mov #len, index
        mov #-jumpd, target
cploop  mov @index, <target
        djn cploop, index
        add #2, target
        mov #0, (jumpd + len +2) * 5 + 2
        jmp @target
maw     spl 0
last    jmp maw



Subject: Re: IMP stomping
From: dxb105@csc1.anu.edu.au
Organization: Theoretical Physics, R.S.Phys.S., A.N.U., Australia
Date: 15 Nov 91 00:52:32 GMT
Message-ID: <1991Nov15.115232.29@csc1.anu.edu.au>

In article <9apq28y98ha3ty98qh4ty98h2g@xcf>, blojo@xcf.berkeley.edu (Jon Blow) writes:
> This is a little discussion about how to build better IMP STOMPERs.

If all you want to do is stomp IMPs, the best method is probably something like
the old "RADAR" program. Maintain a picket some distance upstream of you (RADAR
has one downstream too, this isn't necessary for IMPs). Spend some of your time
checking the picket is intact, and the rest bombing the rest of memory at
random. If the picket is overrun, copy yourself to someplace safe (like some
distance behind it, where the IMP has already been) and jump there. It may take
a while, but you'll nail the IMP eventually. And it isn't critically dependent
on a large CPU allocation, so you can do other things in the meantime, unlike
the direct stomping approach.

Unfortunately the program tends to be fairly large and hence fragile with
respect to bombardment or vampiric capture. Unless the bombardment method is
silly enough to have a very small increment (e.g. DWARF) in which case RADAR
may be able to dodge it.

------------------------------------------------------------------------------
David Bofinger	AARNet:	dxb105@phys.anu.edu.au
                Snail:	Dept. of Theoretical Physics, RSPhysS, ANU, ACT, 2601
------------------------------------------------------------------------------



Subject: Limited bombing range
From: snewman@Neon.Stanford.EDU (Steven Newman)
Organization: Computer Science Department, Stanford University, Ca , USA
Date: Fri, 15 Nov 1991 04:28:21 GMT
Message-ID: <1991Nov15.042821.21202@CSD-NewsHost.Stanford.EDU>

To some extent this is desirable, of course - you want to penalize complex
programs unless they justify their complexity through increased abilities.
And instructions like SPL allow a certain amount of protection against
random bombs.  Still, it's difficult to do anything really interesting in
Core Wars.

A modification that I think might make the game more interesting would be to
limit the range of write instructions.  Instead of allowing a program to
drop bombs anywhere in memory, it would be limited to locations within, say
256 locations of the program counter.  To make attacks farther out, it would
have to copy itself (or send "scouts", i.e. simplified programs that just
propagate forward, bombing as they go).

This could lead to all sorts of interesting goings-on - programs copying
themselves forward 256 locations at a time, other (defensive) programs
bombing the zone within 256 locations of themselves, etc.

Limiting the range of read instructions would be optional.  I suspect it
would be more interesting to allow reading at a larger range, if not all
of memory, for "recon".

Any comments?  Has anyone ever seen something like this implemented?




Subject: Re: SPL 0 ; JMP -1
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: 15 Nov 91 07:22:38 GMT
Message-ID: <91319.01:22:46.491523.DURHAM@ricevm1.rice.edu>

>>From: cpbeaure@descartes.waterloo.edu (Chris Beauregard)
>> So after
>>40 turns, there will be about a million programs out there.

Whoa!  SPL 0 should split ONE task per ONE turn at most.  I have never
seen a system which allocated one more cycle to each turn for every task
added to the system, and I hope I never do!

MAD



Subject: Re: Redcode assembler, simulator pseudocode?
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: 15 Nov 91 08:44:52 GMT
Message-ID: <91319.02:45:03.791112.DURHAM@ricevm1.rice.edu>

>>Does any one have pseudocode (or in code in some common language) for
>>a redcode assembler & simulator?

Is ANSI C common enough?
This implementation of an ICWS'88 MARS was designed to be meticulously
correct in its interpretation.  It is not documented (here) or efficient.
Illegal instructions are assumed to have been caught by the assembler.
Instructions are assumed to have been encoded by the assembler.
Initial task pointers are assumed to have been set by the loader.
The function EMI88 executes one instruction from each of two programs.
Note that most of the work has been done before the opcode is even
decoded.

You are free to dissect, change, and use the code as you see fit.
Any change in the behaviour of the code will be a deviation from the
ICWS'88 standard, however.

-------------------------------------------------------------------------

/*********************************/
/*                               */
/*            EMI88.c            */
/*                               */
/* Execute MARS Instruction a'la */
/* ICWS'88.                      */
/*                               */
/* July 21, 1991                 */
/* Mark A. Durham                */
/*********************************/

#define FALSE  0
#define TRUE   1

struct Statement_Register {
   unsigned char  Control;    /* Encoded Opcode, A-mode, and B-mode */
   int            AField;
   int            BField;
};

struct CoreNode {
   struct CoreNode *last;
   int PC;
   struct CoreNode *next;
};

enum Opcode {
   DAT,
   MOV,
   ADD,
   SUB,
   JMP,
   JMZ,
   JMN,
   DJN,
   CMP,
   SLT,
   SPL
};

enum Mode {
   IMMEDIATE,
   DIRECT,
   INDIRECT,
   PREDECREMENT
};

int EMI88(
   struct CoreNode            *CLL[],
   struct Statement_Register  CORE[],
   int                        MaxTask,
   int                        memory,
   int                        *Tasks
) {
   struct Statement_Register  SR;
   struct Statement_Register  SRA;
   struct Statement_Register  SRB;
   struct CoreNode            *lastCoreNode;
   struct CoreNode            *tempCoreNode;
   int                        index;
   int                        PC;
   int                        PCA;
   int                        PCAI;
   int                        PCB;
   int                        PCBI;
   enum Opcode                OpCode;
   enum Mode                  AMode;
   int                        AValue;
   enum Mode                  BMode;
   int                        BValue;
   int                        cmp;

   for (index = 0; index < 2; index++) {
      PC = CLL[index]->PC;
      SR = CORE[PC];
      AMode = (SR.Control & 0x0C)/4;
      if (AMode == IMMEDIATE) {
         PCA = PC;
         SRA = CORE[PCA];
         AValue = SRA.AField;
      } else {
         PCA = (PC + SR.AField) % memory;
         SRA = CORE[PCA];
         if (AMode != DIRECT) {
            if (AMode == PREDECREMENT) {
               PCAI = PCA;
               PCA = (PCA + memory - 1) % memory;
               CORE[PCAI].BField = (CORE[PCAI].BField + memory - 1) % memory;
            };
            PCA = (PCA + SRA.BField) % memory;
            SRA = CORE[PCA];
         };
         AValue = SRA.BField;
      };
      BMode = SR.Control & 0x03;
      if (BMode == IMMEDIATE) {
         PCB = PC;
         SRB = CORE[PCB];
      } else {
         PCB = (PC + SR.BField) % memory;
         SRB = CORE[PCB];
         if (BMode != DIRECT) {
            if (BMode == PREDECREMENT) {
               PCBI = PCB;
               PCB = (PCB + memory - 1) % memory;
               CORE[PCBI].BField = (CORE[PCBI].BField + memory - 1) % memory;
            };
            PCB = (PCB + SRB.BField) % memory;
            SRB = CORE[PCB];
         };
      };
      BValue = SRB.BField;
      CLL[index]->PC = (CLL[index]->PC + 1) % memory;
      lastCoreNode = CLL[index];
      CLL[index] = CLL[index]->next;
      OpCode = (SR.Control & 0xF0)/16;
      switch (OpCode) {
      case DAT:
         Tasks[index] -= 1;
         tempCoreNode = lastCoreNode;
         CLL[index]->last = tempCoreNode->last;
         tempCoreNode->last->next = CLL[index];
         free(tempCoreNode);
         break;
      case MOV:
         if (AMode == IMMEDIATE) {
            CORE[PCB].BField = AValue;
         } else {
            CORE[PCB] = SRA;
         };
         break;
      case ADD:
         CORE[PCB].BField = (AValue + BValue) % memory;
         if (AMode != IMMEDIATE) {
            CORE[PCB].AField = (SRA.AField + SRB.AField) % memory;
         };
         break;
      case SUB:
         CORE[PCB].BField = (BValue + memory - AValue) % memory;
         if (AMode != IMMEDIATE) {
            CORE[PCB].AField = (SRA.AField + SRB.AField) % memory;
         };
         break;
      case JMP:
         lastCoreNode->PC = PCA;
         break;
      case JMZ:
         if (BValue == 0) {
            lastCoreNode->PC = PCA;
         };
         break;
      case JMN:
         if (BValue != 0) {
            lastCoreNode->PC = PCA;
         };
         break;
      case DJN:
         CORE[PCB].BField = (CORE[PCB].BField + memory - 1) % memory;
         if (BValue != 1) {    /* ((BValue-1) != 0) */
            lastCoreNode->PC = PCA;
         };
         break;
      case CMP:
         cmp = FALSE;
         if (AMode == IMMEDIATE) {
            if (AValue == BValue) {
               cmp = TRUE;
            };
         } else {
            if (SRA.Control == SRB.Control) {
               if (SRA.AField == SRB.AField) {
                  if (SRA.BField == SRB.BField) {
                     cmp = TRUE;
                  };
               };
            };
         };
         if (cmp) {
            lastCoreNode->PC = (PC + 2) % memory;
         };
         break;
      case SPL:
         if (Tasks[index] < MaxTask) {
            Tasks[index] += 1;
            tempCoreNode = (struct CoreNode *)malloc(sizeof(struct CoreNode));
            tempCoreNode->last = lastCoreNode;
            tempCoreNode->PC = PCA;
            tempCoreNode->next = CLL[index];
            lastCoreNode->next = tempCoreNode;
            CLL[index]->last = tempCoreNode;
         };
         break;
      case SLT :
         if (BValue < AValue) {
            lastCoreNode->PC = (PC + 2) % memory;
         };
         break;
      default:
         return(FALSE);
      };
   };
   return(TRUE);
}



Subject: Re: Example Redcode Program
From: cpbeaure@descartes.waterloo.edu (Chris Beauregard)
Organization: University of Waterloo
Date: Fri, 15 Nov 1991 13:44:43 GMT
Message-ID: <1991Nov15.134443.28442@descartes.waterloo.edu>

In article <as0t92498h49h8aeogha348g2h8@xcf> blojo@xcf.berkeley.edu (Jon Blow) writes:

>The basic idea at work here is that the MARS FLYTRAP attempts to keep processes
>occupied by having them spawn indefinitely, but it eventually kills the enemy
>off....

  These types of programs are fun.  This resembles something I wrote called
Mobile Bloodsucker.  It uses the same idea for catching the enemy process, but
instead of having it spawn idefinitely, I use the program to bomb through
memory.  After the enemy has completed one entire round of bombing, the process
is killed off.  Either that, or Bloodsucker moves somewhere else, kills the old
process, and leaves a "forwarding address" for programs caught by its old traps.
  I've written quite a few versions of these types of programs.  I call the
entire class of them "slave drivers", for obvious reasons.
  One really neat slave driver concept is the use of the imp.  If you can turn
the oponent into an imp, he normally runs through memory and really causes 
damage.  The only major problem is killing off the enemy process.  I use the
PCT instruction in my Mac implementation, but I can't think of a really good
method in ICSW standards to kill the imp and still have a bombing process
running...

  How many people here have worked extensively with multi-process programs?  
I personally think these are the best systems around.  I find they work really
well for mobile programs.  You have one process bombing, and the other one
doing the copy routine.  

  Also, has anyone come up with a really surefire and fast verification routine
for copying?  I have a few variations that I've written, but they all require
two passes, and an extra bombing routine to clear out changed code.

-------------------------------------------+---------------------------------  
Chris Beauregard                           | If all the world's a stage, what
cpbeaure@descartes.waterloo.edu            | do we do when the audience starts
"If you can't beat 'em, take 'em with ya!" | throwing stuff?



Subject: Re: SPL 0 ; JMP -1
From: cpbeaure@descartes.waterloo.edu (Chris Beauregard)
Organization: University of Waterloo
Date: Fri, 15 Nov 1991 14:08:05 GMT
Message-ID: <1991Nov15.140805.706@descartes.waterloo.edu>

In article <91319.01:22:46.491523.DURHAM@ricevm1.rice.edu> DURHAM@ricevm1.rice.edu (Mark A. Durham) writes:
>>>From: cpbeaure@descartes.waterloo.edu (Chris Beauregard)
>>> So after
>>>40 turns, there will be about a million programs out there.
>
>Whoa!  SPL 0 should split ONE task per ONE turn at most.  I have never
>seen a system which allocated one more cycle to each turn for every task
>added to the system, and I hope I never do!
>
>MAD

  Good point.  I screwed up the description bigtime.

  Assuming the program you hit is a multi-process program with two processes
running, and you hit one of them.
  Call the regular process (the one we didn't hit) the legal process.
  Every time the legal process executes, there will be something like 
2^(legal executions since other process trapped/2), give or take an exponent, of
executions of the captured and split processes before we get back to the legal.
So, if the legal process has executed 40 times since the other process was
trapped, there will be about 1000000 processes that will execute before getting
back to the legal process.

  I hope that clarifies things...
  Actually, I hope my logic is right on that.  Then again, my impression of how
the Core War turn handling works might be corrupt...

-------------------------------------------+---------------------------------  
Chris Beauregard                           | If all the world's a stage, what
cpbeaure@descartes.waterloo.edu            | do we do when the audience starts
"If you can't beat 'em, take 'em with ya!" | throwing stuff?



Subject: Re: Limited bombing range
From: berg@physik.tu-muenchen.de (Stephen R. van den Berg)
Organization: RBI - RWTH Aachen
Date: 15 Nov 91 14:46:59 GMT
Message-ID: <1991Nov15.144659.14201@urmel.informatik.rwth-aachen.de>

Steven Newman writes:
>To some extent this is desirable, of course - you want to penalize complex
>programs unless they justify their complexity through increased abilities...

>A modification that I think might make the game more interesting would be to
>limit the range of write instructions....

An alternative would be that you would have a single "write-credit" counter
for each side (shared by all the SPL'd programs on that side):

It is set to 256 every time a write in one of the SPL'd programs is performed
and if any of the SPL'd programs tries to write to an address further away
than the "write-credit" counter allows, it is put at the back of the execution
queue again.  This "write-credit" counter would be incremented by a constant
amount on every instruction of either side (or it could be doubled every
time, or whatever).

This favours programs that do a fair amount of processing between writing
at far away memory locations (thereby favouring complex programs), but
it does not outlaw the simple ones, it simply stalls them if they don't
have anything better to do than bombing far away places (until their
write-credit counters allow the write again).

Just my $0.02
--
Sincerely,                                berg@messua.informatik.rwth-aachen.de
           Stephen R. van den Berg (AKA BuGless).    berg@physik.tu-muenchen.de

Real programmers don't produce results, they return exit codes.



Subject: Re: SPL
From: hallyb@globbo.enet.dec.com (John Hallyburton)
Organization: Twin Peaks Municipal Software Works
Date: 15 Nov 91 00:35:24 GMT
Message-ID: <30251@nntpd.lkg.dec.com>


blojo@xcf.berkeley.edu (Jon Blow) writes...
>cdixon@eagle.wesleyan.edu writes:
> 
>> [SPL 0 bomb description]
> 
>It sounds like you're running this on a simulator that does not follow
>ICWS '88 process initiation specifications. [...]

One thing that was never made really crystal-clear to me was the scheduling
of sons of SPLs.  If warrior 1 splits we get task 1 and task 1' and they are
scheduled alternatively in the order 1, 2, 1', 2, 1, 2, 1', 2 etc.

Now suppose 1' splits once more, and we get 1' and 1".  Is the execution then

1, 2, 1', 2, 1", 2, 1, 2, 1', 2, 1", etc. 3 tasks round-robin
		   OR
1, 2, 1', 2, 1, 2, 1", 2, 1, 2, 1', 2, 1, 2, 1", etc. 1 alternating with 1'/1"

I get the impression that all tasks are created equal, rather than sharing
their fathers' time-slice.  Is that correct?

--
						"The Smart Money was on Goliath"
						John Hallyburton 43 55'N 71 45'W



Subject: Re: Oops
From: sander@tagus.engin.umich.edu (the ethc)
Organization: University of Meta-Engineering, Ann Arbor
Date: 15 Nov 91 17:51:25 GMT
Message-ID: <gLj_MfC@engin.umich.edu>


In article <ki454hINN1mc@agate.berkeley.edu>, blojo@xcf.berkeley.edu (Jon Blow) writes:
> 
> The correct suggestion, of course, should have been:
> 
> start: jmp start, <-1

I wrote a slight variation upon this idea, with the intention of destroying
more than IMPs. 

HAVOC.CWR

	DAT #-2       
	DAT #-3000    ;this constant can be set to reflect the playing field
start	DJN 0 <-1 
	JMP -1

start	DJN 0 <-1     
i don't remember if this statement is correct or not, as I wrote
this quite some time ago and haven't played for a great
while. essentially, it is intended to use the DAT 
statement as an index to places to decrement. the program
runs through memory backwards, decrementing each memory
location that it runs across. this basically ruins most programs
that it encounters. when the program runs across itself after looping
through one length of the playfield, it begins to use the first
DAT statement as its pointer, rather the the DAT #-3000 statement.

this program is death to very complex programs. the only program
that has done reasonably well against it is the MICE program, oddly
enough.

the etch



Subject: Subverting opponents to copy yourself
From: rjc@hal.gnu.ai.mit.edu (Ray)
Organization: ^
Date: 15 Nov 91 19:20:55 GMT
Message-ID: <20286@life.ai.mit.edu>


  A while ago I read about "artificial life" in comp.theory.cell-automata
my main interest being the Tierra papers.  The author describes some of
the programs that had evolved (parasites) that lacked the code to
copy themselves. What they did was scan around looking for other
cells and then use other cell's copy routine to copy itself. Hence it
duplicated faster since it only needed to copy 22 or so bytes vs 80.
This gave me an idea for corewars. How about a program that subverts
others into impstomping for it,copying it and then dieing. I have seen
other "virus" redcode programs but none of them did what real viruses do, and
that is to use the target for it's copying rather than just subverting
it to a bombing run.

Well I wrote such a program around September but haven't had a chance
to debug/test it and I'm hoping someone can check this out for me.
I have 3 versions of corewars on my machine (Amiga) but they are
all unusable. 2 of them are the old ICWS standard without the 
autodecrement address mode, some don't have "equ" and the other one is
in german. I found a Unix curses based one, but it's not an up to date
ICWS assembler/simulator. The other on is the X11r4 one on soda.berkeley.edu.
(which is quite nice only I don't have access to an x-display at the moment)

The program is fairly simple right now,here is what is does (or I hope it
does).

1) initialization (find certain "differences" between the spl and jmp
functions)
2) start up the virus dispatcher which executes newly copied code that
our opponent copied for us.
3) scan for non zero corememory which hopefully contains opponent's code.
4) subvert it to a copy/imp stomp routine
5) loop

the virus dispatcher merely loops around executing a jmp1 (nop). When
the copy routine finishes, it forces the opponent to place an
"spl" at the jmp1 to start up the new virus, then the copy task
is put to death. After the new virus is started, the spl is changed back into
a jmp1.

;Retrovirus
;By Ray Cromwell (rjc@gnu.ai.mit.edu)
;USA
;September 1991
;Technique: Subvert other program tricking it into impstomping and copying
;	    our virus for it.

;Here is where the main debugging has to be concentrated. Make sure
; these offsets or correct or the subvert wil execute the wrong instruction.

sizeprog    equ endprog-startprog
rnaoffset   equ virusrna-mainloop


startprog   dat #0
impstomp    mov #0 -1
	    mov #0 -2
	    mov #0 -3
	    mov #0 -4
	    jmp impstomp
jmp0	    jmp 0
jmp1	    jmp 1
jmp5	    jmp 5
jmpvec	    jmp 600+rnaoffset ;make sure jmp points to "virusrna" routine
memptr	    dat #-600
tmp	    dat #0
execaddr    dat #0
size	    dat #0
ptr	    dat #0
dest	    dat #0
delta	    dat #0

start	    mov jmp1 startprog		   ;Put a nop in the beginning
	    mov jmp5 tmp		   ;
	    sub jmp0 tmp		   ;Find jmp5-jmp0
	    mov jmp1 delta		   ;
	    sub jmp0 delta		   ;Find jmp1-jmp0
	    spl exec			   ;start rna dispatcher
mainloop    cmp #0 @memptr		   ;scan for nonzero code
	    jmp subvert 		   ;if non zero, subvert it!
	    sub #5 memptr		   ;sub 5 from ptr
	    add tmp jmpvec		   ;add 5 to jmp instruction
	    jmp mainloop		   ;loop

subvert     sub #6 memptr                  ;6 instructions from cmp #0 #memptr
            mov jmpvec @memptr		   ;poke jmp vector(subvert!)
	    sub #1 memptr		   ;sub 1 from ptr
	    add delta jmpvec		   ;add 1 to jmp vector
	    add #6 memptr
	    jmp mainloop		   ;loop


code	    spl @execaddr

exec	    jmp 1			   ;dispatcher
	    cmp exec code		   ;Execute another virus copy
	    jmp exec			   ;after our opponent has
	    mov jmp1 exec		   ;graciuously copied it then
	    jmp exec			   ;change the spl back into a nop.

virusrna    spl impstomp		   ;make the other program protect us!
	    mov #sizeprog size		   ; find size
	    mov #endprog ptr		   ; get ptr at end
	    mov #400 dest		   ;copy 400 ahead
cploop	    mov <endprog <dest		   ; copy it
	    djn cploop size		   ;
exc	    mov #409 execaddr  		   ;exec begging of code
	                                   ; it is 9 instructions from
		 	                   ; exec to cploop

	    mov code exec		   ; trigger activation
endprog     dat #0			   ;kill the other program's process

--------------------------------------------------

I don't see any problems with it except for the offsets. Assemblers
with "equ" ability help but it's still tough keeping track of
which instruction is executing which relative pointer so I could have
messed it up. Feel free to make any improvements or changes.
When I get free time this weekend I've remove the equ's and put in the
raw numbers. 

Future plans:

  Identifying marker so we don't subvert ourselves. This would consist
of a tag of atleast 5 instructions. For instance, 5 DAT #1991's which
the scanning routine would detect and skip over. If the tag gets bombed
there's a problem.

  Instead of dispatching a new copy of the virus with spl, instead
spl off a "short" bombing run that dies. (like a small mortar) and
JMP directly to the new copy. 


More ideas:

  A corewars program that subverts other's to implement a "voter"
error detection routine and if an error is found, fix it.
The allows the main program to go on bombing/subverting while the opponent
goes on error checking us.

  All of these ideas come from the quest to slow the enemy down
by zapping his cpu resources. Instead of slowing him down with spl0
bombs, force him to do something useful.




Subject: IMPs/multi-process programs
From: blojo@xcf.berkeley.edu (Jon Blow)
Organization: WINDOM BIFF FAN CLUB!!!!!!!!!!!!!!
Date: 15 Nov 91 21:35:58 GMT
Message-ID: <ag08h4298ah34gakdg@xcf>

Chris Beauregard writes:

>   One really neat slave driver concept is the use of the imp.  If you can turn
> the oponent into an imp, he normally runs through memory and really causes 
> damage.  The only major problem is killing off the enemy process...

Ya know, it's really cool to talk to people out there who write neat
Redcode programs.

This idea is sort of similar to one that I had.  Of course, if you can turn
the enemies into imps, they spend their CPU time destroying each other instead
of you having to use so much of yours.  I find this fairly effective against
programs like MICE.

The following program that I wrote a while ago, SLUICEGATE, works like that.
Basically, it bombs the core at a fairly spaced interval (currently set to
12).  Instead of dropping zero bombs, though, it drops IMPS.  Once it has
made one round of the core, it starts bombing again, but with a bit of an
offset so that it doesn't bomb the same addresses.

At the same time the bombing is going on, there is an IMP STOMPER protecting
its top end.  

After SLUICEGATE has made a certain number of bombing rounds (Currently set
to 5), the bombing process stops bombing and jumps to the IMP conveniently
placed at the tail of the program.  Since there are only two processes
running, the IMP zooms through the core at half light-speed, hopefully 
transfixing any programs which have survived the bombing.

When SLUICEGATE's IMP reaches its IMP STOMPER, the IMP is destroyed.  This
leaves SLUICEGATE with only one process running-- the IMP STOMPER.  Since
this IMP STOMPER is running at lightspeed, it cannot fail to destroy the
enemy IMPs which will eventually reach it.

When SLUICEGATE fails, it is often because it takes too much time bombing the
core, and thus is still running two processes when the last enemy IMP hits the
IMP STOMPER.  

SLUICEGATE does not move.  It would be really interesting to see an example of
a program like this that does move.

The code below was written in Redcode '86 and translated to '88.  Because of
that, it is probably a bit inefficient in ways it doesn't have to be.

;;; SLUICEGATE
;;;

hit:    dat #0
pad:    dat #0
stomp:  jmp stomp, <hit
flood:  mov imp, @target
        add #12, target
        slt #-20, target
        jmp flood
        add #22, target
        djn flood, sweeps
        jmp imp
target: dat #20
start:  spl stomp
        jmp flood
sweeps: dat #5
imp:    mov 0, 1


Subject: Re: SPL
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: 15 Nov 91 23:30:10 GMT
Message-ID: <91319.17:30:19.150599.DURHAM@ricevm1.rice.edu>

>>One thing that was never made really crystal-clear to me was the scheduling
>>Now suppose 1' splits once more, and we get 1' and 1".  Is the execution then
>>1, 2, 1', 2, 1", 2, 1, 2, 1', 2, 1", etc. 3 tasks round-robin
>>I get the impression that all tasks are created equal, rather than sharing
>>their fathers' time-slice.  Is that correct?

Yes, all tasks are created equal.  Consider the following program:

   SPL 0
   MOV 0, 1

Under ICWS'88, the initial task (1) will split a second task (I'll use 2 and
ignore any other warriors' tasks) which will split a third task (3), etc.
Order of execution is then:

1 12 123 1234 12345 ...

Note that under ICWS'86, this example is far less interesting because the
new tasks are placed at the front of the task queue instead of the back.
Thus, execution is simply:

123456789 ...

MAD



Subject: King of the hill.
From: wdlee@ccwf.cc.utexas.edu (david lee)
Organization: The University of Texas at Austin
Date: 16 Nov 91 21:37:09 GMT
Message-ID: <62065@ut-emx.uucp>

Redcoders:
 Remember that big pile of dirt in the vacant lot down the street?
(it seemed huge!) and John would scramble up to the top and yell, "I'm
king of the hill!" Yea, right. Not for long...

 Let's organize a "MARS server" so that we can submit our Redcode (in
source form) via E-mail to some server that assembles it, and pits
it against the reigning (sp?) "king of the hill". Here's a "gedanken"
session:

<First we write some Redcode...>

Your.machine.bigu.edu > vi impthing.rc

<yucky vi session omitted>
"impthing.rc" [New file] lot'sa lines, buncha' characters.

<Then we mail it to the Mars server to enter a battle...>

Your.machine.bigu.edu > mail marsserver@their.machine.otheru.edu < impthing.rc

<Of course, we'll need to establish standard headers and footers and
such, but that's easy... right? So we continue with our daily work
while our pride and joy , impthing.rc, slugs it out...>

Your.machine.bigu.edu > xloadimage elle2.gif

<And when you get back from lunch.... >

[YOU HAVE NEW MAIL]

Your.machine.bigu.edu > mail

Mail [5.2 UCB] [IBM AIX 3.1]  Type ? for help.
"/usr/spool/mail/you": 1 message 1 new
>N  1 marsserver    Fri Nov 15 03:08  12/370 "battle results"
& 1

Message  1:
>From marsserver Fri Nov 15 03:08:16 1991
Date: Fri, 15 Nov 91 03:08:15 -0600
From: marsserver@their.machine.otheru.edu
To: you@your.machine.bigu.edu
Subject: battle results

Warrior impthing.rc (received Fri, 15 Nov 91 02:10:11 1991)
was squashed in a mere 15 clock cycles by the reigning champ, byte.rc.
Thank you for playing, and remember, no wagering please.

& d

<What do you think? We could even mail postscript trophies out to the winners!
And the winning routines might be posted in r.g.c.
This could easily be implemented manually, but who wants to sit and
compile someone elses redcode all day? Might one of you systems folks
knock this out one rainy afternoon?>

Happy imp stomping,

David@moe.ece.utexas.edu



Subject: MARS in Hardware!
From: jmason2@gpu.utcs.utoronto.ca (Jamie Mason)
Organization: University of Toronto Computer Services Advisor
Date: 17 Nov 91 01:35:42 GMT
Message-ID: <1991Nov17.013542.9103@gpu.utcs.utoronto.ca>


	I had this idea last night about implementing a MARS machine in
hardware.  It sounds SO COOL!  I also don't think it would be that hard
to do.  Is this a neat idea, or am I crazy?

Jamie



Subject: Three Proposals for Future Core War Standards
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Organization: Vanderbilt University School of Engineering, Nashville, TN, USA
Date: 17 Nov 91 02:09:41 GMT
Message-ID: <1991Nov17.020941.2742@vuse.vanderbilt.edu>


In response to an earlier post in which the author describes his experience
with the invincible "SPL 0" bomb [sorry, I cannot quote the article since it
already expired on our machine], I am posting the "Three Proposals for
future Core War Standards" by Jon Newman (jonn@microsoft.com). This piece
appeared in the Winter 90 issue of the newsletter and is reprinted here
slightly excerpted. I hope this fuels further discussions on how the current
Core War standard could evolve.

---ARTICLE------------------------------------------------------------------
        Three Proposals for Future Core War Standards
        by Jon Newman

        These proposals address some problems with past and current
        standards and the kinds of fighter programming they promote.  I have
        not implemented or tested the last two, and cannot recommend that
        they be adopted without some practical experience.  [ps: I have
        implemented them but have not done significant fighter development
        on them.]


        (1)  The Process Count Modification

        Most simulators specify a maximum number of processes on a side,
        either explicitly or implicitly (through limited available memory).
        However, the ICWS '88 standard assumes that the number of processes
        on a side is unbounded, or at least does not specify program
        behavior when this limit is reached.  This modification provides a
        sound basis for the practically necessary process count limitation;
        in effect, it codifies the behavior of existing simulators.  The
        modification is trivial;  when a fighter is loaded into memory, a
        maximum process count for that side is explicitly or implicitly
        provided.  When the number of processes on that side is at the
        limit, the SPL instruction has no effect;  no new process is
        created, and the existing process continues with the next
        instruction.  No additional syntax is provided for a fighter program
        to supply its own maximum process count;  maximum process count is a
        constant for the tournament.


        (2)  The Address Space Modification

        Since the '87 contest, we have seen that many or most successful 
        fighters are entirely stationary; they do not move around in core, 
        nor do they split off new processes.  These fighters are effective 
        because they spend all of their time attacking and none copying 
        themselves, and because they present a small target;  they can be 
        killed with one hit, but then almost any program can be completely 
        disabled with one hit by a SPL 0,0 bomb.  While such fighters are 
        entirely legal, I find them rather less interesting than programs 
        like MICE.  The address space modification forces programs to move 
        around in core in order to seek out and destroy their opponents.  
        The address space modification is simple, and requires no changes in 
        the REDCODE language.  Instead of allowing any operand to address 
        any location in core, we restrict operand fields to some smaller 
        range.  For example, with CORESIZE=8192 and ADDRESS_SPACE=2048, 
        operand fields would be restricted to the range -1024..1023;  if we 
        add #1 to DAT -1,1027, the result is DAT 0,-1028.  As usual, all 
        address arithmetic is modulo CORESIZE.  The effect of this 
        modification with these parameters is that any instruction can only 
        directly access 1/4 of the core array, or 1/2 of the core array 
        using indirection;  if a program intends to seek out opponents 
        anywhere in core, it will have to copy itself around or split off 
        new processes in other locations.  Why is this modification called 
        "address space"?  Many real computers distinguish between their 
        "logical" address space (the memory which can be addressed by a
        program) and their "physical" address space (the amount of RAM
        actually available in the computer).  Typically, the "logical"
        address space is larger;  if a program references a logical location
        which is not currently available in physical memory, that
        information is brought into physical memory from backing store
        (usually a fast disk).  (I am vastly oversimplifying.)  Our
        modification to Core War follows this model, except that the 
        "physical" address space is larger than the "logical" address space;  
        from any given memory location, there are certain other memory
        locations for which there is no logical address.


        (3)  The Descendant Count Modification

        Under current and prior standards, any process can split off an
        arbitrary number of processes (up to the process count limit).  This
        gives spl 0,0 bombs and vampiric capture devastating effect;  such
        attacks can effectively halt all processing on a side, even by
        processes which were not directly hit.  The Descendant Count
        Modification is intended to limit the effectiveness of these attacks
        somewhat, by allowing a side to specify the maximum number of
        descendants of any new process.  This modification is highly
        experimental;  I cannot claim to really know how it will behave.
        When a new process is created, the B-operand of the SPL instruction
        specifies the maximum number of descendants of the new process.  We
        maintain a "tree" of existing processes and their associated
        descendant count limits, where this tree structure is separate from
        the process queue.  If creating a new process would violate the
        descendant count limit of the parent process, or of its parent
        process, etc., then no new process is created.  When some process X
        dies, its children become the children of X's parent.  The
        descendant count limit of the original process is MAXINT; all "root"
        processes are logically children of an imaginary "super-root" with a
        descendant count limit equal to the process count limit.  Note that
        any process can change its process count limit by splitting off a
        new process and then committing suicide, provided it can split off
        another process.

-----END OF ARTICLE---------------------------------------------------------

I know of two Core War systems that implement these, at least to me, highly
sensible extensions to the current Redcode standard.

The first is Jon Newman's Core! for the Macintosh (available at
sumex-aim.stanford.edu as info-mac/games/core11.hqx). The second is V3.0 of
my own Core War system for the PC (available shortly at soda.berkeley.edu as
pub/corewar/{incoming|systems}/corwp30.zip.

-Stefan
-- 
Stefan Strack, PhD {stracks@ctrvax|stst@vuse|stst@dmwsun.hh}.vanderbilt.edu
Dept. Pharmacology, Vanderbilt Univ., Nashville, TN 37232-6600, USA
Voice: +615-322-4890, Fax: +615-343-6532
"Real men don't use icons"



Subject: Robopolis (I think)
From: stig@Lise.Unit.NO (Stig Hemmer)
Organization: Anarchy
Date: 17 Nov 91 15:13:24 GMT
Message-ID: <1991Nov17.151324.19395@ugle.unit.no>

In an ancient issue of Scientific American (which I have lost, sigh) I
read about a computer game called (I believe) Robopolis.

In this game you played a human that tried to penetrate a
robot-controlled city. To do this you programmed you thrusty three
robots to do your tasks for you, then climbed into one of them and
pressed the start button. (Sounds familiar?)

The interesting thing about this game was that you programmed your
robots using digital circuit logic. You assembled an infinte supply of
AND, OR and NOT gates to do what you wanted. You could also burn ICs
containing a standardized piece of circuit and then use many copies.

Has anyone seens this game or anything like it?
Is it interesting?
Is a PD version available for X11?

Any info appreciated!

Stig 'Tortoise' Hemmer   aka   stig@lise.unit.no
I'm a member of The League for Programming Freedom. I'm also a soldier
of the Norwegian Army. (No comparison intended)
Contact the League at league@prep.ai.mit.edu.



Subject: Re: King of the hill.
From: boutell@brahms.udel.edu (Thomas B Boutell)
Organization: University of Delaware
Date: 17 Nov 91 16:05:14 GMT
Message-ID: <25857@brahms.udel.edu>

Sounds like an excellent idea. I might even be able to help a bit in the
implementation of such a creature (limited time, but I've done some of
this kind of stuff before). I'd love to see such a server set up.

-- 
Tom Boutell, President, the Technology House, University of Delaware.
(Have a similar resident group at your school? Please contact me!)
"The universe of discourse for this problem is... uh... this room?"
Internet: boutell@freezer.cns.udel.edu



Subject: Re: Robopolis (I think)
From: tazzzzz@caen.engin.umich.edu (Kevin Dangoor)
Organization: caen
Date: 18 Nov 91 01:15:50 GMT
Message-ID: <5Hk_D_+@engin.umich.edu>

The game to which you are referring is Robot Odyssey I, by the
Learning Company. TLC also makes such classics as Rocky's Boots
and Gertrude's Secrets. Gertrude's Secrets is made for toddlers,
Rocky's Boots for middle schoolers, and Robot Odyssey for high
schoolers and up. Robot Odyssey is a GREAT game, and I highly
recommend it to anyone. I've only seen it for the Apple II, but
I've heard it's also available for the IBM. I've never solved
it, but I've gotten close.



Subject: Re: King of the hill.
From: tiktok@milton.u.washington.edu (steve feldon)
Organization: University of Washington
Date: 18 Nov 91 05:24:41 GMT
Message-ID: <1991Nov18.052441.5791@milton.u.washington.edu>

One thing I'd like to see, regarding this MARS server, would be a
hierarchy, instead of a single champion.  I imagine five or ten
programs in a "top ten list," with new challengers starting at the
bottom, and eventually being placed above the last one they beat.
This would keep the new "king of the hill" from just being a
specialized program designed to defeat the previous champ; every
champion would have beaten ten other programs straight to get to the
top. 

Maybe even best two of three?  :)

steve

-- 
==============================================================================
Steve Feldon             | These are MY ideas | "Don't stop thinking about
tiktok@u.washington.edu  | and opinions. :-]  |  tomorrow." - Fleetwood Mac



Subject: EBS Tournament Results
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: 18 Nov 91 07:23:09 GMT
Message-ID: <91322.01:23:09.759108.DURHAM@ricevm1.rice.edu>

Here are the results from the first four rounds of the Electronic Branch
Section's ICWS Qualification Tournament.

First, some general information about the tournament(s).  The ICWS
tournament is traditionally run under the following conditions:

a) Standard: ICWS'88
b) Core Size: 8192
c) Maximum Number of Cycles before declaring a tie: 100 000
   (a machine cycle executes one instruction from each warrior)
d) Maximum Number of Tasks per warrior: 64
e) Warrior Size Limit: 64 instructions (1/128th of core size)
f) Six rounds of one-on-one, round-robin play.  Each warrior plays three
   rounds as the initially executing warrior, three mirror rounds as the
   warrior executing second.  Three load addresses are chosen at random
   such that the second warrior starts loading no closer than 64
   instructions (1/128th of core size) to the first.
g) Scoring is 3 points for a win, 1 point for a tie, and no points for
   a loss.
h) The program with the best total score is declared the tournament winner.

This EBS tournament is being run under the same conditions with the
following exception.  In the EBS tournament, a warrior will also play
against itself.  This is due to the observation that a warrior which
can beat itself will score 3 points for the win/loss combination,
whereas a warrior which merely ties itself only scores 2 points for
two ties.

The top ten finishers from the EBS tournament will advance to the ICWS
tournament.  Unfortunately, due to the limited number of entries and
a restriction of two submissions from an individual -- we only have
seven warriors eligible to advance at this time.  If anyone who has
not already entered would like to do so, please EMail your entry to
me ASAP.  I will automatically advance the first three submissions from
different individuals (with the following caveat).

Due to the vast amount of mail generated by the discussion and voting
for rec.games.corewar, I may have misplaced entries to the EBS tournament.
If you submitted an entry and you do not see it listed below, please
resend it to me.  Your entry will of course take precedence over any
others.  In fact, I'll give up my spot if necessary.  My sincere and
heartfelt apologies.

As long as I am apologizing, let my send my regrets to those of you who
were not aware of the EBS tournament.  The timing is awful, but necessary
as the ICWS deadline (set over half a year ago) is near.  But do not
despair!  We are having a net-wide tournament February 14th, 1992.  The
conditions will be as they are listed above.  So get those Redcode
programs ready.

The programs (in alphabetical order) and their authors:
   DAC (Divide And Conquer) by Mark A. Durham
   Dervish by D. Bofinger
   Influenza by D. Bofinger and T. S. Allen
   Mr. Nasty by Kurt Werle and Stephen Beitzel
   Quarter by Stefan Haenssgen
   Sonic by D. Bofinger
   Spider by Morten Due Joergensen
   Vlad by D. Bofinger and T. S. Allen
   XTC by Stefan Roettger

For those of you who bothered to count, yes there are nine programs.
Because of the limited number of submissions, I decided to let all four
of Mr. Bofinger's submissions participate.  Only the top two finishers
submitted by Mr. Bofinger will be advanced to the ICWS tournament however.

Round one took place with the initial program starting at location zero
and the challenger at location 4938 (chosen at random by my computer).
The second round reversed the two programs.

The scores (in order of finish, top to bottom):

    Name         Total (3W + T)    Wins Ties  Losses
    ----         -----             ---- ----  ------
   Quarter        40                13    1     4
   Sonic          39                13    0     5
   XTC            37                12    1     5
   Vlad           33                11    0     7
   Influenza      28                8     4     6
   DAC            24                7     3     8
   Mr. Nasty      18                6     0     12
   Spider         11                2     5     11
   Dervish        5                 1     2     15

Rounds three and four took place with the one program starting at location
zero and the other at location 6699, then reversing.

The scores (in order of finish, top to bottom):

    Name         Total (3W + T)    Wins Ties  Losses
    ----         -----             ---- ----  ------
   XTC            45                15    0     3
   Quarter        35                11    2     5
   Vlad           33                11    0     7
   Sonic          30                10    0     8
   Mr. Nasty      27                9     0     9
   DAC            24                7     3     8
   Influenza      23                6     5     7
   Spider         10                1     7     10
   Dervish        6                 1     3     14

Current Standings (in order of finish, top to bottom):

    Name         Total (After four rounds)
    ----         -----
   XTC            82
   Quarter        75
   Sonic          69
   Vlad           66
   Influenza      51
   DAC            48
   Mr. Nasty      45
   Spider         21
   Dervish        11



Subject: Re: Three Proposals for Future Core War Standards
From: orb@ccwf.cc.utexas.edu (Norman Richards)
Organization: The University of Texas at Austin, Austin TX
Date: 18 Nov 91 15:08:36 GMT
Message-ID: <62132@ut-emx.uucp>

In article <1991Nov17.020941.2742@vuse.vanderbilt.edu> stst@vuse.vanderbilt.edu (Stefan Strack) writes:
>
> I am posting the "Three Proposals for future Core War Standards" by
> Jon Newman....

>---ARTICLE------------------------------------------------------------------
>        Three Proposals for Future Core War Standards

 Is there any way for a program to know what this value is?
 Obviously - you could manually fine-tune a fighter with regards to 
tournament constants each time, but then the fighter tends to be less 
effective in other environments.  I'm not exactly sure HOW this info
would be helpful, but I'm sure someone could think of something.       

>        (2)  The Address Space Modification
 I really like this idea because it gives your programs freedom to be more
creative.  Its really hard to design with any kind of realism against some
kind of brute force attack.  The only alternative I have seen work is to use 
a REALLY big core and then something thst just randomly bombs every square, or 
even uses some sort of pattern, only wins out of luck.

>        (3)  The Descendant Count Modification
  Again - what about some way of reading these values - especially current
# of subprocesses.  For instance - if a program knew that the number of
subproccesses was higher than it should, it could deside to go on some other 
course of action or not.  Again - I dont know how useful this could be, but.
;)  Actually - you could write a program that tries to get the enemy to
execute your code.  Then - a knowledge of the number of subprocesses 
allowed would be of strategic importance.  I am not sure if I understand
the idea behind the part about what happens when a process is killed.  The
subprocess revert to the old parent processes parent process, right?  Well,
then it would be incredibly useful to know how many processes you have -
so you can know how many to allocate to a SPL. :)

 Sorry I didnt quote the original article - but it was too much quote for my
news program and I couldnt decide what was important enough to keep - so I
deleted it all!  :)
 Later...

______________________________________________________________________________
orb@ccwf.cc.utexas.edu              "Two roads diverged in the forest
                                     And I - I chose to climb the nearest tree.
                                     And that has made all the difference."



Subject: Re: King of the hill.
From: cyoon@utdallas.edu (Chang K. Yoon)
Organization: Univ. of Texas at Dallas
Date: 18 Nov 91 16:04:31 GMT
Message-ID: <1991Nov18.160431.4525@utdallas.edu>

That would actually be fun.. Hmm... We could get a system up that automatically
reads in the mail file, finds a string and begins reading from there (In a
specified format of course) and then continues until and end string is reached.
For example, we could use a format similar to this:

<header information.  This is striped by the automatic reader>

#N Chang Yoon
#A cyoon@utdallas.edu
#R impthing.rc
#BEGIN_CODE
<code placed here>
#END_CODE

It would not be dificult to write a program that would take in a mail file and
begin reading this information and putting it into a file..  Any other
suggestions?


-------------------------------------------------------------------------------
Chang Yoon                            |  DISCLAIMER:  My thoughts (and no one
cyoon@utdallas.edu                    |  else's)
-------------------------------------------------------------------------------
   "Our children know EVERYTHING, we have cable."  -  Ms. Penbroke, C 'n C
-------------------------------------------------------------------------------



Subject: Some *simple* (beginner) questions...
From: hysky@polaris.utu.fi (j.h.husgafvel)
Organization: University of Turku, Finland
Date: 18 Nov 91 22:19:41 GMT
Message-ID: <hysky.690502781@polaris>


I have some (probably silly) questions about Core War. I'm trying to 
implement this game on my Port Folio but there are a couple of things
I really don't understand.

I gather that every instruction is one memory cell. So: what does imp
`MOV 0 1' do? Does it copy the whole cell (instruction, A-field and 
B-field) or what????

How is for ex. `DAT #? #?' represented in MARS?? Can I MOV something to become
some other instruction (`MOV #? p  => p:   spl #0')?????

I have tried to study the redcode.c posted here a while ago but I still
don't understand it (comments would help even though C is self-documented ;-)



Thanks in advance,
--
/Hysky     hysky@polaris.utu.fi (j.h.husgafvel)
Have you tried McSquared, the pure energy fast-food?



Subject: Re: Robopolis (I think)
From: nagle@netcom.COM (John Nagle)
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
Date: 18 Nov 91 23:39:02 GMT
Message-ID: <1991Nov18.233902.20258nagle@netcom.COM>

stig@Lise.Unit.NO (Stig Hemmer) writes:

>In an ancient issue of Scientific American (which I have lost, sigh) I
>read about a computer game called (I believe) Robopolis.

>The interesting thing about this game was that you programmed your
>robots using digital circuit logic. You assembled an infinte supply of
>AND, OR and NOT gates to do what you wanted. You could also burn ICs
>containing a standardized piece of circuit and then use many copies.

    This is "Robot Odyssey", from the Learning Company, 545 Middlefield
Road, Suite 170, Menlo Park, CA 94-25  (415)-328-5410.  (The address
and phone number may be outdated.)  It's a 1985 PC product, and rather dated.
CGA graphics.  "For sharp teens and adults".  The concept of a game for 
teaching digital logic design is kind of neat.  It even uses the 
standard logic symbols, and you get to see the circuit run animated,
with the lines changing color as signals go HIGH and LOW.  As a means of
controlling a robot, it's lousy, though.

     Egghead Discount Software can probably get you a copy.

>Is a PD version available for X11?
      Very unlikely.  But it's cheap.

					John Nagle



Subject: Re: Three Proposals for Future Core War Standards
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Organization: Vanderbilt University School of Engineering, Nashville, TN, USA
Date: 19 Nov 91 01:13:00 GMT
Message-ID: <1991Nov19.011300.6327@vuse.vanderbilt.edu>

In article <62132@ut-emx.uucp> orb@ccwf.cc.utexas.edu (Norman Richards) writes:
>In article <1991Nov17.020941.2742@vuse.vanderbilt.edu> stst@vuse.vanderbilt.edu (Stefan Strack) writes:
>[...]
>>        Three Proposals for Future Core War Standards
>>        by Jon Newman
>
> Is there any way for a program to know what this value is?
> Obviously - you could manually fine-tune a fighter with regards to 
>tournament constants each time, but then the fighter tends to be less 
>effective in other environments...

Should these modifications actually find their way into a future standard,
I'm sure the values for the three parameters will be standardized as well,
at least for tournaments. I agree however that, until such time, it would
be nice if the program was "aware" of the conditions of the fight, so that
we could experiment with different values for "Process count", "Address space"
and "Descendant count" without a complete rewrite of the warrior's code.

It's relatively easy to adapt a program to the current MARS state: A lot
of system already provide warriors with information about the current
size of the Core array through a "system variable", called, say CORESIZE.
Similarly, we can just allow Redcode programs to refer to PROCESS_COUNT,
and ADDRESS_SPACE. In my system, you could write something like:
	process_distance EQU (ADDRESS_SPACE / 4)
to set the distance between copies of a self-copying program to 1/4th
of the current value for "Address space".

># of subprocesses.  For instance - if a program knew that the number of
>subproccesses was higher than it should, it could deside to go on some other 
>course of action or not....

That's trickier, because we're no longer dealing with a constant that can
be inserted into the program code at load time. Besides, it seems to go
against the "spirit of Core War" to provide programs with the info how
many processes it has currently executing. Then you might as well allow
programs to find out their *absolute* address in Core; I'm sure this would
also be "incredibly useful" :-)

>orb@ccwf.cc.utexas.edu              "Two roads diverged in the forest

-Stefan

-- 
Stefan Strack, PhD {stracks@ctrvax|stst@vuse|stst@dmwsun.hh}.vanderbilt.edu
Dept. Pharmacology, Vanderbilt Univ., Nashville, TN 37232-6600, USA
Voice: +615-322-4890, Fax: +615-343-6532
"Real men don't use icons"



Subject: Hardware implementation of corewar
From: mjmccut@cs.ubc.ca (Mark McCutcheon)
Organization: University of British Columbia, Vancouver, B.C., Canada
Date: 19 Nov 91 02:28:40 GMT
Message-ID: <1991Nov19.022840.2225@cs.ubc.ca>


I'd guess that every hardware hacker who ever wrote a Redcode program has sketched out the requirements of an actual corewar processor.  But then you realize that even a virtual machine can be written to run the code faster than you can really watch it, s
o what's the point of doing it in hardware?  Might make an interesting undergrad project in an EE class, though!

Mark McCutcheon / UBC CS-EE



Subject: Re: Hardware implementation of corewar
From: mrhoten@Neon.Stanford.EDU (M Paul Rhoten)
Organization: CS Department, Stanford University, California, USA
Date: 19 Nov 91 07:43:41 GMT
Message-ID: <mrhoten.690536621@Neon.Stanford.EDU>

mjmccut@cs.ubc.ca (Mark McCutcheon) writes:
>[...] even a virtual machine can be written to run the code faster
than you can really watch it, so what's the point of doing it in
hardware?

What if you wanted to run two programs exhaustively -- either using
every possible initial starting configuration, or doing a Monte Carlo
run on the programs? In this case, even 100,000 instructions per
second is a little too slow. If you wanted to run many programs against
each other exhaustively, the time constraints get even worse.

To answer a few other questions I've seen here, descriptions of the
1986 and 1988 Redcode standards, as well as a unix and a PC
MARS implementation, are available from soda.berkeley.edu via
anonymous ftp. A Macintosh MARS implementation is available from
sumex.stanford.edu and wuarchive.wustl.edu (to name a few) via
anonymous ftp.

 -matt
-- 
Matt Rhoten | mrhoten@cs.stanford.edu    | m_rhoten@leland.stanford.edu
70701 357   | PO 10031/Stanford CA 94309 | veni, vidi, vomui.



Subject: Hardware implementation of corewar
From: mjmccut@cs.ubc.ca (Mark McCutcheon)
Organization: University of British Columbia, Vancouver, B.C., Canada
Date: 19 Nov 91 17:40:29 GMT
Message-ID: <1991Nov19.174029.18042@cs.ubc.ca>


OK, you've come up with a situation in which a hardware implementation
might be of use.  I find it a little difficult to imagine *wanting*
to use every possible initial configuration of a Redcode program, but
if you did, I guess it would be nice to do it at hardware speeds.

Mark McCutcheon / UBC CS-EE



Subject: Re: Hardware implementation of corewar
From: jmason2@gpu.utcs.utoronto.ca (Jamie Mason)
Organization: University of Toronto Computer Services Advisor
Date: 20 Nov 91 02:10:26 GMT
Message-ID: <1991Nov20.021026.17403@gpu.utcs.utoronto.ca>

mjmccut@cs.ubc.ca (Mark McCutcheon) writes:
>OK, you've come up with a situation in which a hardware implementation
>might be of use....

	How about	F U N ?

	Hardware is FUN.  Corewar on real CORE would be lotsa fun.  I'm
not talking about a VLSI implmentation, I'm talking about a breadboard
hack.

	Naturally, I want to control the clock rate manually.  That is
either a clock switch to press, a "crank" which gives, say 30 clocks per
revolution, or a dial (pot + AtoD) which selects the clock speed
(exponentially?).

	Wouln't it be fun to load the warriors into the CORE, then
sit there with your finger on the clock switch:

	Clock...  Clock...  Clock... Clock... Clock...
	[etc...]
	Clock... Clock...  Ha!  You die next cycle you
	stupid IMP.  Clock!

	I think that would be LOADS of fun!


	Doesn't anyone here share my fascination with good 'ol
hardware hacking?

Jamie ... char *i; main(){for (i=(char *) malloc(31457280);;*(i+=4096)=1);}
Written On  Tuesday, November 19, 1991  at  09:02:14pm EST



Subject: Re: PCT, cw for mac, Three Proposals for Future Core War Standards
From: jonn@microsoft.com (Jon NEWMAN)
Organization: Microsoft Corp.
Date: 20 Nov 91 00:01:59 GMT
Message-ID: <1991Nov20.000159.1920@microsoft.com>

I'll respond to all three of these, plus give an update on the ICWS.

First, regarding PCT:  This was an early attempt to make more survivable
programs.  When you PCT a location, that cell enters the "protected"
state.  The first write to that location will not change the cell contents,
but will only de-protect the location.  Some early simulators supported this
opcode, in particular the Robert Martin simulator for the Mac, but it has
never been part of the ICWS standard.

Second, regarding Core War for the Mac:  If you can't get this from
sumex-aim.stanford.edu or from the mailer daemon at LISTSERV@ricevm1.rice.edu,
contact me via email or at One Microsoft Way, Redmond WA 98052-6399.  A
quick plug:  Core! 1.1 supports up to four fighter programs, simultaneous
editing, breakpoints, color, '86 and '88 ICWS standards plus optionally
the Three Proposals for Future Core War Standards, color on color macs,
System 7, and generally more features than you can shake a stick at.  All this
for only US$14 plus US$3 if I have to mail it to you.  What a deal!

Third, regarding the Three Proposals:  These are just trial balloons and
I am certainly open to suggestions.  Concerning process count and coresize,
I suppose we could preset a define to these values and let programs access
them at load time; however, many programs have dependencies on coresize
factoring (divisible by 5? divisible by 12?) and will only work for certain
coresizes.  Concerning descendant count, I don't know what a fighter could
do with this information unless it had some special instruction to kill all
its children.  Try these out and see if you can do anything interesting
with them!

Finally, concerning the ICWS itself:  I apologize to all of you who have
asked about the ICWS and been told to wait.  As soon as I have obtained the
membership information from the previous Director, I will post information
about the ICWS and its activities.  Until then, please be patient.


Jon Newman
jonn@microsoft.com
-- 
jonn@microsoft.com    

This is not the official opinion of Microsoft Corporation.  Bill Rules!



Subject: Extension to Redcode
From: mochang@aludra.usc.edu (Morrison J. Chang)
Date: 17 Nov 91 05:57:22 GMT
Message-ID: <21643@chaph.usc.edu>

The one problem that I see with the current standards of Redcode is
that at some point all of the efficent programs get written. MICE can
kill a certain set which can be killed by SPL 0 bombers which in turn
may be killed only by ones of a similar class or by something simple
like DWARF which can be killed by MICE and so on.  The question is 
of course, have all of the efficent programs been written or their classes
defined such that either any new program can be killed, most of the time
or is a subset of a defined class or classes i.e. clone programs, SPL/DAT
bomber etc...

Whew, sorry about all that. Now that I look at it again there are some
holes in my logic, but I'll just leave it in anyway.
 
Well my idea for changing Redcode is to make instructions execute with
different cycles.   I liked the idea of having a difference between
near and far instructions so that a MOV instruction within 256 locations
gets executed in less cycles than a far MOV. Has anyone implemented
this idea? (this system is incompatable with ICWS '86 or '88 unfortunately
since both standards execute instructions in only one cycle)


-- Morrison J. Chang
-- mochang@chaph.usc.edu
-- yeah, CHANG1 is mine, I'm still looking for someone who has a name
   close to the one I have...



Subject: Re: Wanted:  Help!  : )
From: cpbeaure@descartes.waterloo.edu (Chris Beauregard)
Organization: University of Waterloo
Date: 20 Nov 91 06:00:59 GMT
Message-ID: <1991Nov20.060059.7931@descartes.waterloo.edu>

In article <13241@plains.NoDak.edu> myhre@plains.NoDak.edu (Rezh - Chin Na (aka Robert Myhre)) writes:
>
>  For years I have been hearing about core wars... ever since I had my trusty
>C64.  Well, this newsgroup comes along and within hours I have a copy of the
>corewars processor and arena.  Little did I know what I was getting myself
>into.  :)

  Yes, innocent little concept, isn't it?  <Aside:  Little does he know that
the obsession will grow, and grow, and...you get the idea, until it becomes the
focal point in his life, even eclipsing reading news, and he becomes <horror
music, lightning, thunder, shower of rain> A CORE WAR JUNKY!!!>

>  My question:  are there any GOOD files or programs that show you exactly
>how to start programming in redcode.  Of particular interest would be something
>with detailed examples of what exactly is happening.  Running the examples
>that came with CoreWar Pro did little to help me understand it.

  Sigh.  I tried writing something like this a while back, just for the sake
of getting all my various ideas down in...virtual ink.  This was way before
I'd even heard of Internet and sush.  Anyway, if I would have finished, it
would have been _big_.  There are more ideas for making Core War fighters
than you can shake a light pen at.  And if you want to throw in examples,
special cases, etc, it gets bigger.  I think I had a list of things that I
wanted to include in the document that was about three pages long.     

  It's kind of amazing that a dozen little assembly language operations can
do things like this, isn't it?

  I would be very interested in what other people have written on this.  In
fact, it would make a really good project for rec.games.corewar to put
a sort of guide to Core War ideas document, and occasionally update it for
new ideas, implementations, etc.  I mean rec.games.frp has their net.*.books,
rec.pyrotechnics has TBBOM, and rec.games.design have their major project
(to name a few I know of) so why not?

  I don't volunteer to keep the thing though.  I have a whole 1 meg of disk
space available to me, and I just don't think I could handle something the
size this could become...

>  If this doesn't exist... is there anyone out there that would like to give
>me some help... either private or via r.g.cw?  If this is the case I would be
>more than happy to create a good tutorial as I learn.  Thanks

  Just post your problems.  Given the volume of messages asking what Core War
is,  there's probably a good number of people also wondering what they can do
with the thing.  And besides, even the "veterans" might learn something...

-------------------------------------------+---------------------------------  
Chris Beauregard                           | If all the world's a stage, what
cpbeaure@descartes.waterloo.edu            | do we do when the audience starts
"If you can't beat 'em, take 'em with ya!" | throwing stuff?



Subject: Validation Suite for ICWS'88 Compatibility
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: 20 Nov 91 07:44:14 GMT
Message-ID: <91324.01:44:14.698697.DURHAM@ricevm1.rice.edu>

Almost from the begining of Core War, there have been calls for a
validation suite of Redcode programs.  With the vast proliferation of
Core War systems, it is becoming a much higher priority.  So, I have
started such a validation suite.

I welcome any assistance anyone offers in the way of interesting
programs which are likely to ferret out errors in MARS interpretation.
Note that the very little bit I have included here starts from DAT #0, #0
and builds from there.

There is only one program with truly interesting behaviour (PVS #7).
At first you might expect it to terminate on the second cycle, but it
actually takes three cycles for it to terminate.

Comments on the format are welcome as well.  You should be able to
cut and paste and assemble these programs directly.

Enjoy,
MAD

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

; Proposed Validation Suite for ICWS'88 Memory Array Redcode Simulators
; ---------------------------------------------------------------------
;         Author(s):   Mark A. Durham
; Last Modification:   November 19, 1991

; Subscripts indicate changes in modes which do not change program
; behaviour.  $ is used to mean direct mode for clarity.

; ---------------------------------------------------------------------

; PVS #1

start   DAT     #0,     #0
        END     start

; Result: Failure on first cycle at start
; Memory: Unchanged

; ---------------------------------------------------------------------

; PVS #2(a-d)

start   DAT     #0,     <1
change  DAT     #0,     #2      ; b(#,<) c(<,#) d(<,<)
        END     start

; Result: Failure on first cycle at start
; Memory: change becomes DAT #0, #1 (one less than 2)

; ---------------------------------------------------------------------

; PVS #3(a-d)

start   DAT     <1,     <1
change  DAT     #0,     #3      ; b(#,<) c(<,#) d(<,<)
        END     start

; Result: Failure on first cycle at start
; Memory: change becomes DAT #0, #1 (two less than 3)

; ---------------------------------------------------------------------

; PVS #4(a-c)

start   JMP     0,      #0      ; b($,$) c($,@)
        END     start

; Result: No failure
; Memory: Unchanged

; ---------------------------------------------------------------------

; PVS #5(a-d)

start   JMP     1,      <2
stop    DAT     #0,     #0
change  DAT     #0,     #2      ; b(#,<) c(<,#) d(<,<)
        END     start

; Result: Failure on second cycle at stop
; Memory: change becomes DAT #0, #1 (one less than 2)

; ---------------------------------------------------------------------

; PVS #6(a-c)

start   JMP     @0,     #0      ; b(@,$) c(@,@)
        END     start

; Result: No failure
; Memory: Unchanged

; ---------------------------------------------------------------------

; PVS #7(a-b)

stop    DAT     #0,     #2      ; b(<,#)
start   JMP     @0,     <0
        END     start

; Result: Failure on THIRD! cycle at stop
; Explanation: The A-field of JMP @0, <0 is evaluated BEFORE the
;         B-field, and therefore the effective A-address is zero for the
;         first cycle.  The next cycle, the instruction is JMP @0, <-1.
;         Again, the A-field is evaluated BEFORE the B-field, and
;         therefore execution is transferred to stop after its B-field
;         is decremented.
; Execution: start, start, stop
; Memory: start becomes JMP @0, <-1 (one less than 0)
;         stop becomes DAT #0, #1 (one less than 2)

; ---------------------------------------------------------------------

; PVS #8(a-i)

start   JMP     <2,     #0      ; b,d,f,h(<,$) c,e,g,i(<,@)
stop    DAT     #0,     #0
change  DAT     #0,     #0      ; b,c(#,#) d,e(#,<) f,g(<,#) h,i(<,<)
        END     start

; Result: Failure on second cycle at stop
; Memory: change becomes DAT #0, #-1 (one less than 0)

; ---------------------------------------------------------------------

; PVS #9(a-d)

start   JMP     <2,     <2
stop    DAT     #0,     #0
change  DAT     #0,     #1      ; b(#,<) c(<,#) d(<,<)
        END     start

; Result: Failure on second cycle at stop
; Memory: change becomes DAT #0, #-1 (two less than 1)

; ---------------------------------------------------------------------



Subject: EBS tournament entry
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: 20 Nov 91 08:16:43 GMT
Message-ID: <91324.02:16:43.756304.DURHAM@ricevm1.rice.edu>

Here is my entry into the EBS tournament.  It did not do as well as
I would have liked, and therefore I expect it will not do well in the
ICWS tournament December 15th.  Thus, I have little to lose by posting
it here now.  I will post the others after the ICWS tournament.

Looks like I need to spend more time working on my Redcode and less
on rec.games.corewar!

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

; Divide And Conquer
;
; Mark A. Durham
; November 1, 1991

; Code

         JMP   start                         ; In case END start fails

; This code copies the warrior and splits the copy

source   DAT   #target
start    MOV   #trap-source,        source   ; Init copy pointer
         MOV   #2432+source-trap,   target   ; Init destination pointer
copy     MOV   @source,             <target  ; Copy warrior
         DJN   copy,                source
         SPL   @target                       ; Start copy of warrior

; This code traps and kills potential enemy code

         MOV   #164,               target
enslave  MOV   trap,                @target
         DJN   enslave,             target

         MOV   #164,               target
kill     MOV   target,              @target
         DJN   kill,                target

target   DAT   #2432+source-target            ; Kill self when finished
trap     SPL   trap
         END   start



Subject: ICWS 88?
From: shectman@husc10.harvard.edu (nicholas shectman)
Organization: Harvard University Science Center
Date: 20 Nov 91 10:53:06 GMT
Message-ID: <1991Nov20.055307.5658@husc3.harvard.edu>

Forgive me if this has been posted before, but I'm looking for a copy
of the ICWS 88 redcode definition.  See, back around '87 or so, I wrote
a version of MARS from the description of redcode in the scientific 
american article, which is vague on some important addressing and process
handling points.  I decided to make processes execute round-robin in the
way that someone recently described in this group, and wrote an ownership
algorithm that let victory be declared for program A even if stolen processes
were still running in A's trap.  I also had absolute addressing according to
this kind of ownership rather than by process ownership, something which I
suspect is not entirely kosher.  My program was written in interpreted basic
for an IBM PC with cga graphics and was written over a weekend (this was back
before I, a lowly high school student, had access to any fancy compilers).
It simulated a 16-bit Redcode machine with 1K of cells.  There was no 
assembler or editor.  There was no process limit.

I then wrote a 12-line program that beat the living shit out of anything
I could throw at it, defeating MICE in a few hundred cycles.  I'm actually
far more interested in the standard to see about entering this program
in contests than for checking the correctness of my MARS program.

If someone could point me to a print article describing redcode in a more 
complete way, or email me an electronic version of such an article, I'd much
appreciate it.

advTHANKSance,
					-/phi



Subject: Re: Validation Suite (Ooops!)
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: 20 Nov 91 17:32:09 GMT
Message-ID: <91324.11:32:09.975955.DURHAM@ricevm1.rice.edu>

Please ignore PVS #9.  The description of its behaviour is completely
incorrect.  I was so preoccupied with #7 that I missed the fact that
#9 is a variant and exhibits the same kind of (unexpected?) behaviour.

My sincere thanks to Harri Haanp <f40661b@saha.hut.fi> for catching
this blatant error.

I hope this example shows both how important and how difficult a
validation suite is to write.

MAD



Subject: Re: Three Proposals for Future Core War Standards
From: orb@ccwf.cc.utexas.edu (Norman Richards)
Organization: The University of Texas at Austin, Austin TX
Date: 21 Nov 91 04:49:58 GMT
Message-ID: <62378@ut-emx.uucp>

In article <1991Nov19.011300.6327@vuse.vanderbilt.edu> stst@vuse.vanderbilt.edu (Stefan Strack) writes:
>In article <62132@ut-emx.uucp> orb@ccwf.cc.utexas.edu (Norman Richards) writes:
>># of subprocesses....
>
>That's trickier, because we're no longer dealing with a constant that can
>be inserted into the program code at load time. Besides, it seems to go
>against the "spirit of Core War"...

 Well - it was just a suggestion.  Actually, I think it is still a fairly
good idea.  WEll - my main point is saying that if a SPL x x command is used
to specify the number of subtasks allowed to this process being split tom
then you should definately have some way of knowing how many tasks you are
dealing with.  Perhaps the idea of some sort of register variables or something?
Its an idea.  I agree with you that knowing the number of processes you are 
executing might be a little out of the "spirit of core war" but knowing your
task allotment isnt.  I suppose that this information could be passed along to
your subprecess by some means, but there are some things that just cant be 
effectively implemented in a core war instruction set without using more
instructions than a warrior is allotted.

 Later...


______________________________________________________________________________
orb@ccwf.cc.utexas.edu              "Two roads diverged in the forest
                                     And I - I chose to climb the nearest tree.
                                     And that has made all the difference."



Subject: 2 programming questions
From: orb@ccwf.cc.utexas.edu (Norman Richards)
Organization: The University of Texas at Austin, Austin TX
Date: 21 Nov 91 05:00:06 GMT
Message-ID: <62381@ut-emx.uucp>


 Ok - two quick ones:
1) has anyone found a way to effectively implement a divide?  I
don't see as how it would be that bad.  Even if it would be
slow and probably have no practical use - it would be neat to see.

2) suppose you have two memory locations - lets call them ptr1 and ptr2.  
Both are dat statements.  the first points to some address in memory.
You want the second to point to the same spot.
 mov   ptr1        tmp       
 add   #ptr2-ptr1  tmp
 mov   tmp         ptr2

 This should work, right?  Is there a faster way?

Later...
_____________________________________________________________________________
orb@ccwf.cc.utexas.edu              "Two roads diverged in the forest
                                     And I - I chose to climb the nearest tree.
                                     And that has made all the difference."



Subject: Re: 2 programming questions
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: 21 Nov 91 06:02:11 GMT
Message-ID: <91325.00:02:19.089372.DURHAM@ricevm1.rice.edu>

>>2) suppose you have two memory locations - lets call them ptr1 and ptr2.
>>Both are dat statements.  the first points to some address in memory.
>>You want the second to point to the same spot.
>>  mov   ptr1        tmp
>>  add   #ptr2-ptr1  tmp
>>  mov   tmp         ptr2

That should be add #ptr1-ptr2  tmp
            or sub #ptr2-ptr1  tmp

to work.  Anyone have a use for such two pointers which point to the
same place?  (Sounds like a really stupid question in Pascal or C, etc.
but I really can't think of a use for it in Redcode).

MAD



Subject: Re: Division
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: 21 Nov 91 06:49:27 GMT
Message-ID: <91325.00:49:27.955529.DURHAM@ricevm1.rice.edu>

To do division in Redcode, you need to go back to the fundamental
definition of division -- "How many times can you subtract y from x?".

x     DAT     #15         ; Put the numbers of your choice into x and y
y     DAT     #3
z     DAT     #0          ; z = x / y
temp  DAT     #0          ; For non-destructive division
start MOV     x,    temp  ;    copy x into temporary variable
      MOV     #0,   z     ; In case we re-use this routine
      SLT     temp, y     ; Skip next instruction if temp < y
      JMP     loop        ; If y <= x, then x / y > 0
      JMP     done        ; If y > x, then x / y = 0 (integer division)
loop  SUB     y,    temp
      ADD     #1,   z     ; Keep track of how many times we subtract y
      SLT     temp, y     ; Skip next instruction if temp < y
      JMP     loop        ; y <= temp so continue
done  ...                 ; y > temp, therefore we are done and z holds
      END     start       ;    x / y


Needless to say, division is SLOW!!!!   Multiplication can be done
in a similar way.  Sometimes you can speed up multiplication.  For
instance, to multiply 5 times x:

x     DAT     #3
temp  DAT     #0
start MOV     x,     temp         ; x
      ADD     x,     temp         ; x + x = 2x
      ADD     temp,  temp         ; 2x + 2x = 4x
      ADD     x,     temp         ; 4x + x = 5x
      ...
      END     start


Here is a challenge for all you Redcode programmers out there.
Write a Redcode program which bombs core (core size 8192) in a
pseudo-random fashion (ala linear congruential randon number
generators).  I'll print the best solution in the next TCWN
(which I will post to the net when completed).

MAD



Subject: Re: King of the hill.
From: dgg@llcn2.jhuapl.edu (Dave Gawron)
Organization: Johns Hopkins University
Date: 18 Nov 91 18:24:04 GMT
Message-ID: <1991Nov18.182404.19340@aplcen.apl.jhu.edu>

In <1991Nov18.160431.4525@utdallas.edu> cyoon@utdallas.edu (Chang K. Yoon) writes:

><header information.  This is striped by the automatic reader>

>#N Chang Yoon
>#A cyoon@utdallas.edu
>#R impthing.rc
>#BEGIN_CODE
><code placed here>
>#END_CODE

>It would not be dificult to write a program that would take in a mail file and
>begin reading this information and putting it into a file..  Any other
>suggestions?

I'd be a fan of the idea to encode all of the necessary data in the form of
standardized header and trailing comments.  Or to get fancy, you could also
strip this information from the "From:" and "Subject:" lines of a message.
Nothing would be in the body of the message except valid code.  One problem,
however, is that some people like to have signatures automatically included
in all outgoing mesages.

-Dave-



Subject: Re: Division
From: wms@iwarp.intel.com (William Shubert)
Organization: Intel iWarp, Beaverton, Oregon, USA
Date: 21 Nov 91 16:58:23 GMT
Message-ID: <1991Nov21.165823.18457@iWarp.intel.com>

Mark Durham posted:
>Write a Redcode program which bombs core (core size 8192) in a

Why this fixation on core size 8192?  As I remember, the original Scientific
American articles specified a core size of 8000, but on this board I keep
seeing references to 8192 instead.  On a binary machine this makes sense,
but (as far as I can tell) redcode has nothing to do with binary.  I
happen to prefer 8000 to 8192 also because it is more divisible, which
means there are more nifty programs you can write that use wraparounds...
for example, 8000 is divisible by 2, 4, 5, 8, 10, etc. while 8192 is only
divisible by powers of two.  Also, 8000 is a nicer, rounder number for us
humans to work with.
				-Bill (wms@iwarp.intel.com)



Subject: Re: 2 programming questions
From: cpbeaure@descartes.waterloo.edu (Chris Beauregard)
Organization: University of Waterloo
Date: 21 Nov 91 17:00:36 GMT
Message-ID: <1991Nov21.170036.13247@descartes.waterloo.edu>

In article <62381@ut-emx.uucp> orb@ccwf.cc.utexas.edu (Norman Richards) writes:
> mov   ptr1        tmp       
> add   #ptr2-ptr1  tmp
> mov   tmp         ptr2
>
> This should work, right?  Is there a faster way?

  Off hand, I think that this might work...

  mov #(ptr1-ptr2)+@ptr1   ptr2

  I'm not sure though.  I have this feeling that it would throw up on you.  
My grasp of expressions as part of Redcode operators is not phenomenal.

An alternative might also be

  mov 	ptr1	        ptr2
  add 	#ptr1-ptr2	ptr2

  Which seems to be a faster way of doing what you originally did, without the
temporary variable.

-------------------------------------------+---------------------------------  
Chris Beauregard                           | If all the world's a stage, what
cpbeaure@descartes.waterloo.edu            | do we do when the audience starts
"If you can't beat 'em, take 'em with ya!" | throwing stuff?



Subject: Can Redcode be useful?
From: consp04@bingsuna.bingsuns.cc.binghamton.edu (Dan Boyd)
Organization: State University of New York at Binghamton
Date: 21 Nov 91 17:28:25 GMT
Message-ID: <CONSP04.91Nov21122825@bingsuna.bingsuns.cc.binghamton.edu>


Redcode is apparently equal in power to a Turing machine.
Theoretically, anything that can be done by any computer, anywhere,
can be done by Redcode.

So can anyone do anything useful with Redcode?

Could anyone, for instance:

-- Compute the fibonacci series?

-- Implement a bubble sort?

-- Implement quicksort?

-- Implement a binary search?

-- Add/delete numbers to/from a linked list?

-- A hash table?

-- Recursively implement Euclid's Algorithm?

-- Play Conway's Game of Life (in one dimension, of course)?

-- Do floating-point operations (using one DAT instruction as the
   exponent and another as the mantissa)?

-- With your fancy new floating-point operations, generate an
   approximation to your favorite trig function?

-- With Redcode's easy forking of concurrent processes, perhaps a good
   parallel sorting algorithm could be developed and tested?

-- How about artificial intelligence?  Every battle program I've seen
   has basically one mechanical method hard-coded into it -- why not
   use something more adaptive?
	(I know, I know -- you can't write LISP in Redcode.)

-- A Redcode LISP interpreter?  (This is too nuts and I should
   probably stop here.

It would be interesting to see what comes of this idea; some of these
are almost trivial (the Fibonacci series, for instance), but some are
pretty tough.


   
--
Microsoft Windows:  Proof that a GUI doesn't have to be useful or intuitive.
----------------------------------------------------------------------
	 Daniel F. Boyd -- consp04@bingvaxu.cc.binghamton.edu
		  Next week: The origin of Chimp-X!



Subject: Re: 2 programming questions
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Organization: Vanderbilt University School of Engineering, Nashville, TN, USA
Date: 21 Nov 91 18:34:41 GMT
Message-ID: <1991Nov21.183441.2882@vuse.vanderbilt.edu>

In article <91325.00:02:19.089372.DURHAM@ricevm1.rice.edu> DURHAM@ricevm1.rice.edu (Mark A. Durham) writes:
>to work.  Anyone have a use for such two pointers which point to the
>same place?  (Sounds like a really stupid question in Pascal or C, etc.
>but I really can't think of a use for it in Redcode).
>
>MAD


Well, I can see how this could be used for some form of "interprocess
communication". 'ptr1' could e.g. be a counter for the current number of
subprocesses a program has running, which every program-copy in Core 
can read from/write to.

-Stefan
-- 
Stefan Strack, PhD {stracks@ctrvax|stst@vuse|stst@dmwsun.hh}.vanderbilt.edu
Dept. Pharmacology, Vanderbilt Univ., Nashville, TN 37232-6600, USA
Voice: +615-322-4890, Fax: +615-343-6532
"Real men don't use icons"



Subject: Idea: 3-operand code
From: n8243274@henson.cc.wwu.edu (steven l. odegard)
Organization: Western Washington University
Date: 21 Nov 91 21:04:20 GMT
Message-ID: <1991Nov21.210420.29609@henson.cc.wwu.edu>

Has anyone explored the idea of expanding the instruction set to employ
3-operand format, like many of the RISC processors?



Subject: Re: Idea: 3-operand code
From: consp04@bingsuna.bingsuns.cc.binghamton.edu (Dan Boyd)
Organization: State University of New York at Binghamton
Date: 21 Nov 91 22:15:17 GMT
Message-ID: <CONSP04.91Nov21171517@bingsuna.bingsuns.cc.binghamton.edu>

In article <1991Nov21.210420.29609@henson.cc.wwu.edu> 
n8243274@henson.cc.wwu.edu (steven l. odegard) writes:
> Has anyone explored the idea of expanding the instruction set to employ
> 3-operand format...

Because of the way MOV works, I don't think this is worth doing.
Right now it's very simple and orthogonal.  Expanding it would
probably mean adding things like distinct instructions for MOV and
MOVA (move address).

> ... like many of the RISC processors?

Three-operand instructions are a lot older than the idea of RISC!
Hell, VAXes have three-operand instructions, and a VAX is NOT a RISC
machine.

-- Dan
--
Microsoft Windows:  Proof that a GUI doesn't have to be useful or intuitive.
----------------------------------------------------------------------
	 Daniel F. Boyd -- consp04@bingvaxu.cc.binghamton.edu
		  Next week: The origin of Chimp-X!



Subject: IMPS
From: lalonde@cis.ohio-state.edu (robert c lalonde)
Organization: The Ohio State University Department of Computer and Information Science
Date: 21 Nov 91 23:41:04 GMT
Message-ID: <9111212341.AA10797@skink.cis.ohio-state.edu>

I have seen quite a few people complain about the dreaded SPL 0 bomb, but I 
don't really see how this is such a problem.  If you wrote a replicate, then
erase and die, warrior it would seem to be resistant to an SPL 0 bomb, because 
it would erase it, but if you had the split limitation that everyone is talking
about it would protect against the unlikly hit on the erasure loop.  (This 
would also seem to provide some protection against a vapiric attack.)  What 
I am wondering about is if this limitation of process splits continues after
the process has extingused itself.  If not then one could set the limit to
two, split off to copies and committ suicide.  

Another question is how to deal with IMPS.  It seems to me that IMPS (one line
self replicating process) are the ultimat leveler. It is very hard to hit the
IMP, and an IMP seems to hit other processes quit well.  The only problem is
that it seems to tie almost all of the time.  If there is any kind of loop
in its target, it is likely that there will be a re-execution of the IMPS
trail by its enemy.  Unfortunatly, while the imp has a hard time winning, it
is hard to kill.  The only program I can think of that would be sure to
destroy an imp would be a stationary, non-replicating program that forever, 
bombs the address above it, and even then this bomb behavior is a 2 instruction
loop, while the imp moves forward each instruction, so even then there is only
a 50/50 chance of winning against the imp.  

Am I missing something?  To me it seems that the IMP is the most powerfull of 
all.  Can anything beat the imp?   If not why not submit 
start:	mov	0	1

as a contestant in these turnaments?  I am sure it would come in the middle
of the pack, because its record would be somthing like 1 win, 3 losses, and 
10 ties.


-- 
Robert C. LaLonde (Rob)           |Internet: lalonde.6@osu.edu,
                                  |        : lalonde@cis.ohio-state.edu,
Computer Science Undergrad        |        : rlalonde@magnus.acs.ohio-state.edu
Senior Year                       | or UUCP: osu-cis!lalonde
Secretary of The Ohio State University Student Chapter of ACM.



Subject: Re: IMPS
From: melody@matgrd00.ncsu.edu (Patrick Melody)
Organization: NCSU Mathematics Dept.
Date: 22 Nov 91 02:36:36 GMT
Message-ID: <1991Nov22.023636.22384@ncsu.edu>

In article <9111212341.AA10797@skink.cis.ohio-state.edu> lalonde@cis.ohio-state.edu (robert c lalonde) writes:

>Can anything beat the imp?   If not why not submit 
>start:	mov	0	1
>
>as a contestant in these turnaments?


Well, under current tournament rules, I believe a win is worth 3 points, while
a tie is only worth 1 point.  In a tie, the Imp's opponent also gets a point, 
so the Imp isn't ahead.  You need wins to become champ.  There is a much more
efficient Imp stomper I read in Mark Durham's post which has a much better than
50/50 chance of working:

        DAT #0,  #0
start   JMP  0, <-2

Also, there are programs such as Raidar and Cowboy which maintain "fences":

 ********        =======         ********
  fence          program          fence

The program writes a certain word into the fence regions and periodically
checks to see is any fence locations have changed. If so, the program copies
itself out of danger to an area on the other side of the damaged fence and
transfers control to the copy, which builds 2 new fences for the new copy
and continues.  Imp doesn't have a chance at overrunning these programs.
(Unless of course, it has other friendly processes helping it.)

melody@matgrd00.ncsu.edu  



Subject: SPL 0 bombs
From: kwhyte@dickson.uchicago.edu (Kevin Whyte)
Organization: Dept. of Mathematics, Univ. of Chicago
Date: 22 Nov 91 06:35:04 GMT
Message-ID: <1991Nov22.063504.7786@midway.uchicago.edu>


   What do people think of the following modification
of the SPL instuction:  give the child process some 
fraction of the parent's time slice.  This fraction could
be variable and determined by the B field.  This 
certainly limits the effectiveness of SPL 0 bombs as
the bomb can use, at most, all of the time slice of the
process which hit it.  In fact, since to win you would
eventually have to track down and kill the bomb, it isn't
clearly any better than a strait DAT bomb.  (As a silly
aside: with this convention one no longer needs the JMP
instruction, just SPL and give the child the entire time
slice).

  As far as limiting the read/write range of a program, 
consider the following.  Break memory up into pages, each
page being circular the same way the core is now.  Allow
read/write within the same page, along with two new addr.
modes for next/prev. page.  This limits the program to
a three page range, without setting arbitrary boundries
in the core. It also is nice since a "page" is then a
well defined block of memory so it doesn't change depending
on where you are in the program (yes, I am advocating that
execution would not pass from one page to another, but rather
wrap around as though the page were an entire (but small) core).
This allows for some interesting extentions to corewar ...
for example if the # of pages is the same a the size of a 
page, then make an instuction which takes the page # as an
argument and returns the # of processes executing in that
page.  This certainly allows programs to hunt each other down
reasonably quickly, hence encouraging programs to move alot!

  Since I am relatively new to Corewar (except for a brief
  flirtation around the time of the SA article), I will
  not be surprised if these are well known or stupid-for-
  some-obvious-reason.  I await your comments,

Kevin
kwhyte@math.uchicago.edu



Subject: Re: Division
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: 22 Nov 91 14:34:56 GMT
Message-ID: <91326.08:35:06.211724.DURHAM@ricevm1.rice.edu>

>>Why this fixation on core size 8192?

ICWS tournaments have always been 8192.  (Sort of begs the question though.
I do not know why tournaments have always been 8192, except perhaps that
was the only core size the original tournament system supported).

The real reason I suggested 8192 for the random number generator problem
is that I already have a version which depends on that core size.

I also prefer 8000 (and other 2^n * 1000) core sizes.  Especially if
people do not know the core size ahead of time.

MAD



Subject: Re: Can Redcode be useful?
From: benh@eecs.umich.edu (Benjamin Harrison)
Organization: University of Michigan
Date: Fri, 22 Nov 1991 21:08:51 GMT
Message-ID: <BENH.91Nov22160851@dip.eecs.umich.edu>

In article <CONSP04.91Nov21122825@bingsuna.bingsuns.cc.binghamton.edu> consp04@bingsuna.bingsuns.cc.binghamton.edu (Dan Boyd) writes:
>Redcode is apparently equal in power to a Turing machine.

Um, I don't mean to be rude, but since a Turing machine has infinite
memory, and the memory of a Redcode core is inherently finite, there
are a great many things that you cannot do in a redcode program that
are trivial with a Turing machine.  Thus Redcode is apparently *NOT*
equal in power to a Turing machine.  For example, you cannot even add
X to X in Redcode, where X is the largets number possibly represented
in the M memory locations of the core, each able to hold up to M
instructions.

>Theoretically, anything that can be done by any computer, anywhere,
>can be done by Redcode.

And this is of course wrong, tho I know what you meant.  Obviously
redcode cannot do even simple things, like graphics or sound, because
it is inherently limited.  However, this also applies to a Turing
machine.


-------- Ben/Bosk ----------



Subject: Another proposed SPL change
From: wms@iwarp.intel.com (William Shubert)
Organization: Intel iWarp, Beaverton, Oregon, USA
Date: 22 Nov 91 22:12:42 GMT
Message-ID: <1991Nov22.221242.29522@iWarp.intel.com>

Y'know, the proposals about limiting processes, etc. got me thinking.  I also
don't like the way that you can just subvert a provess, make it split off
millions more, and then kill the guy.  However, I also don't like the way that
it's just far too effective to split off millions of copies of yourself (like
say lots of imps) and then at least tie.  After thinking about the other
proposals I've got an idea:

   First, I really like the idea that when a process splits, it's CPU cycles
are divided among it's two children, so after the first split each process gets
1/2 of the cycles.  Let's call them A and B.  Then if A splits into A0 and A1,
A0 and A1 get 1/4 of the cycles each while B gets 1/2 still.  This both makes
sense logically (since now the startup with one process per player is a lot
like a regular split) but also allows you to write programs with some form
of priority ordering; some processes get more time than others.  If you want
your impstomper to get 1/2 of the cycles, just split to it first then split
all other processes off of the non-imp stomper.

   The second idea that kind of goes with this is designed to prevent the
usefulness of supersplitters.  What is when a process of yours is killed IT
STILL CONSUMES CYCLES?  So imagine this:  There are two players, A and B.
The execution is as follows:

A B A B A B ...

Then a forks, into A1 and A2.  Execution is:

A1 B A2 B A1 B A2 B ...

Now A1 splits off, into A11 and A12.  We now have:

A11 B A2 B A12 B A2 B A11 B A2 B A12 B A2 B ...
(note that A2 gets 1/2 of A's CPU time, A11 gets 1/4, and A12 gets 1/4).

At this point, B _kills_ A12.  Now the execution is:

A11 B A2 B <nobody> B A2 B A11 B <nobody> B A2 B
(note that A2 STILL gets 1/2 of A's CPU time and A11 STILL gets 1/4.  1/4 of
A's CPU time will now be unused forever, because A12 still takes up cycles
even though it is dead.)

Notice that now you can fork all you want, but if you make millions of
subprocesses then some die the remaining processes do NOT speed up again.
This makes it important to make sure that all of your subprocesses are doing
something useful.  Also the vampires, SPL 0 bombs, etc. do no more damage than
killing a single process.

What do you all think?
				-Bill (wms@iwarp.intel.com)
PS - I like the paging idea also.  I've got to think about a good way to
implement it, though.



Subject: Re: Can Redcode be useful?
From: consp04@bingsuna.bingsuns.cc.binghamton.edu (Dan Boyd)
Organization: State University of New York at Binghamton
Date: 22 Nov 91 23:33:59 GMT
Message-ID: <CONSP04.91Nov22183359@bingsuna.bingsuns.cc.binghamton.edu>

In article <BENH.91Nov22160851@dip.eecs.umich.edu> benh@eecs.umich.edu
(Benjamin Harrison) writes:
> In article <CONSP04.91Nov21122825@bingsuna.bingsuns.cc.binghamton.edu>
consp04@bingsuna.bingsuns.cc.binghamton.edu (Dan Boyd) writes:

> Um, I don't mean to be rude, but since a Turing machine has infinite
> memory...

The idea is to pretend that core is 'big enough' to get whatever done
that you want to do.  Of course CORESIZE isn't infinity.  Neither is
the amount of memory on your VAX -- but you don't model VAXes with
finite automata, you model them with Turing machines.

> For example, you cannot even add X to X in Redcode...

This same limitation holds for any computer.  If you have 32 megs of
memory on your VAX and you have 300 megs of disk space, then you can't
add 2^N to 2^N where N is greater than the total number of bits in
your memory and on disk.

Can we dispense with your objection by adding a footnote: CORESIZE is
assumed to be 'big enough' to hold the particular problem we're
working on?  Or could we say, 'Redcode can SIMULATE a Turing machine?'

--
Microsoft Windows:  Proof that a GUI doesn't have to be useful or intuitive.
----------------------------------------------------------------------
	 Daniel F. Boyd -- consp04@bingvaxu.cc.binghamton.edu
		  Next week: The origin of Chimp-X!



Subject: Re: Extension to Redcode
From: jonn@microsoft.com (Jon NEWMAN)
Organization: Microsoft Corp.
Date: 22 Nov 91 22:27:59 GMT
Message-ID: <1991Nov22.222759.28461@microsoft.com>

In article <21643@chaph.usc.edu> mochang@aludra.usc.edu (Morrison J. Chang) writes:
>The one problem that I see with the current standards of Redcode is
>that at some point all of the efficent programs get written....

I have thought so every year ... until the annual ICWS tournament, where
something new always turns up.  Naturally, any program can be killed by
a lucky hit (for CHANG1, it would have to be a _very_ lucky hit), the
question is whether a better program overall can be written.  Watch the
ICWS tournament for this year's innovations!
-- 
jonn@microsoft.com    

This is not the official opinion of Microsoft Corporation.  Bill Rules!



Subject: two dimensional core
From: hoffman@tesuji.cmf.nrl.navy.mil (Eric Hoffman)
Organization: Connection Machine Facility, NRL
Date: 23 Nov 91 17:15:54 GMT
Message-ID: <HOFFMAN.91Nov23121554@tesuji.cmf.nrl.navy.mil>


Has the idea of programs running in a multi-dimensional core been
considered? 

Each instruction would contain a field indicating which of four
directions on the mesh the processor counter should proceed. This
would not effect the orthogonality of the instruction set, since all
constants and relative addresses would be vector valued. 

A process could be arranged to have up to three different 'branches'
adjacent to a memory position, changing the contents of that location 
changes which gets executed. 

The basic 'imp' program would no longer restrict the development of
more complex multi-threaded programs, because it could no longer be
guaranteed that the enemy lies along its trajectory. It could be
changed to exhaustively search a two dimensional space, at the expense
of making it slower. I would suggest that two dimensional cores be
generally be larger than the canonic 8k 1d core, being something more 
like 2kx2k.

The packing of a program into core could be a strategic factor, with
a designer possibly choosing a very sparse layout to reduce the
possibility of a hit, or a very tight one to make a smaller target.

Since programs which wind through two space would be inherently
difficult to write in a line-oriented assembler, there could be both
an emacs mode which windows on a two dimensional grid of instructions
(replace 'specially written editor' for 'emacs mode' if you are so
inclined), and a bunch of programs to take a one-dimensional program,
and pack it according to selectable criterion. 

I myself haven't written any cw code. I've always been put off by the
tiny instruction set and the fact that any clever program always is
reduced to dealing with 'imp' if it is to survive. This doesn't put me
in a very good position to judge the feasibility of 2d core. I was
about to run off and code this (with the editing mode) a few months
ago but it was definitely low priority, and got shelved. 

Let me know if people are interested, since the interpreter (why do
people compile redcode?) would be pretty simple, given the proper
motivation.

2d core wars would make a nice X display (not to defame the efforts of
blojo@soda.berkeley.edu, I was pleasantly suprised by this
implementation, thanks). 

Actually, as far as spatial complexity goes, a 3d core would be
preferrable, but the code generation and run-time viewing makes this a
little infeasable. 

  e



Subject: Editorial
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: 24 Nov 91 03:22:53 GMT
Message-ID: <91327.21:22:53.391087.DURHAM@ricevm1.rice.edu>

Since the dawn of Core War, it seems people are more interested in
CHANGING the game than PLAYING the game.  I understand you all have
your reasons for wanting to change the game in this way or that, and
I too think that the game can be improved.  But I have two words for
you -- TRY IT!

If you have written or are writing a Core War system, first make it
ICWS'88 compatible, then add all of your wonderful ideas as options
you can turn on and off.  But you cannot stop there!  You must write
and try as many Redcode programs that use that feature to its utmost
in order to understand what it means to the game.

SPL was added to Redcode before anyone truly knew what it would mean
to the game.  Is SPL good or bad for the game?  Makes no difference
really, we should have found out before we added it to the standard.

I do not want to quash all of the wonderful ideas out there.  I want
to get them organized.  My personal goal is to help establish a new
standard on the tenth anniversary of Core War in the Public Eye on
March 1st, 1994.  That may seem like a long time to wait, but it really
is not.  The other standards both took two years each to establish.
The difference with the '94 standard will be its longevity (I hope).

But there are some important points to address before we start haggling
over the inclusion of this instruction or that feature.  Core War is
drifting aimlessly in this sea of ideas because it has no philosophy
upon which it can take root and be firmly based.

Please consider the following points.  Think them over.  Let them simmer
on the backburners of your mind.  Sometime later in January, we will post
a questionaire, form an informal committee, and start working toward
that new and better Core War.

But a warning to those who think they know best about what is best for
Core War.  Core War as it exists today is a very complicated thing.  I
know that it is hard to believe that such a small set of instructions
can be so complicated, but it is.  The world is full of complicated games
(and complicated things) which arise from a small set of simple instructions.
Those of you who think IMP or MICE or SPL 0 are the be-all, end-all of
Core War just have not devoted enough time to the game as it exists today
to fully appreciate its complexities.

Things to think about:
   What do we want from Core War?  Do we want it to be
      * A great game?
      * A good simulation of present day hardware?
      * A tool for Artificial Life?
Of course, some aspects of each of these already exist in Core War.  And
we would like to keep as much of each as possible.  But we need to
establish priorities.
   What level of sophistication do we want Core War to be?  When Core War
first appeared, it was very simple.  Almost anyone could write a simulator
for almost any machine (and almost everyone did!).  Today's Core War
systems tend to be much more sophisticated.  Do we want to continue to make
the game more difficult to implement, possibly to the point where most
people would be forced to purchase shrink-wrapped systems off-the-shelf?
Also, will people need X Megs of RAM, a Y Meg harddisk, and a Z MHz speed
processor in order to play?
   What parts of the game should be set in stone, and which should be left
up to the user (or person running the tournament)?  People often want to
know what size the core is.  They want to take advantage of that information.
That's fine.  But I should have the option of not telling them, of forcing
them to reason out a strategy that does not depend on core size or taking a
chance on a strategy that does.  Chance is an element of life and of games
which should not be overlooked.
   I have a confession.  I am a huge fan of the Motorola 68xxx family of
microprocessors.  My apologies to anyone with some interest or sympathy for
segmented architectures, but I just think they are plain dumb and no matter
what numbers or figures or reasoning you may throw at me I will probably go
to the grave with that bias (so please don't try to change my closed mind)!
But, I am in favor of adding a kind of segmentation to Core War to improve
game play.  On the other hand, I do not want segment size set in stone.  If
I want core size to be 529361 and segment size to be 529361, I should have
that option.
   Present day Core War has some of this philosophy.  Core size and the
maximum number of tasks are completely up to whoever is running the game.
Oh, and the number of cycles before declaring a draw too.  There is a great
deal to be said for continuity and backwards compatibility.  But I will
leave that to a future editorial.

MAD



Subject: Re: Division
From: alpowell@images.cs.und.ac.za (L)
Organization: Univ. Natal, Durban, S. Africa
Date: 24 Nov 91 04:45:01 GMT
Message-ID: <1991Nov24.044501.5544@images.cs.und.ac.za>

DURHAM@ricevm1.rice.edu (Mark A. Durham) writes:

>To do division in Redcode, you need to go back to the fundamental
>definition of division -- "How many times can you subtract y from x?".
> [Redcode deleted]

>Needless to say, division is SLOW!!!!   Multiplication can be done
>in a similar way.  Sometimes you can speed up multiplication.
> [more Redcode deleted]

OK. This last bit got me thinking (doesn't happen much nowdays I'm 
afriad). The better algorithms for mutliplication rarely use repeated
"adds". A better way is to use shifting and adds - usually faster, more
general than the example given ( and easier to understand?). So, isn't
there something similar for division - I haven't had a look yet, but I'm 
sure there's a better way to divide then to subtract a whole bunch of times.
Of course, the above works when you consider the binary representation of the
number - not too difficult in Redcode? :-)

Just a thought.
L 



Subject: Re: Division
From: kwhyte@dickson.uchicago.edu (Kevin Whyte)
Organization: Dept. of Mathematics, Univ. of Chicago
Date: 24 Nov 91 10:19:17 GMT
Message-ID: <1991Nov24.101917.18522@midway.uchicago.edu>


   Being a math grad student I somehow feel compelled to
comment here.  Arithmetic in REDCODE is not standard 
integer arithmetic, but arithmetic "mod M".  This is not
anything tricky, just means "wrap around" when you get to M.
Thus, as we all know, 1=M+1=2M+1 = -M+1 = etc.  Somehow
we still manage to add sensibly.  Why? because, for example

   1 + 2 =3
   and (1+M)+(2+M)=3+2M which =3.  So we can still add. The
same works for subract and, for multiplication.  Division
however is another matter.  Example, take M=8192

   4096+4096 = 2 * 4096 =0
   so what is 0 divided by 2 ? 0 or 4096?

   Here's another strangeness 3 * 2731 = 8193 = 1,
   so 1/3 = 2731!!!

believe it or not, all of the problems go away if M is prime,
but many programs depend on certain #'s dividing M.  (My
personal preference is to specifically not tell what the
core size is, and run different rounds of the tournement at
various core sizes).  Anyway, some of you may think, well
why don't we just represent #'s as 0 through M-1 and divide
and round off in the standard fashion?  Well this could be
done (the similar problem with defining less than was 
appearently dealt with this way, but notice if X<Y it may
not be true that X+1<Y+1 !! so, one needs to be careful), but
then we could have (2 * x) /2 not necesarily equal x, so
DIV might be of limited usefulness!

 Kevin
  kwhyte@math.uchicago.edu
  (somehow I think I've got that lecture mode 
  on again. Damn! last time it made me lecture
  calculus at a frat party while drunk.  gotta
  get that fixed.



Subject: Re: Division
From: jmason2@gpu.utcs.utoronto.ca (Jamie Mason)
Organization: University of Toronto Computer Services Advisor
Date: 24 Nov 91 15:25:56 GMT
Message-ID: <1991Nov24.152556.10893@gpu.utcs.utoronto.ca>

kwhyte@dickson.uchicago.edu (Kevin Whyte) writes:
>   Being a math grad student I somehow feel compelled to
>comment here.  Arithmetic in REDCODE is not standard 
>integer arithmetic, but arithmetic "mod M".  This is not

	Please remember that, strictly speaking, integer arethmetic on
ANY computer is modulo arithmetic.  Integer arithmetic in an unsigned 16
bit short is mod 65536.  In an unsigned 32 bit long, it's mod 4294967296.
But it's still modulo.

	'Signed integers' cannot technically be considered to be
modulo N, since that would require them to be in the range 0..N-1.  But
the signed integers still display the wrapping around property of modulo
arithmetic:
	Most Positive representable number: Pos = 2^(n-1) - 1
	Most Negative representable number: Neg = - 2^(n-1)

    Pos + 1 = Neg

	So in regular computer arithmetic we have to worry about the fact
that we are actually using modulo arithmetic.  In an unisgned short,
65535 + 1 = 0.   0 ( + 65536 ) / 2 = 0 ( or 32768).  So we have the same
problems.   2^n is most definitely NOT prime.

	But what do we do about the problem?  We count 'wrapping around'
as an 'error', giving arithmetic overflow.  Then we go happily on with
our business pretending that we were doing normal integer arithmetic.  I
don't see why Redcode should be any different.

Jamie ... char *i; main(){for (i=(char *) malloc(31457280);;*(i+=4096)=1);}
Written On  Sunday, November 24, 1991  at  10:23:55am EST



Subject: Re: Division
From: ajz@mentor.cc.purdue.edu (T. Tim Hsu)
Organization: Purdue University Computing Center
Date: 24 Nov 91 16:51:32 GMT
Message-ID: <27308@mentor.cc.purdue.edu>


Your most basic method of nonrestoring division goes like this on unsigned
numbers.....

Let's say we have 3 registers, Dr will hold the divisor, Dd will hold the
dividend, and Q will hold the quotient.
1) Initialize Q to 0, Dr to the divisor, Dd to the dividend.
2) Shift Dd and Q.  The bit shifted out of Q (should be a zero in all cases)
   is put into the LSB of Dd.  The bit shifted out of Dd is put into the
   carry flag.
3) If the carry flag = 1, store a 0 into the LSB of Q and add Dr to Dd
   storing the result in Dd.
4) If the carry flag = 0, store a 1 into the LSB of Q and subtract Dr from
   Dd (actually add the complement of Dr to Dd) storing the result in Dd.
5) Repeat steps 2-4 N times where N is the number of bits in Dd.

In hardware, steps 2-4 are performed simultaneously.  For multiplication,
most methods of multiplication attempt to speed it up by creating more and
more rows of zeros in the multiplication table, thus requiring less adds.

In redcode, the problem I see is that there are no shift operators which
nearly every faster method of multiplication/division uses.

-- 

Ting Hsu                           UUCP    ...pur-ee!ajz@mentor.cc.purdue.edu
                                   ARPA    ajz@mentor.cc.purdue.edu
FAX   1 317 494 0566               BITNET  xajz@PURCCVM



Subject: Re: Division
From: hallyb@globbo.enet.dec.com (John Hallyburton)
Organization: Twin Peaks Municipal Software Works
Date: 22 Nov 91 22:00:10 GMT
Message-ID: <30592@nntpd.lkg.dec.com>


DURHAM@ricevm1.rice.edu (Mark A. Durham) writes...

>I also prefer 8000 (and other 2^n * 1000) core sizes.  Especially if
>people do not know the core size ahead of time.

Amen to that!  Core sizes, like load addresses, should be randomly generated.
Some programs work better with smaller or larger memories.

--
						"The Smart Money was on Goliath"
						John Hallyburton 43 55'N 71 45'W



Subject: Re: Division
From: consp04@bingsunm.bingsuns.cc.binghamton.edu (Dan Boyd)
Organization: State University of New York at Binghamton
Date: 24 Nov 91 18:20:24 GMT
Message-ID: <CONSP04.91Nov24132024@bingsunm.bingsuns.cc.binghamton.edu>

In article <1991Nov24.101917.18522@midway.uchicago.edu> 
kwhyte@dickson.uchicago.edu (Kevin Whyte) writes:
> Well this could be done (the similar problem with defining less than
> was appearently dealt with this way, but notice if X<Y it may not be
> true that X+1<Y+1 !! so, one needs to be careful), but then we could
> have (2 * x) /2 not necesarily equal x, so DIV might be of limited
> usefulness!

	This strangeness with comparisons will let your program figure
out what CORESIZE is -- WITHOUT being told.

	Set A to 10, and B to -10.  B is actually CORESIZE-10.  So
comparing A to B will say that B is greater.  Increment A, decrement
B.  Compare again.

	When you find that A is greater than B, we know that B and A
have crossed over.  So B is set to Coresize/2.

	I've seen programs that have a preamble like this appended to
their code:

bomb:	SPL 0
start:	MOV bomb, -50
	MOV bomb, 50
	MOV bomb, -100
	MOV bomb, 100
	.
	.
	.
begin:	; do whatever the program really does.

	This is intended to get a bunch of bombs fired off FAST,
before the enemy is done initializing itself.  I think you could
determine the size of core and bomb some of it with the same loop.

-- Dan
--
Microsoft Windows:  Proof that a GUI doesn't have to be useful or intuitive.
----------------------------------------------------------------------
	 Daniel F. Boyd -- consp04@bingvaxu.cc.binghamton.edu
		  Next week: The origin of Chimp-X!



Subject: Re: Division
From: adam@flammulated.owlnet.rice.edu (Adam Justin Thornton)
Organization: Shift to the left!  Shift to the right!  Stand Up!  Sit Down!
Date: 24 Nov 91 19:51:33 GMT
Message-ID: <1991Nov24.195133.24765@rice.edu>

Certainly, shifts are a much more optimal way to implement multiplication and
division than simple iterated addition and subraction, but there is a problem.

Everyone has been discussing this as if you can directly map Redcode numbers to
bits, but Redcode isn't inherently binary, is it?  I mean, it doesn't seem to
assume _any_ base as far as I can tell.  With a given base you can do smart
algorithms for * and /, but I'm not sure this is valid withing Redcode.
Admittedly, it's always looked a lot like 8-bit assembly code to me, so I 
suppose supporting a two-byte, sixteen-bit unsigned int as the number structure
would make sense, but I don't think anything in Redcode makes this strictly
necessary.

I too would appreciate a formal syntax for Redcode, as my PC version came
with no docs and I have no idea if it's '86 or '88 compliant.

Adam

--
Adam Thornton  |  Opinions are mine alone, though Rice is welcome to them.
"Once in a while, you can get shown the light in the strangest of places
if you look at it right." | "To all the beautiful people out there: there
are a lot more of us than there are of you."| adam@owlnet.rice.edu | 64,928



Subject: King of the Hill
From: wms@iwarp.intel.com (William Shubert)
Organization: Intel iWarp, Beaverton, Oregon, USA
Date: 24 Nov 91 22:48:40 GMT
Message-ID: <1991Nov24.224840.22103@iWarp.intel.com>

OK, OK, this idea was suggested a while ago, I didn't really have time, so I
figured somebody else would take it up.

But since nobody else has, I'll volunteer.  I haven't written a program that
could handle it, but I'll start soon.  I do have a real job, and not much
time left over, so it may be a while, but I HAVE written a corewar program
before so I can do it again.  I plan on making it mail-oriented so anybody
who sends me mail in a certain format will get it automatically entered into
an ongoing tournament.  I'll keep everybody posted on my progress.  In the
meantime, if anybody else thinks that they can get it going sooner, please
do so.
				-Bill (wms@iwarp.intel.com)



Subject: Re: IMPS
From: marksv@cs.man.ac.uk (Vaughan Marks)
Organization: Department of Computer Science, University of Manchester
Date: 24 Nov 91 15:54:19 GMT
Message-ID: <MARKSV.91Nov24155419@t7.cs.man.ac.uk>


On 21 Nov 91 23:41:04 GMT,
lalonde@cis.ohio-state.edu (robert c lalonde) said:
> Sender: lalonde@cis.ohio-state.edu (robert c lalonde)

> Am I missing something?  To me it seems that the IMP is the most powerfull
> all.  Can anything beat the imp?   If not why not submit 
> start:	mov	0	1

Is the PCT instruction a standard extension to redcode? It was part of the
instruction set on the implementation I used... PCT protects a store location
for 1 write (only). Therefore programs can protect themselves as well as
being offensive.. of course it is a double edged sword... IMPs can be
dispensed with:

	PCT 0
	DAT 0
start:  SPL -2
	rest of program

Spawn a process that protects a location and dies. An imp will execute 
mov 0 1, breaking the protection, it will then execute your PCT 0, resetiing
the trap for subsequent IMP's before dying ;-)
What do you think of having PCT in redcode? It makes things interesting...
--

				-Vaughan Marks



Subject: Re: King of the Hill
From: cyoon@utdallas.edu (Chang K. Yoon)
Organization: Univ. of Texas at Dallas
Date: 25 Nov 91 03:18:08 GMT
Message-ID: <1991Nov25.031808.18795@utdallas.edu>


------- BEGIN INCLUDED MESSAGE -------

OK, OK, this idea was suggested a while ago, I didn't really have time, so I
figured somebody else would take it up.

But since nobody else has, I'll volunteer.  I haven't written a program that
could handle it, but I'll start soon.  I do have a real job, and not much
time left over, so it may be a while, but I HAVE written a corewar program
before so I can do it again.  I plan on making it mail-oriented so anybody
who sends me mail in a certain format will get it automatically entered into
an ongoing tournament.  I'll keep everybody posted on my progress.  In the
meantime, if anybody else thinks that they can get it going sooner, please
do so.
				-Bill (wms@iwarp.intel.com)


-------- END INCLUDED MESSAGE --------

I'd be willing to hosts the system..  My home system is mm1.lonestar.org (or
soon will be.  The uucp maps have already recieved the information, but I've
been trying to contact doug@letni.lonestar.org without success) and I can
setup a daemon to automatically handle the information. (ex: cwdaemon
addr ex: cwdaemon@mm1.lonestar.org or somesuch name).  If no one else has
any objections, I'd be willing to do this.

-------------------------------------------------------------------------------
Chang Yoon                            |  DISCLAIMER:  My thoughts (and no one
cyoon@utdallas.edu                    |  else's)
-------------------------------------------------------------------------------
   "Our children know EVERYTHING, we have cable."  -  Ms. Penbroke, C 'n C
-------------------------------------------------------------------------------



Subject: Re: Can Redcode be useful?
From: dgg@llcn2.jhuapl.edu (Dave Gawron)
Organization: Johns Hopkins University
Date: 25 Nov 91 18:56:54 GMT
Message-ID: <1991Nov25.185654.21468@aplcen.apl.jhu.edu>

In <BENH.91Nov22160851@dip.eecs.umich.edu> benh@eecs.umich.edu (Benjamin Harrison) writes:

>In article <CONSP04.91Nov21122825@bingsuna.bingsuns.cc.binghamton.edu>
>consp04@bingsuna.bingsuns.cc.binghamton.edu (Dan Boyd) writes:
>
>>Redcode is apparently equal in power to a Turing machine.

>Um, I don't mean to be rude, but since a Turing machine has infinite
>memory, and the memory of a Redcode core is inherently finite, there
>are a great many things that you cannot do in a redcode program that
>are trivial with a Turing machine.  Thus Redcode is apparently *NOT*
>equal in power to a Turing machine.  For example, you cannot even add
>X to X in Redcode, where X is the largets number possibly represented
>in the M memory locations of the core, each able to hold up to M
>instructions.

I understand the basis behind your argument about a Turing machine being more
powerful than Redcode, but you miss the mark a little concerning the true
nature of Turing machines.  The power of a Turing machine comes not from the
infinite amount of memory available, but by its ability to express any
computable algorithm when given sufficient memory.

If you argue that a Turing machine is more powerful because it can use
infinite memory, then you have a created a problem for yourself.  For
example, if your turing Machine *requires* infinite memory to compute the
answer to some algorithm, then this implies that the Turing machine must scan
over each tape cell at least once.  Now, since the tape is infinite this
implies that the Turing machine will never halt.  Thus your algorithm is
"uncomputable".  Even though it has infinite memory you still don't get
the expected answer.

As for the addition example you give, the answer is simple, increase the core
to the required size; then the problem is "computable" by Redcode.  You see,
the infinite tape mechanism of a Turing machine allows us to ignore the real
world constraints of core size and instead concentrate on the fundamentals of
the algorithm.  It does not "magically" make A Turing machine more expressive
or powerful.


>>Theoretically, anything that can be done by any computer, anywhere,
>>can be done by Redcode.

>And this is of course wrong, tho I know what you meant.  Obviously
>redcode cannot do even simple things, like graphics or sound, because
>it is inherently limited.  However, this also applies to a Turing
>machine.

Not so fast.  Have you a proof of this?  To prove the equivalence of Redcode to
a Turing machine you have to do two things:

1) prove that Redcode can simulate any possible Turing machine.
2) prove that a Turing machine can simulate any possible Redcode.

Are you game to prove the negative of these? ;-)

-Dave-

PS: all this is intended in good spirit.  If you want to do some comparisons,
    it would be better to consider Finite Automata with respect to Redcode
    since Finite Automata takes into account finite space and time requirements.



Subject: Re: Can Redcode be useful?
From: sander@inthehat.engin.umich.edu (Scott D Anderson)
Organization: University of Michigan Engineering, Ann Arbor
Date: 25 Nov 91 20:11:18 GMT
Message-ID: <!Yp_-CA@engin.umich.edu>


In article <1991Nov25.185654.21468@aplcen.apl.jhu.edu>, dgg@llcn2.jhuapl.edu (Dave Gawron) writes:
> In <BENH.91Nov22160851@dip.eecs.umich.edu> benh@eecs.umich.edu (Benjamin Harrison) writes:
> 
[discussion of Turing machines deleted]

> 
> -Dave-
> 
> PS: all this is intended in good spirit.  If you want to do some comparisons,
>     it would be better to consider Finite Automata with respect to Redcode
>     since Finite Automata takes into account finite space and time requirements.

actually, since it is possible to 'remember' things with redcode, and perform
simple stack operations, i think a finite automata would be too limited, and
one would be forced to use at least a pushdown automata for comparison, if
not even a turing machine. however, i could be wrong. perhaps you might want
to build a dfa with the amount of states equal to the sum total of all 
possible values of the core along with pointers for each process, etc. ;)

scott



Subject: Re: Can Redcode be useful?
From: lenp@microsoft.com (Len Popp)
Organization: Microsoft Corp.
Date: 26 Nov 91 03:11:03 GMT
Message-ID: <1991Nov26.031103.19947@microsoft.com>

In article <BENH.91Nov22160851@dip.eecs.umich.edu> benh@eecs.umich.edu (Benjamin Harrison) writes:
>In article <CONSP04.91Nov21122825@bingsuna.bingsuns.cc.binghamton.edu> consp04@bingsuna.bingsuns.cc.binghamton.edu (Dan Boyd) writes:
>>Redcode is apparently equal in power to a Turing machine.
>
>Um, I don't mean to be rude, but since a Turing machine has infinite
>memory...

(Sigh, not again.)

No Turing machine program can use an infinite amount of tape, because that
would take infinite time!  Any Turing machine program that halts uses only a
finite amount of tape (but there's no bound on that amount).  Well, Redcode
can use any finite core size, so it IS equivalent to a Turing machine.  Eg.
you can translate a TM program into Redcode, run it, and if it runs out of
memory, double coresize and try again.  If the TM program halts, so will the
Redcode program eventually.

In face, Redcode is MORE like a Turing machine than any "real" computer,
because memory size is unbounded.  Which isn't true on my Macintosh.

Besides, we DO use Turing machines to model real computers, even though any
real computer has a limit to its memory.  The Turing machine model can be
used to determine if a given computation is possible, and its theoretical
complexity.  Then you can worry about whether it'll run on a particular
"real" computer.  Sure, you can say, "Well, any *real* computer can only
store a certain number of bits, so it's *really* equivalent to a finite
state machine, not a Turing machine."  That doesn't get you very far,
though, because then you have to deal with a finite state machine with, say,
10^250000000 states!

The idea that "TM's are infinite, so they can't model real computers" just
misses the point about how the Turing machine works and what it's for.

	Len Popp
	lenp@microsoft.com

	"A person who is more than casually interested in computers should
	be well schooled in machine language, since it is a fundamental part
	of a computer."
		--Donald Knuth



Subject: Corewar Competition
From: montfaid@IASTATE.EDU (Monty L Faidley)
Organization: Iowa State University
Date: 26 Nov 91 15:03:15 GMT
Message-ID: <1991Nov26.090315@IASTATE.EDU>


ATTENTION!ATTENTION!ATTENTION!ATTENTION!ATTENTION!ATTENTION!ATTENTION!ATTENTION


	Computer users/hackers/slashers/programmers/wizzes/freaks/dudes

			AMBIT Inc. is sponsoring a Contest.

		That's right.  A Corewars programming contest. 

	Using a special code developed by employees of AMBIT Inc. we will
	be running programs submitted by interested competitors, and we
	will be awarding Cash Prizes to the top programmers.  The code is
	easy to learn, and the programs are easy to write. 

			Tell all your friends! 
			Tell all your enemies!
			Tell everyone!!

	For more information:  swilliam@iastate.edu

			Includes: Contest Rules
				  Documentation
				  Code

ATTENTION!ATTENTION!ATTENTION!ATTENTION!ATTENTION!ATTENTION!ATTENTION!ATTENTION

 



Subject: Re: Another proposed SPL change
From: ADCMS@CUNYVM.BITNET
Organization: City University of New York/ University Computer Center
Date: 26 Nov 91 04:17:14 GMT
Message-ID: <91329.231714ADCMS@CUNYVM.BITNET>

I agree heartily with the ideas that 1) a parent splits its time equally
with a child upon an SPL command, so that spl 0,0 bombs are not very
effective '
and
2) A dead process should continue to use CPU time. This will rapidly
cripple previously all-regenerating mice; when a process maximum is reached,
mice won't regenerate new processes when old ones are killed!

3) 8192 is a fine coresize! Personally, I would be in favor of non-random
loading positions; exactly 1/2 core apart. This makes things more
predictable. (OK, I can understand how people might disagree with this--
luck victories may become inevitable. What do other folks think?)

The parent split count idea discussed earlier is kind of arbitrary; 1 and 2
above are much more aesthetic and probably simpler to code.

King of the kill  (I meant hill) is a great idea.
OK: now for a new idea or two. (At least I think they are new.)
How about allowing an FLP command that would set a process executing backwards?
Relative addressing should be flipped appropriately also. Initial loading,
in this system, would also be random; of course, a program loaded backwards
would begin in the same place it would if executing forward (the first line
of code in the .rc file often, or the place marked start) and would begin
FLP'd. The net effect of this would be to eliminate the assymetry of the core;
there would no longer be any arbitrary direction "forward" or "backwards".
Highly interesting loops with FLP at each end could be written, and the code
need not be symmetric if labels are not used. Labels insource Redcode may
get screwed up in reverse- executing code, so loops would need to be carefully
coded.
FLP bombs may cause interesting side effects.
Also, I read an idea somewhere around here for 2-d corewar. I would like to
say. this sounds really neat. One can envision ROT commands to rotate
execution 90 degrees in this scenario.
Aaron



Subject: PCT and the '88 standard
From: rogue@cellar.org (Rachel McGregor)
Organization: The Cellar BBS and public access system
Date: 26 Nov 91 15:39:49 GMT
Message-ID: <31Z1BB5w164w@cellar.org>


   This newsgroup has been my first exposure to Corewar and Redcode, but I've 
since gone back and gotten Eric Dewdney's Scientific_American articles on the 
subject (May '84, March '85, and January '87).  From all the talk about 
people's reliance on PCT instructions, I'm surprised that it hasn't been 
included in a post-'88 standard.  Is a '92 standard currently being devised?

   (Also, what is the deadline and address for entries in this year's ICWS 
tournament?)

Rachel Kathleen McGregor : rogue@cellar.org : {tredysvr,uunet}!cellar!rogue

"If I want more love to the world, I must show more love to myself.
 'Cause I do want to change the world."



Subject: Re: Division
From: rogue@cellar.org (Rachel McGregor)
Organization: The Cellar BBS and public access system
Date: 26 Nov 91 15:32:14 GMT
Message-ID: <FoZ1BB4w164w@cellar.org>

hallyb@globbo.enet.dec.com (John Hallyburton) writes:

> DURHAM@ricevm1.rice.edu (Mark A. Durham) writes...
> >I also prefer 8000 (and other 2^n * 1000) core sizes.  Especially if
> >people do not know the core size ahead of time.
>
> Amen to that!  Core sizes, like load addresses, should be randomly generated.
> Some programs work better with smaller or larger memories.

I *heartily* disagree with that.  I'm developing a program in which it's 
important to know core sizes because of the attack patterns it uses.  Since 
core sizes are not always 8000, I've designed two different versions, for a 
core of 8000 and a core of 8192.  The 8192 version will work in an 8000 core, 
but the 8000 is tighter, and the 'preferred' model.  The 8000 version, 
however, is based on multiples of five, and would wind up crashing in an 8192 
location core.

Rachel Kathleen McGregor : rogue@cellar.org : {tredysvr,uunet}!cellar!rogue

"If I want more love to the world, I must show more love to myself.
 'Cause I do want to change the world."



Subject: Re: Division
From: consp04@bingsuna.bingsuns.cc.binghamton.edu (Dan Boyd)
Organization: State University of New York at Binghamton
Date: 26 Nov 91 20:04:53 GMT
Message-ID: <CONSP04.91Nov26150453@bingsuna.bingsuns.cc.binghamton.edu>

In article <FoZ1BB4w164w@cellar.org> rogue@cellar.org (Rachel McGregor) writes:
> I *heartily* disagree with that.  I'm developing a program in which
> it's important to know core sizes because of the attack patterns it
> uses.

There are ways to find CORESIZE -- have two pointers A and B, which
are stored adjacent to each other.  Make a loop, in which you
increment one of them (A) over and over again.  Set things up so that
the B pointer is incremented only EVERY OTHER time through the loop.
When A becomes 0, B points halfway around core.

Indeed, you could have another pointer, C, which is incremented only
every fourth time through the loop -- this pointer will end up at
CORESIZE/4.

But this means you're sitting around for 8192 cycles, doing
essentially nothing.  Try starting A at 7998 and B at 7998/2; this
will let you figure out whether CORESIZE is 8000 or 8192.

The thing is, bombing all of core seems fast -- but it takes a long
time to scan all the way through the whole core.  And while you're
scanning and bombing all of core, somebody's replicating all over the
place and approaching your position.  No magic way to win.

-- Dan
--
Microsoft Windows:  Proof that a GUI doesn't have to be useful or intuitive.
----------------------------------------------------------------------
	 Daniel F. Boyd -- consp04@bingvaxu.cc.binghamton.edu
		  Next week: The origin of Chimp-X!



Subject: Re: Division
From: kadatz@fraser.sfu.ca (Blake Carl Kadatz)
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: 27 Nov 91 01:27:19 GMT
Message-ID: <1991Nov27.012719.20670@newsserver.sfu.ca>

In article <FoZ1BB4w164w@cellar.org> rogue@cellar.org (Rachel McGregor) writes:
>hallyb@globbo.enet.dec.com (John Hallyburton) writes:

>> Amen to that!  Core sizes, like load addresses, should be randomly generated.
>> Some programs work better with smaller or larger memories.
>
>I *heartily* disagree with that.  I'm developing a program in which it's 
>important to know core sizes because of the attack patterns it uses....

The spirit of corewars is to develop a program that can survive given any
conditions.  With a randomly generated set of parameters, programming in
corewars is an ART.  If everything is known ahead of time, you reduce it to
a pure science, which means that an attack can be basically formulated.

Introduce a few random things, and the programs need to be dynamic.  Think
of it like putting a person somewhere in the middle of a field.  To survive,
the person needs to check out the surroundings and make decisions based on
that.  In corewars, the program is basically blind, but the same concept holds.
You need to go from what you're given, which is basically nothing.  You then
try and use a method of attack that will wipe out the enemy, which is hiding.



-Blake Kadatz			e-mail: kadatz@fraser.sfu.ca



Subject: INV command implemented
From: ADCMS@CUNYVM.BITNET
Organization: City University of New York/ University Computer Center
Date: 27 Nov 91 01:11:33 GMT
Message-ID: <91330.201133ADCMS@CUNYVM.BITNET>

I wrote up an INV command last night for the UNIX X-windows based cw implement
available at soda.berkeley.edu.  The command currently takes two dummy args
and reverses process execution without considering them. A reversed processs
also has completeley reversed relative and indirect addressing, so that a
piece of code written backwards and run backwards will run quite happily,
never knowing that it is moving backwards through memory. Furthermode, the
program #2 in this implementation is loaded and run in a random orientation
as well as a random location; the result is a core that posseses no inherent
orientation (at least as far as the programs can tell.) Children of SPL get
the same direction as their parents.
The implementation has been uploaded to soda.berkeley.edu; I ask that whoever
it was that wrote it take a look at the code. I have described most coding
changes so that the code may be integrated more easily with other revisions/
improvements on the code you may be writing.
The assembler program seems to work on some systems but not others. To test
your assembler, assemble the impinv.rc file included and compare the .e file
to the standard imp.e. If they are identical, try moving the assembler to
another machine. In this implementation, .e files are fairly transferable.

The implications of the INV command, which I am currently testing, seem to
center around the head-to-head collisions that can now occur when two process
running in opposite directions crash across one another. Also, the INV command
should allow for some rather odd- looking loops with INV's at both ends.
I am working on this, but as I am fairly new to Redcode, I would appreciate
somemore experienced help.

Please send comments to cann@msrcvax.bitnet, not this address. Oh, the
files I uploaded to soda.berkeley.edu are only the ones I changed; the
Makefile may need to be edited on your specific system as well, to make sure
that yacc does its job correctly.

Aaron Cann



Subject: Philosophy of Corewar
From: ADCMS@CUNYVM.BITNET
Organization: City University of New York/ University Computer Center
Date: 27 Nov 91 01:32:55 GMT
Message-ID: <91330.203255ADCMS@CUNYVM.BITNET>

I do a fair amount of programming and I like games in general. The way I see it
the most important thing about Redcode is --Keep it simple--. The structure of
MARS should be as intuitive, natural, and SMALL as possible; conversely, the
SMALL instruction set should attempt to allow for the largest variety possible
of programming strategies.
On these grounds, I propose the eternal banishment of the following commands:
RND and PCT. These highly artificial, deus-ex-machina approaches to common
corewar problems (getting a good dispersal pattern and protecting against imps,
respectively) subtract from the elegance of MARS. The problem of an effective
dispersal pattern is much better solved by a Fibonacci series than an RND
command, and I think the last work on stoppin IMPs was said about three weeks
agoon this board. The RND command pulls a number out of thin air; why not then
allow absolute addressing, another way of pulling numbers out of thin air?
The PCT command is simply unneccasery.
The reason I thought up the INV command was to get rid of the single bit of
outside information a process did have, namely, the direction through core it
in which it is processed. The random orientation of program #2 eliminates the
knowledge of which direction a standard imp will come from, and allows for a
host of new interactions between opposing processes. The INV command allows
processes to fully avail themselves of the newfound flexibility of MARS.
OK, next application of the "Elegance & Simplicity" theory of corewars:
Core size.
Which is more "elegant," 8000 or 8192? Well, 8192 has only two as a factor,
which admits advantage to programs dependent on multiples of 2 but no other
number; 8000 has 2 and 5 as factors (only.) and so allows for programs
that take advantage of core architectures that have these multiples (only.)
As previously pointed out, there is no a-priori reason to use a power of two
for a core size.
The fault I find with (both) of these coresizes is that they grant advantage
to very specific types of code, namely, those that depend on the factors of
code. This dependence is eliminated by using only prime coresizes; how about
a MARS system that randomizes coresize (within certain, admittedly arbitrary,
bounds) to some prime number and then starts contestants(CORESIZ +1)/2 units
apart from eachother? (Or some fixed method. Best if distance is also a prime
number, but maybe that is going too far...sigh.) Aaron



Subject: King of the Hill
From: wms@iwarp.intel.com (William Shubert)
Organization: Intel iWarp, Beaverton, Oregon, USA
Date: 27 Nov 91 02:43:50 GMT
Message-ID: <1991Nov27.024350.24182@iWarp.intel.com>

OK, everybody...a few days ago I said I would start working on a "King of the
Hill" corewar which had been suggested by other people.  I said I'd keep you
up to date on the progress, so here I am.  When I'm done this should make it
easy for people writing corewar programs to test them out on a regular
basis.

   Progress is going faster than I expected.  I have finished the assembler
and tested it; it seems to work correctly and robustly, and does a fairly
good job of error reporting when you screw up your redcode.  It accepts
the "+" and "-" operators when parsing an argument, but does not accept "*",
"/", or "()".  I believe that this is standard for redcode assemblers.
   Now I have to write the simulator and the mail daemon.  I hope to have
the set ready for a beta-test tournament a week from Friday (it would be
sooner, but I'll be away over Thanksgiving.)
   JustIn tutty is also working on a KotH; however, he mentioned he is
busy with exams so I went ahead and got started.
                                -Bill (wms@iwarp.intel.com)



Subject: Re: MADitorial :-)
From: hallyb@globbo.enet.dec.com (John Hallyburton)
Organization: Twin Peaks Municipal Software Works
Date: 27 Nov 91 15:02:10 GMT
Message-ID: <30850@nntpd.lkg.dec.com>


DURHAM@ricevm1.rice.edu (Mark A. Durham) writes...
>Since the dawn of Core War, it seems people are more interested in
>CHANGING the game than PLAYING the game.  I understand you all have
>your reasons for wanting to change the game in this way or that, and
>I too think that the game can be improved.  But I have two words for
>you -- TRY IT!

OK, I tried it.  I concluded, as posted earlier (I'm sorry I can't find
the posting to credit the author) that in the current system there seems
to be an intransitive set of "top dogs", MICE loses to SPL0 loses to ...
... loses to MICE.  It doesn't seem very interesting!

>Those of you who think IMP or MICE or SPL 0 are the be-all, end-all of
>Core War just have not devoted enough time to the game as it exists today
>to fully appreciate its complexities.

This is a bit like the faith healers' eternal fall-back:  "What?  You say
you're NOT cured?  Why, you must NOT BELIEVE ENOUGH...".

I'd like to see a program that consistently (say, 80%+ of the time) beats
IMP ^ n, MICE, SPL 0/DAT 0 bombs.  Do such creations exist?

I think the proposed extensions to Core War seem to aim towards reducing the
power of these small programs, thus encouraging and rewarding clever thinking.
Various proposed changes to the way SPL works would go a long way towards
what I consider to be an improvement.
--
						"The Smart Money was on Goliath"
						John Hallyburton 43 55'N 71 45'W



Subject: Tryin' to figure out...
From: rpb0804@venus.tamu.edu (BATES, ROBERT PATRICK)
Organization: Texas A&M Univeristy, Academic Computing Services
Date: 27 Nov 91 16:30:00 GMT
Message-ID: <27NOV199111303025@venus.tamu.edu>

I'm trying to write a RedCode program, and have run into a stumbling block... 
Being new to CoreWars, but not to assembly language, I can't seem to figure out 
how to successfully check to see if an address has something other than DAT 0 0 
in it!  Do I do a compare to #0, or is there some other way to do it?  I've 
currently got a program that SORTA works, but it doesn't seem to locate the DAT 
0 0 addresses very well... I don't have any RedCode samples that I could look 
at as templates, so any help would be appreciated!

Thanks,
Rob 

==============================================================================
Robert Bates                        Disclaimer:
rpb0804@venus.tamu.edu                  "I make no claims..."
Texas A & M University
==============================================================================



Subject: Re: INV command implemented
From: n8243274@henson.cc.wwu.edu (steven l. odegard)
Organization: Western Washington University
Date: 27 Nov 91 18:19:13 GMT
Message-ID: <1991Nov27.181913.11444@henson.cc.wwu.edu>

ADCMS@CUNYVM.BITNET (Aaron Cann) writes:

>I wrote up an INV command last night for the UNIX X-windows based cw implement
>also has completeley reversed relative and indirect addressing, so that a
>piece of code written backwards and run backwards will run quite happily,
>never knowing that it is moving backwards through memory. Furthermode, the

	This brings to mind an idea:  INV x will cause the program to
	fetch the next instruction (x) from the current instruction.
	INV is pronounced "interleave", and x can be negative
	This again will be transparent to the process  (the process
	just perceives a different view of "consecutive memory".
	Code can run on each Nth memory cell and perhaps be more
	stealthy.  Or maybe different process will be loaded to run
	a random direction and random interleave.  IMPs would have a
	different behaivoir in this case.  Note that with this
	implementation, the number of cells in the core should be a prime
	number.



Subject: Re: MADitorial :-)
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: 27 Nov 91 19:46:03 GMT
Message-ID: <91331.13:46:14.210721.DURHAM@ricevm1.rice.edu>

>>OK, I tried it.  I concluded, as posted earlier (I'm sorry I can't find
>>the posting to credit the author) that in the current system there seems
>>to be an intransitive set of "top dogs", MICE loses to SPL0 loses to ...
>>.... loses to MICE.  It doesn't seem very interesting!

>Those of you who think IMP or MICE or SPL 0 are the be-all, end-all of
>Core War just have not devoted enough time to the game as it exists today
>to fully appreciate its complexities.

>>This is a bit like the faith healers' eternal fall-back:  "What?  You say
>>you're NOT cured?  Why, you must NOT BELIEVE ENOUGH...".

This is an incorrect analogy.  What I was trying to say is not that you do
not have enough FAITH, but that you do not have enough EXPERIENCE.  You
can run IMP and MICE until your MARS fries itself, it will not give you
the experience of having run programs such as QUARTER and XTC, two very
good Redcode programs which are capable of consistently beating lesser
(IMP-like and MICE-like) programs.  (Please treat "you" as plural, meaning
all well-intentioned people who want to change Redcode in a very specific
manner without fully understanding the current state-of-the art Core War
programs [which on occasion does include myself!]).

>>I'd like to see a program that consistently (say, 80%+ of the time) beats
>>IMP ^ n, MICE, SPL 0/DAT 0 bombs.  Do such creations exist?

Such programs do exist (see above) and we are trying to post them here and
to soda.berkeley.edu as quickly as possible.  Maybe early December?

>>I think the proposed extensions to Core War seem to aim towards reducing the
>> [accidentally deleted line, unimportant to point below]
>>Various proposed changes to the way SPL works would go a long way towards
>>what I consider to be an improvement.

OK.  The point I was trying to make (and did not do well enough) was that
we should be talking about the "aims" and "consider to be an improvement"s
in general terms at this point, NOT SPECIFIC EXTENSIONS geared toward those
aims.  How can we agree to specific extensions if we do not agree to the
general aims first?

[ I was about to launch into an aside about the specific problems of allowing
code to run backwards here, but realized I would be falling into the same
trap. ]

So let us talk about the general aims.  The general aim you wish to discuss
is making certain types of programs less effective?  This is certainly a
common goal of many people.  The scoring of tournaments was changed to make
IMP and MICE less effective.  That succeeded.  IMP and MICE do not fare well
in modern day tournaments.  In ICWS'88, the SPL instruction was changed so
that new tasks are added to the end of the task queue instead of the
beginning in order to make SPL 0 -type programs less effective.  It certainly
makes SPL 0 -type programs less effective, but enough so to change which
programs win tournaments?  That remains to be seen.

But what is the logical conclusion of this pursuit?  Will we need to change
the language every time someone writes a good program?  How many people
want to change the game because they personally can not come up with a
program to beat IMP or MICE or whatever?  Do people want to change the
rules of chess just because they can not beat Kasparov?

Granted, this is an exaggeration.  Core War does not possess quite the
"richness" of chess.  Nor does it possess the history.  It is a good
thing to want to improve the game.  I just want people to start with
a general idea - "Pawns should have more mobility" in the chess analogy.
Then if we agree that yes, pawns should have more mobility, then and only
then should people suggest ways to fulfill that desire.  "Pawns should
be able to move sideways" or "Pawns should be able to move two squares
all of the time".

After we agree on the general principle and people have put forward
specific suggestions which address that general principle to one degree
or another, then we should implement them, test them, and decide which
ones are keepers and which should be allowed to die quietly.

Experimentation is a good thing.  I do not want to discourage experimentation
on a small, confined scale.  Experimentation in the glaring spotlights of
the public eye is much more dangerous (witness cold fusion).  I only ask
that extensions to ICWS'88 be clearly indicated as EXTENSIONS NOT
SUPPORTED BY THE STANDARD.  That way we can avoid needlessly confusing
the public.  I do think people get much more caught up in playing with
these extensions than playing standard Core War though.

MAD



Subject: Re: INV command implemented
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: 27 Nov 91 20:45:37 GMT
Message-ID: <91331.14:45:46.236976.DURHAM@ricevm1.rice.edu>


>	This brings to mind an idea:  INV x will cause the program to
>	fetch the next instruction (x) from the current instruction.
>	INV is pronounced "interleave", and x can be negative

This suggestion is really a suggestion to eliminate the current
"speed of light" (limiting speed) from Core War.  Do we really want
programs to be able to move through core at any speed?  Currently, if
a program wants to move faster than IMP, it needs to copy itself to a
new location farther along in core than IMP would get by that time.
The trade off is that the program has to sit still long enough to copy
itself.

   INV x
   MOV 0, x

can move arbitrarily fast.  Is moving arbitrarily fast something we
want in Core War?  It seems contrary to the suggestion of limiting how
far a program can bomb, etc. using any of the paging schemes suggested
earlier.

Let us try to move the conversation to these higher plains rather than
specific implementation ideas.

MAD



Subject: Re: INV command implemented
From: kwhyte@dickson.uchicago.edu (Kevin Whyte)
Organization: Dept. of Mathematics, Univ. of Chicago
Date: 27 Nov 91 23:16:12 GMT
Message-ID: <1991Nov27.231612.26419@midway.uchicago.edu>


  On a general level it seems to me that the complaint
people have with the current Core War command set is
that programs do not seems to act "intelligently".  By
this I mean that they do not respond to their environment
to any great degree.  (Many programs respond effectively
in one way, XTC scans for enemies ... Cowboy moves when
things come nearby ... etc).  Why is this true?  Well
such programs would me much larger and slower than current
programs and hence while they were trying to do whatever
"thinking" we would have them do, they would have 3 or 4
bombs dropped in their midst.

  The more I think about this question, the less sure I
am that we want to "fix" it.  Currectly corewar is easy
to understand, and all the programs (even the best), use
ideas that anybody can understand quite simply once told.
Nonetheless, as MAD comments, there is a surprising amount
of complexity and richness there.  If we change the game
enough we certainly could make it a serious AI challenge,
but it's not at all clear this a sacrifice we want to make.
(At least, I would be much more likely to spend the time
to play a "simple" corewar, similar to the currect one)

  This said, there still are some ideas that I think 
it would be useful to discuss.  Any program can be 
killed by a lucky hit, so virtually any program will
be beaten a substantial portion of the time (30% ?)
by an efficient bomber.  It would seem this can be
solved easily, within the current standards, namely
increase the core size drastically.  (I'm thinking
somewhere between 128K and 1M).  On a more should we
do this level, do we want to encourage more sophisticated
information gathering?  Currently I see two reasons
why this doesn't happen : 1> It is as fast to bomb
memory as to read it, and 2> There is little need to  
keep track of where the enemies are as one bomb, or
at least one bombing run, will disable just about
anything.  There are plenty of ways this could be changed,
i.e. make reads faster than writes, do "pages" and
allow the programs to tell if there are executing 
processes in a given page, limit write range but not
read range, etc.  However discussing specific methods
is probably not worth it until we determine exactly
what we wish to accomplish.

 Kevin
 kwhyte@math.uchicago.edu

uld be pursu:



Subject: Q: Cellular automata in the spirit of CW
From: joel@cs.ucsc.edu (Joel Darnauer)
Date: 28 Nov 91 15:09:36 GMT
Message-ID: <24568@darkstar.ucsc.edu>

I had an idead several years ago when I first heard about
core war, but I haven't had the time to try it out.

Does anyone know whether there is a core war-type simulator
that uses cellular automata instead of linear codes?  In such
a system, you might have a large 2D or 3D array of cells (the core)
that might be several bits deep.  There would be a simple function
that computes the next state of a cell from the previous states of
its neighbors.  Users would design 'programs' by setting the initial
states of an area of cells in such a way that the 'program' would
move or replicate itself, 'eat' enemies, etc.  etc.  It's conceiveable 
that users could also be given a special slice of the domain of the
next state function to define thier own behaviors.

Obviously generating such a system or generating programs in it 
poses special problems: 3D visualization, creating an efficient way
of specifying and testing CA `programs' and such. Since there is no 
thread of control in any real sense, telling who is alive and dead 
at ant given time is a rather subjective matter, but this is true 
in real life as well.

Is anyone aware of anything like this out there?

joel@ce.ucsc.edu



Subject: Re: Q: Cellular automata in the spirit of CW
From: gt3930b@prism.gatech.EDU (NICHOLS,STEVEN MALCOLM)
Organization: Georgia Institute of Technology
Date: 28 Nov 91 16:18:14 GMT
Message-ID: <42694@hydra.gatech.EDU>

In article <24568@darkstar.ucsc.edu> joel@cs.ucsc.edu (Joel Darnauer) writes:
>Does anyone know whether there is a core war-type simulator
>that uses cellular automata instead of linear codes?....

I have thought about this too, and decided that it is not very feasible
for two reasons: finding a good rule set, and "programming" the
automata in a way that is not complete chance.

One of the problems with the cellular automata you
describe is their only seems to be a few "interesting" rules in the
huge number of possible rule sets.  For example, Conway's Life is one
rule set for 2-D local elementary cellular automata (i.e. nearest neighbor
interactions and 2 states for each cell).   In Carter Bay's 3-D Life
there are apparently only 2 "interesting" rule sets, but the number of
possible rules is astronomical, so who can say what else is out there.
To have two different kinds of cells would make rule sets even larger.
So the first crux would be finding a "good" rule set for the game; 
since "good" is hard to quantify, this would mean trying a bunch of rules.

The other problem is that the dynamics of cellular automata are not
well understood. Even with a good rule set, programming these things 
would be more chance than strategy.  Here's an example:  if you have
a copy of Life, randomly fill in a 5x5 grid.  Now predict what it is
going to do.  

Maybe I'm a pessimist, but I feel that cellular automata are just
too poorly understood to create a game as rich as core wars.

>Obviously generating such a system or generating programs in it 
>poses special problems: 3D visualization....
>
>joel@ce.ucsc.edu

(WARNING: yet another core wars upgrade proposal!)

How about this for a twist: a 2-D version of Corewars.  The core would
be a grid rather than linear, and addresses would have an X and Y
component.  A program like IMP could copy itself along the X direction,
keeping Y constant, or vice versa.  I imagine larger programs would 
be much less fragile in a 2-D array (there is a lot more space to hide
in from mindless bombing), leading to some sophisticated strategies.
Another possibility would be, rather than having two component addresses,
a rotate instruction that would allow a program to switch between X addressing
and Y addressing.  The problem with this idea is that a corewar might
have to go for a *really* long time before there is a winner.

Steve Nichols.

============================================================================
Steve Nichols					gt3930b@hydra.gatech.edu
random .sig quote of the day, pilfered from someone else's .sig:
	"The best effect of any book is that it excites the reader to
	self-activity."
	- Thomas Carlyle
============================================================================



Subject: Re: Looking for MARS for the C-64
From: benh@eecs.umich.edu (Benjamin Harrison)
Organization: University of Michigan
Date: Sun, 1 Dec 1991 03:09:57 GMT
Message-ID: <BENH.91Nov30220957@sparky.eecs.umich.edu>

This may be obvious, but the strategies one would use in a core of
size 8000 or so is so completely different than the strategy one could
use in a core of size 8000000 or so as to be extremely important.  I
mean, if you want to write any kind of intelligence into your program,
it is important that your program be much smaller than the total core
size.  If your program is, say, half the core size, not only will most
assemblers refuse to let it play, but it will be unable to reference
itself, and will probably die immediately.  But an intelligent program
of say, size 1000, could very easily survive against almost anything
in a core of size 1000000, where it occupies only 1/1000 of the core,
but can do a lot of high level processing.  If nothing else, I would
recommend allowing some form of access to the 'coresize/2' constant.
Perhaps in data statements, with 'MEMSIZE' as a predefined constant.

But with such miniscule core sizes, I think intelligence will lose out
to tiny persistance in the long run.  Any thoughts on this?

--------------- Ben/Bosk ----------------



Subject: Memory bombing (long)
From: cpbeaure@descartes.waterloo.edu (Chris Beauregard)
Organization: University of Waterloo
Date: Mon, 2 Dec 1991 16:47:45 GMT
Message-ID: <1991Dec2.164745.12728@descartes.waterloo.edu>

  Several things I want to bring up.

  First.  About the pre-decrement indirect instruction.  

  What was the argument for introducing this mode?  As far as I can tell, it
was a way of letting the programmer do things like copy and bomb much 
faster than with the DJN, SUB, or original DJZ.  I find that it just
doesn't fit in with the regular CW instruction set.  Just call me
over-critical.

  And further, where is the pre-increment indirect?



-----------------


  The following ideas may have appeared somewhere in TCWN or some CW
correspondence about the world.  I've never seen anything one it though
(maybe 'cause I haven't followed CW other than Scientific American and
recently this group.)  However, I'm sure there are others whoi haven't seen
anything like it, so this is for them...

  Oh, yes, I'd like to mention that these ideas may not be viable for a
good competition warrior.  I couldn't care less.  I just like to program
for the sake of programming, and competition is quite secondary to
inventing neat new concepts.  However, if someone puts any of these ideas
together into a good battle program, I'd like to hear about it.  And maybe
you could put a line into the source giving me credit...

-----------------

  This weekend, I was sort of bored and looking for something to do
(actually, trying to avoid studying for finals...) so I started paging
through a pile of CW stuff I've compiled over the years.  At some point,
an idea hit me.  I hit back, and a major tussle stated.  It won, and I was
forced to boot up the handiest implementation of CW and actually test the
idea.  

  A little prelim stuff...

Howitzer Fangs

  I suppose many are familiar with the good old fashioned vampiric fang.
The one that looks like

  JMP @1
  DAT wherever_you_want_them

  At some point, I came up with a variation, which I call the Howitzer fang
(after a program named <duh> Howitzer)  The basic fang looks like

  MOV 1,@1
  DAT Some_address

  As Howitzer was written, it would bomb the world with these fangs, and if
one was hit, the program hitting it would send it's relative location back
to a Howitzer and die.  Howitzer would then bomb the area hit, really
heavily.  You might be saying "So it bombs the place. It's already dead.
Why bother?"  Good point.  This was written with the purpose of killing
programs with good regeneration capabilities, like the Five Musketeers, or
a few of my own.  It's a pretty specific purpose program... 

  A later incarnation of Howitzer simply replaced the fang.  As I was using
R.Martin's Mac implementation, I also used the PCT instruction to defend
the cell.  If a program regenerated onto the spot without bombing the
place, it would likely hit the fang again.  Very deadly against
regenerators, and it would also handle imps and stuff.

  

  A later program I designed was a slave driver called Whip.  It would
launch fangs which looked like

   MOV 2,@2
   JMP 0
   DAT whatever

  I never got around to implementing Whip, but the theory was pretty
complex.  When an enemy hit the fang, it would signal Whip and sit on the
JMP 0 until Whip picked it up.  Whip would copy a simple slave program, the
n send code to make the captured program jump to that slave.  The slave
program was loaded with the location it was captured at, and it was
dedicated to bombing the point it was captured over and over and over
again, until Whip finally killed it.  Or was it suppoed to replace the
fangs?  Whatever, one or the other, it was still pretty complex.  

  The whole Howitzer/Whip arguement is leading up to the biggy.  The thing
about Whip is that it would create as many new slave programs as captured
prorgams were brought in.  No real limit to things.  (Some people are
probably nodding and saying "uh huh" in an abstract tone of though)

Memory Bombing

  So what hit me this weekend is the ultimate way to burn the hell out of
programs that like to regenerate on the same location.  Memory bombing.  

  Essentially, the program launches Howitzer fangs.  When a program returns
an address, it will put the address at the end of a list, and every once in
a while, it will go through the list and bombs every locations (and area
around)  Really simple, and surprisingly easy to implement.  Took me about
two hours to write, debug, and test.

  I wrote a simple program called Memory 1.0 to demonstrate the concept.
Unfortunately, I don't have a ICWS '88 implementation handy (well, I have
one, but my IBM is in Toronto) or I would have wrote it up in that.  I
couldn't even upload the code of the one I wrote, or I would have tried
that too.  <sigh>  Such is life.  Here goes with a rough approximation of 
what it looks like, with an attempt to modify it to ICWS '88 standards.
I'll try to find time and disk space for the x11 CW, and then I can
do a good write-up and test.
 
  Sorry about the org-expressions.  A hold over from the original.


;  Memory 1.0 rough-idea-code     Chris Beauregard    Dec 1,1991

@-3
target     dat 0              ; target for dumping fangs
fang       mov 1,@1           ; basic Howitzer fang
bite       dat 0              ; bite, each fang should point to gotone
                              ; when placed
@0
mainloop   jmn addone,gotone  ; this is the start of the program, and
     			      ; the main loop. Note that bite and target
                              ; should have value loaded when the program
                              ; starts up.  depends on how you write it
                              ; though.
                              ; Oh, yeah, what are we doing.  If gotone is
                              ; not a zero value, go to addone, because it
                              ; means a program has returned its location.
           [
            insert vampiric fang placement
            routine here.  Just make sure that the bite value
            placed always points to gotone, or you could have
            some serious problems.
           ]

           djn mainloop,count ; when count hits zero, bomb the target
                              ; addresses known.  I use count at 100, but
                              ; whatever pleases you...


bomb       mov #100,count     ; reset count
           jmz mainloop,numgot ; trying the bomb without targets would be
                               ; useless and probably fatal.

; setting up for each bomb run.

setup      mov numgot,curgot  ; move the value containing the number of
                              ; known targets to curgot, so we can change
                              ; it while bombing.
           add #1,curgot      ; and add one.  Check how numgot/curgot are
                              ; set up, adn you'll set why.
           mov #5,target2     ; set up for bombing first target location.
           sub @curgot,target2 ; Since the value returned is relative to
                               ; Memory, and negative, we have to change
                               ; it so we're pointing the right way (shitty
                               ; explanation, I know...
                               ; The #5 is an offset, so we start bombing
                               ; about 5 cells before the location the
                               ; fang returned.
           mov #10, attacks   ; we bomb each target for 10 cells.  You
                              ; can change to suit. 
bombloop   mov #0,@target2    ;a basic bomb loop.  ICWS '88 code would
                              ; likely speed it up.
           add #1,target2     ; increment target
           djn bombloop,attacks  ; loop back, until 10 cells bombed.
           sub #1,curgot      ; decrement curgot, so it points to another
                              ; target
           cmp curgot,#1      ; if 1, back to mainloop.
           jmp mainloop
           jmp setup          ; else setup for next run.

; adding a target location.  simple process.  Simply add one to numgot,
; which points to the last target address stored, move the address in
; gotone to the new location, and reset gotone to zero.
; Oh, and 'addone' might not work as a label.  I spent a while looking
; for this bug before I realized the assembler probablt though it was
; opcode. <sigh>

addone     add #1,numgot      ; increment numgot.
           mov gotone,@numgot ; move target to last location.
           mov #0,gotone      ; reset gotone
           jmp mainloop+1     ; jump back to loop, one past where we
                              ; were called from.  '+1' not necessary, but
                              ; I try to keep way from redundant code...

; now the data structures.

count      dat 100
attacks    dat 10
target2    dat 0              ; for max efficiency and not having to do
                              ; a lot of arithmetic, I keep target close to
                              ; gotone.  You can have it anywhere by just
                              ; changing the mov #5,target2 to whatever
                              ; gives the appropriate offset.
gotone     dat 0              ; bites point HERE!
curgot     dat 0
numgot     dat 0 

; target locations are added here.  numgot points to the last in the series
; which is why we add one when curgot is setup.  curgot has to point to
; the last in the series while we're working.


  A little messy, but with all the comments, probably useable.

  As you can imagine, unless you really optimize the code, especially the
fang placement code (at least what I wrote!) it's a bit slow.  As well, it
has nothing for imps, worms, what-have-you.  It's also immobile, but that's
not a big problem.  

  The biggest problem is that as more targets are found, the time it takes
to bomb them all goes up bigtime.  And it's only really effective against
programs that like to regenerate into the same location.  The ones I've
written with good regen capabilities are all mobile, and especially avoid
areas they know have been bad for them in the past.

  I guess a lot of this is implementation.  Who knows, someone might be
able to scrap together a powerful system from this...

Enjoy...
 
-------------------------------------------+---------------------------------  
Chris Beauregard                           | If all the world's a stage, what
cpbeaure@descartes.waterloo.edu            | do we do when the audience starts
"If you can't beat 'em, take 'em with ya!" | throwing stuff?



Subject: Memory Bomb - implementation
From: cpbeaure@descartes.waterloo.edu (Chris Beauregard)
Organization: University of Waterloo
Date: 3 Dec 91 17:08:03 GMT
Message-ID: <1991Dec3.170803.6133@descartes.waterloo.edu>


  Okay, I managed to at least get the code for Memory 1.0, as written in
R.Martin implementation, onto my unix account.  Here it is...


------------------------------

* Memory 1.0           Chris Beauregard           Dec 1,1991

* INTRODUCTION 
* This is an implementation of a concept called "memory
* bombing."  A program will, somehow, find the location of
* a program, and "remember" its location. The program then
* has the locations available for later use, be it bombing,
* vampire fangs, or anything else... 

* METHOD
* Sends out Howitzer fangs, and as data comes in, puts the
* locations at the end of the program.  Every once in a while
* it bombs the area.

* Howitzer fangs, btw, are derived from a program I wrote
* called <duh> Howitzer.  Instead of having the target jump
* to where we are, it just returns its address relative to
* us back to a certain location, and we do something with it.
* Howtizer would bomb the area and then replace the fang.
* Combined with the PCT command on the fangs, this could
* kill just about anything...

* SPECIFICS
* The main loop does a typical vampiric fang placement, the
* fangs being modified so that instead of the program jumping
* back, it returns its location to gotone and dies.

* If the main program finds something in gotone, it adds it
* onto the end of a series of target locations, and increments
* the number of known targets.

* After every 100 fangs placed, the main program goes and
* bombs all target addresses known.  This value could be
* changed depending on preferences.

* COMMENTS
* Very deadly to regenerating programs.  At least the ones
* that regenerate in the same location (i.e. Five Musketeers)

* As the number of target locations increases, the length of
* the bomb time increases.  This could be a problem.

* No protection from imp based programs, and non-mobile.  It's
* just a test program though.

* The fang placement is way too slow.  Using ICWS standard
* opcode would change that.

* Does not use ICWS standard.  Uses original A.K. Dewdney,
* with 1985 SPL opcode added.  For R.Martin Mac version of
* Core Wars, 1985

@-3
target  dat 63                  * target for fang drops
fang    mov bite,@bite          * basic fang code
bite    dat -34                 * return value for fang
                                * points to gotone
@0
start   mov #63,target          * set fang pointers
        mov #-34,bite
mainlup jmg got,gotone          * if we have a return, process
        add #9,target           * place fangs
        jmz start,target        * uses standard vampiric
        mov bite,@target        * fang placement
        sub #1,target
        mov fang,@target
        sub #8,bite
        djz memory,count        * countdown for memory bomb
        jmp mainlup             * loop back
memory  mov #100,count          * memory bomb.  reset counter
        jmz mainlup,numgot      * if nothing, return
        mov numgot,curgot       * set for attack loop
        add #1,curgot
loop    mov #-5,target2         * setup for bomb.  
        sub @curgot,target2
        mov #10,attacks         * we bombs 10 cells at target
                                * area.
loop2   mov #0,@target2         * main bomb loop
        add #1,target2
        sub #1,attacks
        jmg loop2,attacks
        sub #1,curgot
        cmp curgot,#1
        jmp mainlup
        jmp loop
got     add #1,numgot           * add a target point
        mov gotone,@numgot
        mov #0,gotone           * reset gotone
        jmp mainlup+1
count   dat 100

@34
target2
gotone  dat 0                   * where fangs return values
attacks dat 0
curgot  dat 0
numgot  dat 0                   * number of known targets
                                * points to last in series
* target data starts here, as it's added.
*CB

-----------------------

  If you're not familiar with this form of code, and you want to convert it
to ICWS '88, look into the orginal two A.K.Dewdney Core War columns from
SA, or The Armchair Universe...SA May '84 and March '85, I believe...

  This is pretty much the same as the code from my original post, but you
might want to inspect this for actual implementation details.

  Now, we need some major improvements.

  Mobile code, including copying and updating the target points (and making
sure none of them were pointing to where we have just moved).

  Imp protection.  Adding a simple imp killer will probably save us from a
lot of that stuff.  It will slow down bombing.

  Faster fang placement.  This is really important.  The program is useless
if it can't hit before getting hit.

  Faster bombing.  This shouldn't be hard.  I think I used the DJN opcode in
my original posting to cut it to three lines...

-------  

  I'm afraid a lot of the techniques might be a little inefficient 
compared to some of the stuff developed by the ICWS community in the past 
years.  This happens when you haven't followed changes in the game.  I'd
especially like to see a better fang, and fang placement.  I've seen the
improved vampired JMP fang ( the jmp @0,something) that you get from being
able to play with the B operand.  I think I've figured out a way of doing
this, by using the fang as
 
mov 0,whatever

  Where whatever points to gotone.  The whole instruction gets moved, and
you have to B operand to play with.  I guess you have to move and entire
dat 0,0 instruction to reset gotone though.  I'm not sure qbout this, though,
I'm not all that familiar with the ICWS '88 structure. If someone would 
comment on this method...

  I notice that ICWS standards could probably do a lot for this program.
If I have some spare time during exams, and my IBM back, I'll rewrite
this with a pile of major fixes, and repost the whole discussion...

  
-------------------------------------------+---------------------------------  
Chris Beauregard                           | If all the world's a stage, what
cpbeaure@descartes.waterloo.edu            | do we do when the audience starts
"If you can't beat 'em, take 'em with ya!" | throwing stuff?



Subject: King of the Hill
From: wms@iwarp.intel.com (William Shubert)
Organization: Intel iWarp, Beaverton, Oregon, USA
Date: 4 Dec 91 06:02:32 GMT
Message-ID: <1991Dec4.060232.7106@iWarp.intel.com>


   OK, folks, I spoke of it earlier and now it's ready.  An implementation of
King of the Hill corewar - a cumulative tournament.
   Justin seems to have finished up his also, but hey, enter both!
   How to enter?  Simple!  Format your corewar program as follows:

;redcode
;Name <Insert the name of your program here>
;Author <Insert your name here>
<Insert your program here>

And mail it off to: wms@iwarp.intel.com

The ";redcode" line is very important; without it my demon will think that it's
mail for me and not enter it in the tournament.
After receiving your mail, the demon should within a few minutes try to
assemble it and reply to you with a message either telling you that all is
well or that your program couldn't compile.  If something goes wrong it will
try to tell you what.

The assembler is fully ICWS '88 compatible WITH the following exceptions:
   A comma is required between two operands.
   The EQU pserdo-op does a parenthesized text insertion instead of straight
      text insertion.
   The core size is 8000 instructions.
   In addition to the normal +, -, *, and / operators parenthesis can be used
      in an argument.  I do not think that this is in ICWS '88.

Notice that it implements every goofy restriction in the standards; for
example, DAT instructions can only support immediate or pre-decrement
argument(s).
   So hurry up!  Send any program you have, no matter what it may be like,
and when I get enough together I'll run the tournament.  It is round-robin with
every program playing every other 10 times (5 going first, 5 going second).
3 points for a win, 1 for a tie, 0 for a loss.

SAMPLE PROGRAM:
;redcode
;name Dwarf
;author A. K. Dewdney
bomblen:	equ	progend - bomb
bomb:	dat	#0
start:	add	#bomblen,bomb
	mov	bomb,@bomb
	jmp	start
progend:
	end	start

PS - DON'T include a line like ";address this problem" in your code; this will
be interpreted as your return address for a mailer.
PPS - I may not have sufficiently tested this program.  It may crash, in which
case all later programs sent in will not get replies.  If this happens,
please bear with me.  Also, if you get a "weird" error message tell me about
it.
				-Bill (wms@iwarp.intel.com)


