Subject: Validation Suite Update
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: 19 Dec 1991 05:43:01 GMT
Message-ID: <164D814D85.DURHAM@ricevm1.rice.edu>

; Proposed Validation Suite for ICWS'88 Memory Array Redcode Simulators
; ---------------------------------------------------------------------
;         Author(s):   Mark A. Durham
; Last Modification:   December 18, 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,     #0      ; b(#,<) c(<,#) d(<,<)
        END     start

; Result: Failure on second cycle at stop
; Explanation: The A-field of JMP <2, <2 is completely evaluated before
;       the B-field is evaluated.  In this case, that means the jump will
;       be 2 (from <2) plus -1 (from #0 decremented once) = 1 (stop).
; Memory: change becomes DAT #0, #-2 (two less than 0)

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

; PVS #10(a-f)

start   MOV     #0,      0      ; b(#,@) c($,$) d($,@) e(@,$) f(@,@)
stop    DAT     #0,     #0
        END     start

; Result: Failure on second cycle at stop
; Memory: Unchanged

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

; PVS #11(a-d)

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

; Result: Failure on second cycle at stop
; Memory: Unchanged

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

; PVS #12

start   MOV      1,     <1
stop    DAT     #0,     #1
        END     start

; Result: Failure on second cycle at stop
; Memory: Unchanged!
; Explanation: This behaviour is open to interpretation.  If one
;     "completely" evaluates the A-operand first, one should make a copy
;     of the instruction labelled "stop" as part of that evaluation.
;     Then when the B-operand is completely evaluated as
;     start + 1 + (1 - 1) = stop, the copy of the instruction labelled
;     "stop" (prior to the decrement) is copied onto the instruction
;     labelled "stop" (after the decrement), restoring "stop" to its
;     initial state.
;              There are those who would argue, and not without
;     substantial basis, that there is no explicit reference in the
;     standards to a "copy" and therefore the instruction labelled
;     "stop" (after the decrement) should be copied onto itself.  Thus
;     stop would appear as "stop DAT #0, #0" after execution.

; Systems that "copy" the A-operand instruction include The MADgic Core
;     and Core War Pro.


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

; PVS #13

start   MOV     @0,     <1
stop    DAT     #0,     #1
        END     start

; Result: Failure on second cycle at stop
; Memory: Unchanged
; Explanation: See explanation under PVS #12


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

; PVS #14(a-b)

start   MOV     <1,      1     ; b(<,@)
stop    DAT     #0,     #1
        END     start

; Result: Failure on second cycle at stop
; Memory: stop becomes DAT #0, #0 (one less than one)
; Explanation: Here the decrement occurs before the copy.  Therefore,
;     DAT #0, #0 is moved onto itself.  Note that @1 is evaluated as
;     start + 1 + 0 = stop since the decrement occurred before the
;     B-operand was evaluated.


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

; PVS #15

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

; Result: Failure on second cycle at stop
; Memory: stop becomes DAT #0, #0
;         change becomes a copy of start: DAT #0, #0


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

; PVS #16(a-b)

start   ADD     #1,      1      ; b(#,@)
stop    DAT     #1,     #0
        END     start

; Result: Failure on second cycle at stop
; Memory: stop becomes DAT #1, #1


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

; PVS #17

start   ADD     #1,     <1
stop    DAT     #1,     #1
        END     start

; Result: Failure on second cycle at stop
; Memory: Unchanged


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

; PVS #18(a-d)

start   ADD      1,      1      ; b($,@) c(@,$) d(@,@)
stop    DAT     #2,     #0
        END     start

; Result: Failure on second cycle at stop
; Memory: stop becomes DAT #4, #0


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

; PVS #19

start   ADD      1,     <1
stop    DAT     #2,     #1
        END     start

; Result: Failure on second cycle at stop
; Memory: stop becomes DAT #4, #1
; Explanation: See the explanation for PVS #12


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

; PVS #20

start   ADD     @0,     <1
stop    DAT     #2,     #1
        END     start

; Result: Failure on second cycle at stop
; Memory: stop becomes DAT #4, #1
; Explanation: See the explanation for PVS #12


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

; PVS #21(a-b)

start   ADD     <1,      1      ; b(<,@)
stop    DAT     #2,     #1
        END     start

; Result: Failure on second cycle at stop
; Memory: stop becomes DAT #4, #0


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

; PVS #22

start   ADD     <1,     <1
stop    DAT     #2,     #1
        END     start

; Result: Failure on second cycle at stop
; Memory: start becomes ADD <3, <1
;         stop  becomes DAT #2, #-1 (one decremented twice)
; Explanation: See explanation of PVS #12


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

; PVS #23(a-b)

start   SUB     #1,      1      ; b(#,@)
stop    DAT     #1,     #0
        END     start

; Result: Failure on second cycle at stop
; Memory: stop becomes DAT #1, #-1


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

; PVS #24

start   SUB     #1,     <1
stop    DAT     #1,     #1
        END     start

; Result: Failure on second cycle at stop
; Memory: stop becomes DAT #1, #-1


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

; PVS #25(a-d)

start   SUB      1,      1      ; b($,@) c(@,$) d(@,@)
stop    DAT     #2,     #0
        END     start

; Result: Failure on second cycle at stop
; Memory: stop becomes DAT #0, #0


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

; PVS #26

start   SUB      1,     <1
stop    DAT     #2,     #1
        END     start

; Result: Failure on second cycle at stop
; Memory: stop becomes DAT #0, #-1
; Explanation: See the explanation for PVS #12


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

; PVS #27

start   SUB     @0,     <1
stop    DAT     #2,     #1
        END     start

; Result: Failure on second cycle at stop
; Memory: stop becomes DAT #0, #-1
; Explanation: See the explanation for PVS #12


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

; PVS #28(a-b)

start   SUB     <1,      1      ; b(<,@)
stop    DAT     #2,     #1
        END     start

; Result: Failure on second cycle at stop
; Memory: stop becomes DAT #0, #0


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

; PVS #29

start   SUB     <1,     <1
stop    DAT     #2,     #1
        END     start

; Result: Failure on second cycle at stop
; Memory: start becomes SUB <-1, <1
;         stop  becomes DAT #2, #-1 (one decremented twice)
; Explanation: See explanation of PVS #12



Subject:    B-field of spl
From: <ASMQK@ASUACAD.BITNET>
Organization: Arizona State University
Date: Thursday, 19 Dec 1991 11:38:25 MST
Message-ID: <91353.113825ASMQK@ASUACAD.BITNET>

I have the following ideas to keep spl as a tool not a weapon.
The assembler can generate a random number (CHECK) for each warriors.
The spl command split the execution only if it's B-field id equal to
CHECK.
So if we want to split our program we can write:
    spl somewhere    CHECK
But our program possibly will not split because of an spl 0 0 bomb since
0 is not equal to CHECK.

nandor sieben       asmqk@asuacad



Subject: SPL parents and mice
From: kurt@crash.cts.com (Kurt Werle)
Organization: Crash TimeSharing, El Cajon, CA
Date: 19 Dec 91 19:49:17 GMT
Message-ID: <1991Dec19.194917.16437@crash.cts.com>

I don't have a copy of corewars yet (havent' written it :-), but it seems to
me that if SPL is implemented where each child get 1/2 it's parents CPU time
mice will once again become very hard to beat.
If you kill a mouse, it's 'brothers' will become stronger as always, but if
you 'catch' a mouse (eg. vampire) you will NOT weaken the others (only
it's children mice).  The only way a mouse will slow down is if it
multiplies; that's the whole idea!
I don't think we want that to happen.
I DO like the diversified spl commands, though.  Especially the thread one.
If you want a program that can't be split, just use a thread and kill the
parent process.  I recall a large program from CoreWars! the mac program
that had 3 dwarves, and picket tests, etc.  It could use threads for all but
the parent process (and keep the parent loop SMALL) to keep from getting 
vamped (which was one of it's big problems).  (the program was > 80 lines).
my 2 cents
Kurt



Subject: Re: SPL parents and mice
From: cedman@golem.ps.uci.edu (Carl Edman)
Organization: University of California, Irvine
Date: 20 Dec 91 04:10:33 GMT
Message-ID: <CEDMAN.91Dec19201025@714-725-3177.nts.uci.edu>

In article <1991Dec19.194917.16437@crash.cts.com> kurt@crash.cts.com (Kurt Werle) writes:
   I don't have a copy of corewars yet (havent' written it :-), but it seems to
   me that if SPL is implemented where each child get 1/2 it's parents CPU time
   mice will once again become very hard to beat.
   If you kill a mouse, it's 'brothers' will become stronger as always, but if
   you 'catch' a mouse (eg. vampire) you will NOT weaken the others (only
   it's children mice).  The only way a mouse will slow down is if it
   multiplies; that's the whole idea!
   I don't think we want that to happen.

No, that won't happen if the split command is changed the right way
i.e. each child gets 50% of the CPU of the parent _and_ when a process
gets killed its CPU share is lost. That way when you catch a mouse you
do damage exactly proportional to the number mice which there are i.e.
you don't kill all mice as it is currently (via SPL 0), nor do you do
in effect no damage at all (as it would be if only DAT #0 was
effective). In fact you could achieve the same effect even on an
implementation which redistribute CPU power, by using JMP 0 bombs.

Overall this change to SPL seems very fair to me. It limits the power
of bombers, without making them completely ineffective, thus restoring
balance. And balance is more than anything else which makes for good
games and interesting new developments.

   I DO like the diversified spl commands, though.  Especially the thread one.
   If you want a program that can't be split, just use a thread and kill the
   parent process.  I recall a large program from CoreWars! the mac program
   that had 3 dwarves, and picket tests, etc.  It could use threads for all but
   the parent process (and keep the parent loop SMALL) to keep from getting 
   vamped (which was one of it's big problems).  (the program was > 80 lines).

Well, if for one do not like the proposals for half a dozen new
versions of the SPL command. IMESHO there already are too many
commands, particularily too many commands doing almost the same things
(i.e. who ever uses the SUB command ?).

        Carl Edman



Subject: Re: SPL parents and mice
From: wms@iwarp.intel.com (William Shubert)
Organization: Intel iWarp, Beaverton, Oregon, USA
Date: 20 Dec 91 05:53:56 GMT
Message-ID: <1991Dec20.055356.28624@iWarp.intel.com>

Well I think I can answer this question definitively.

I just ran a bunch of fights of mice vs. Leech with parents splitting to share
CPU time and Leech wins about 4/5 of the time.  How?  The mice run so slow just
from their own splitting that Leech manages to capture almost all of them
on it's own!  Then once all but a few are captured the captured ones finish
the job off by clearing the core before their brethren can breed.

Along the subject of changes to Corewar, I also disagree more than one way to
split is completely unnecessary.  There should be one and only one way.

The suggestion I saw recently - use the B op of SPL as an ID that must match -
I like also, maybe more then the split-time idea.  Why?  Because vampires can
STILL drain time if they're real smart or persistent (by trying IDs until one
works or maybe searching the enemy code, trying one B op after another).  Also,
let's say all programs start with ID=0; then the command
	ID	a,b
sets ID to "b" if it is CURRENT "a", otherwise it's a no-op.  This leaves tons
of nifty ideas; for example, imagine two threads with IDs 1 and 2 execute this
code:

	SPL	proc1,#1
	SPL	proc2,#2
	dat	#0

This will take two processes executing the same code and make them jump to
separate places!  Anyway it might be worth trying.

Which brings me this this: A list of what I have planned for KotH:

1) Try new instructions.  Mark Durham had the clever idea of trying a bunch of
   'em at once and automatically keeping track of how many people use each to
   decide which to keep.
2) Try setting a maximum write distance.
3) Try the SPL variant outlined above.
4) Add a usable interface.  Right now my Corewar is designed for KotH so it's
   almost no fun at all to use interactively.  If I just strap a cheesy X
   windows interface onto it I could distribute the source code each time a
   new Corewar variant is tried so people could try out their program ideas on
   exactly the system used for the tournaments.

   Anyway, these will all have to wait 'cause I'm going on vacation.  See my
next post.
				-Bill (wms@iwarp.intel.com)
--
Hi!  I'm a .signature virus.  Copy me into yours and join the fun!



Subject: Christmas Corewar
From: wms@iwarp.intel.com (William Shubert)
Organization: Intel iWarp, Beaverton, Oregon, USA
Date: 20 Dec 91 06:05:19 GMT
Message-ID: <1991Dec20.060519.28825@iWarp.intel.com>


   Hello everybody and thanks for making King of the Hill work so well!  There
were some bugs there for a while but things are working smoothly now so thanks
for hanging in.  Recently I've been getting 5 to 10 entries per day and
there's been a lot of variety.
   But hey, nothing lasts forever and I've been working for 6 months now
without a single vacation so I need it.  I will leave corewar up while I'm
gone (I'm getting back January 5) but if anything goes wrong and the demons
die that'll be it.  Here's what you can do to help out while I'm gone:

   Feel free to submit programs, but if you don't get a response PLEASE DO NOT
      RESUBMIT YOUR PROGRAMS.  If you get no response then something has gone
      wrong and there is NOBODY HERE TO PUT IT RIGHT.  Resubmitting will just
      make a bigger mess for me to clean up when I get back.
   Please, PLEASE, PLEASE, if you have a program on the top 10 list do not
      submit a slight variant of it!  Wait for your first program to fall off
      the list then try out the new one.
   This site only keeps mail for a few days so any posts over the next two
      weeks I won't see.  If you want to let me know something please mail it
      in.

Happy holidays everybody!  Have nice vacations!  And keep trying out your
   programs!  You may have noticed that today I got the ";strategy" lines
   printed out in status reports.  Include them in your programs!

The current Hill:
  W/  L/  T                                      Name   Score
254/157/ 29                                 Leech 1.1     791
250/172/ 18                                 Parasite2     768
228/195/ 17                                  parasite     701
223/189/ 28                                   Ecstacy     697
223/214/  3                                   dodgem6     672
162/162/116                      Intangible Worm 88.1     602
195/241/  4                                    El Rey     589
164/191/ 85                                        42     577
149/189/102                                     Virus     549
172/244/ 24                                    Killer     540

The program "42" is by Stefan Roettger, the author of Ecstasy.  Nice to see
he's around.

Here's the ;redcode-x hill (splitting causes children to share the parent's CPU
time):
  W/  L/  T                                      Name   Score
225/160/ 55                                    El Rey     730
210/142/ 88                                 Leech 2.0     718
205/135/100                              Twin Dwarves     715
212/152/ 76                                 Minidwarf     712
201/146/ 93                                slowdown-x     696
159/164/117                                   Splice2     594
 88/ 68/284                                      Nova     548
140/200/100                            Retrovirus 1.2     520
 89/140/211                                   Modify2     478
 85/156/199                                      host     454
Not as much action has been here as on the ;redcode hill - come on, feel free
to submit any program to both hills!
				-Bill (wms@iwarp.intel.com)
--
Hi!  I'm a .signature virus.  Copy me into yours and join the fun!



Subject: are changes to SPL REALLY necessary?
From: orb@ccwf.cc.utexas.edu (Norman Richards)
Organization: The University of Texas at Austin, Austin TX
Date: 20 Dec 91 16:54:19 GMT
Message-ID: <64178@ut-emx.uucp>


  Am I the only one - or are there other people out there who think that
changes to SPL are totally unnecessary?  I definately see that SPL bombs
and other forms of similar attacks are verytough - but would changing things 
really make things better?  I dont think so - whatever you change it to - 
programs will be written to exploit it.  Then - someone will think its 
obviously unfair or that there are of course better ways to do it (which is
of course true because then all of this persons neat creations would do much 
better).  
 I honestly don't see anything wrong with the way the SPL is implemented that
wouldnt be cured by some form of memory paging or higher cost for further
indexing memory type stuff.  (hows that for being techinical :)  No - I
dont think it is the be all and end all of corewar solutions, but it does
certainly seem to me that the main problems with SPL are things that just
wont be changed with changing the implementation of SPL.  There are just
ALLWAYS going to be clever forms of attack using SPL no matter what you do.
But - a neat balance would occur between SPL power (As well as other 'clever'
forms of attack) and intellegence given that we address the overall 'problem'
of any program being able to read/write anywhere in memory.
 (on the other hand - I also like the original idea of specifying the maximum
number of subprocesses allowed by a SPL.  If any changes were made this would
seem to be the most sensible.  Its just that I don't think that this addresses
the heart of the problem.)
______________________________________________________________________________
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: are changes to SPL REALLY necessary?
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Organization: Vanderbilt University School of Engineering, Nashville, TN, USA
Date: 20 Dec 91 18:16:10 GMT
Message-ID: <1991Dec20.181610.7905@vuse.vanderbilt.edu>

In article <64178@ut-emx.uucp> orb@ccwf.cc.utexas.edu (Norman Richards) writes:
> (on the other hand - I also like the original idea of specifying the maximum
>number of subprocesses allowed by a SPL.  If any changes were made this would
>seem to be the most sensible.  Its just that I don't think that this addresses
>the heart of the problem.)

But it does! The current problem with SPL is that it is overwhelmingly used 
as a weapon. The SPL/descendant-count instruction is a good antidote against
it (a process created by SPL addr #0 is unaffected by SPL 0 type bombs)
without being "too easy". It takes some clever programming to avoid having a
SPL-resistant, self-replicating warrior succumb to its own process restric-
tions. This is the kind of "intelligent" program I'd like to see encouraged!

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

Happy Holidays, 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: Re: are changes to SPL REALLY necessary?
From: solman@athena.mit.edu (Jason W Solinsky)
Organization: Massachusetts Institute of Technology
Date: 21 Dec 91 02:24:50 GMT
Message-ID: <1991Dec21.022450.14463@athena.mit.edu>

In article <64178@ut-emx.uucp>, orb@ccwf.cc.utexas.edu (Norman Richards) writes:
|> 
|>   Am I the only one - or are there other people out there who think that
|> changes to SPL are totally unnecessary?  I definately see that SPL bombs

I'm willing to bet that there are quite a few out there. I'm not one of them.
Between January 10th and February 1st I will be taking a poll on this issue (as
per a previous posting by MAD). I also hope to be able to poll people on how they
would like SPL to change, although that is still uncertain.

|> and other forms of similar attacks are verytough - but would changing things 
|> really make things better?  I dont think so - whatever you change it to - 
|> programs will be written to exploit it.  Then - someone will think its 
|> obviously unfair or that there are of course better ways to do it (which is
|> of course true because then all of this persons neat creations would do much 
|> better).  
|>  I honestly don't see anything wrong with the way the SPL is implemented that
|> wouldnt be cured by some form of memory paging or higher cost for further
|> indexing memory type stuff.  (hows that for being techinical :)  No - I
|> dont think it is the be all and end all of corewar solutions, but it does
|> certainly seem to me that the main problems with SPL are things that just
|> wont be changed with changing the implementation of SPL.  There are just
|> ALLWAYS going to be clever forms of attack using SPL no matter what you do.

The idea here is to increase the potency of longer programs, not to kill off the
use of SPL as a mode of attack. I think a secondary goal is to keep everything
simple. That's not accomplished by multiple SPL commands, and that's not
accomplished by complicated memory addressing schemes. That's why I oppose all of
these EXCEPT the limited addressing range restriction which keeps the code simple
AND improves the diversity.

Jason W. Solinsky



Subject: Re: SPL parents and mice
From: solman@athena.mit.edu (Jason W Solinsky)
Organization: Massachusetts Institute of Technology
Date: 21 Dec 91 03:42:39 GMT
Message-ID: <1991Dec21.034239.16674@athena.mit.edu>

In article <CEDMAN.91Dec19201025@714-725-3177.nts.uci.edu>, cedman@golem.ps.uci.edu (Carl Edman) writes:

|>    ...it seems to me that if SPL is implemented where each child get 1/2
|>    it's parents CPU time mice will once again become very hard to beat...
|> 
|> No, that won't happen if the split command is changed the right way
|> i.e. each child gets 50% of the CPU of the parent _and_ when a process
|> gets killed its CPU share is lost....

This is why redistributing the parent's time is so important. Mice can be killed
with or without redistribution (i.e. JMP 0 and vampires). If you just kill lost
CPU slices, then a program can't terminate it's own processes. And DON't propose
any of these ownership of memory things. The whole idea of corewars is that two
programs are competing in neutral territory.

|>         Carl Edman

Jason W. Solinsky



Subject: Re: SPL parents and mice
From: cedman@golem.ps.uci.edu (Carl Edman)
Organization: University of California, Irvine
Date: 21 Dec 91 16:42:03 GMT
Message-ID: <CEDMAN.91Dec21084155@714-725-3177.nts.uci.edu>

In article <1991Dec21.034239.16674@athena.mit.edu> solman@athena.mit.edu (Jason W Solinsky) writes:

> This is why redistributing the parent's time is so important.

I agree. Ownership of memory is a Bad Thing. Still, JMP 0 bombs under
CPU redistribution are not perfect for several reasons:

1. They don't really kill the process. That means that to win, you
have to have a second pass of DAT #0 bombing (and hope that you didn't
miss even a single little enemy process - otherwise that single
process again gets the total CPU power of the enemy).

2. JMP 0 bombs can be fixed i.e. an error-correcting program can
notice the bomb, simply fix the spot where the bomb occured, and the
bombed process is again fully in operation.

Not any longer being able to terminate yourself might be a problem,
though I'm not convinced it is. If it should turn out to be, a real
terminate instruction TRM which redistributes might be added to
redcode.

An additional advantage of non-redistributing deaths, is that this
might be a way to keep additional score during the course of a
corewar. Each program starts out with a CPU power of 1 and as the
programs fight each other slowly (or not so slowly sometimes) they
wear down each others CPU power, until one of them finally drops to 0
and the other program wins. This is one stat I'd like to see in the
graphical display of such a corewar implementation and maybe even have
the remaining CPU of the winner recorded in the final tally.

        Carl Edman



Subject: New unix version of Core Wars available!!!
From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins)
Organization: Ohio University CS Dept., Athens
Date: 3 Jan 92 16:48:34 GMT
Message-ID: <4606@oucsace.cs.OHIOU.EDU>


I have finally finished the program I set out to do a long time ago (just got
lazy, that is all)!  :-)  I wrote it with intentions to write redcode that 
fully conforms to the '88 Standards, as well as for me to conduct tournaments
in various ways.  It comes with a curses display, which you may turn off and on
at will.  It is available at soda.berkeley.edu in the 'incoming' directory for
the time being.  It will hopefully get moved to the 'systems' directory at a 
later time.  If you do not have ftp access, I will be more than happy to send
it through mail (2 parts, shell archive).  My EMail address is the following:

	sadkins@bigbird.cs.ohiou.edu  <---- most of the time here
	sadkins@oucsace.cs.ohiou.edu  <---- try here if mail problems

Here is the FEATURES file that comes with my program:


			     Core Wars Deluxe v1.1
-------------------------------------------------------------------------------

Here is what it has:

  1)  Assembles programs and loads them on the fly... this keeps the clutter
	of files down a bit.  If one file has an error, then Core Wars is
	aborted without playing.  All errors are fairly descriptive.

  2)  You may fight up to 16 programs at the same time in the arena, or you
	may opt to fight one program against a set of programs, or even 
	conduct a full Round Robin event with every program fighting against
	each other, one at a time.  There is also the ability to battle 
	programs repeatedly and then display the total results.

  3)  You may specify a configuration file on the command line to change any
	of the default options.  This allows you to change the size of the
	Core, number of cycles for each battle, the number of battles per
	game, whether you want statistics displayed, the fighting mode, etc.  

  4)  There is a nice curses display for arena battles, keeping track of all
	programs fighting, their tasks, current cycle being executed and the
	final winner of the fight.  You may change in the defaults file a 
	number of options, such as refresh rate and fading of core (aging
	effect).  Up to 16 programs can be monitored on this display.

  5)  I have a debugging mode where you can test one program if you choose.
	It has a lot of room for improvement, but it is a start.

  6)  Lots and lots more... I am going to have a job documenting this whole
	system, so I hope it is easy enough to use until then.  Full around
	with the Configuration file some, you will find that you can do a 
	lot of stuff!

Scott Adkins
sadkins@bigbird.cs.ohiou.edu


Subject: Core Wars Deluxe
From: sadkins@bird24.cs.ohiou.edu (Scott W. Adkins)
Organization: Ohio University CS Dept., Athens
Date: 8 Jan 92 21:40:31 GMT
Message-ID: <4646@oucsace.cs.OHIOU.EDU>


Hi there!

I posted an article about a week ago that I had a version of Core Wars
available through Email and ftp.  I have receive many replies and am
very greatful!  :-)  Now I have a request!

I have kept the names of all the people that have replied to the posting
and I will send the newest version to all of them.  Do not be surprised
that I do not reply for awhile or at all for the next week, since I will
be making some big changes in the compatibleness of the program and
I attend many classes and work in between them.  So, please be patient.

Also, for all of those who haven't sent me mail yet and will about wanting
a copy of the game, please enclose the type of system you are running on.
Thanks... :-)

Ok, now for the changes... I have been notified by a couple of actively
debugging people that System V is a problem in compiling in some cases.
I just got a new SysV account today, so I will be working on that as
well.  I will also be making changes to the assembler, probably from 
now on making commas in between fields a requirement... (not sure yet).
This is to make it easier to have expressions in each of the field.  The
third thing I will be working on is improving the debugger to make it 
easier in developing programs.   And the final, planned thing I am going
to do is find the nasty Core Dump that happens when certain redcode
programs fight in the arena... (Cowboy is one, and there are a couple of
other isolated incidents.)  

>From those people that have older copies of the program now, I would 
appreciate greatly to have the reports of bugs sent to me now, or sometime
soon.  I want to clean the code up and get it working as fast as possible,
and need to have the list of bugs to help me in this process.  I am very
gratified to receive bug reports from anyone out there (and I have had some
very big one reported...)

Well, thanks and I will get back to you later!
(Also, would anyone object to me in actually posting the program to this
newsgroup when I feel it is completely ready?  I have had lots and lots 
of mail, and see that it may be beneficial in general.)

Scott Adkins
bigbird.cs.ohiou.edu



Subject: King of the Hill
From: wms@iwarp.intel.com (William Shubert)
Organization: Intel iWarp, Beaverton, Oregon, USA
Date: 12 Jan 92 17:30:33 GMT
Message-ID: <1992Jan12.173033.9609@iWarp.intel.com>

Well I've recently gotten a bunch of mail requests about King of the Hill so I
guess it's time to repost the entry instructions.  Here they are.
----------------------------------------------------------------------
Entry rules for King of the Hill "standard" Corewar:

1) Write a corewar program.  KotH is fully ICWS '88 compatible, EXCEPT that
   a comma (",") is required between two arguments.

2) Put the line ";redcode" at the top of your program.  This MUST be the first
   line.  Anything before it will be lost.
   In addition, writing ";redcode verbose" or ";redcode quiet" will alter how
   much information you get on your program.  See part 5) below.
   Additionally, adding ";name <program name>" and ";author <your name>" will
   be helpful in the performance reports.  Do NOT have a line beginning with
   ";address" in your code; this will confuse the mail demon and you won't
   get mail back.
   In addition, it would be nice if you have lines beginning with ";strategy"
   that describe the algorithm you use.

3) Mail this file to "wms@iwarp.intel.com".

4) Within a few minutes you should get mail back telling you whether your
   program compiled correctly or not.  If it did compile correctly, sit back
   and wait; if not, make the change required and re-submit.

5) In a hour or so you should get more mail telling you how your program
   performed against the current top 10 programs.  If no news arrives in an
   hour, don't worry; entries are put in a queue and run through the
   tournament one at a time.  A backlog may develop.  Be patient.

   If your program makes it onto the hill, you will get mail every time a
   new program makes it onto the hill.  If this is too much mail, you can use
   ";redcode quiet" when you first mail in your program; then you will only
   get mail when you make it on the top 10 list or when you are knocked off.
   Using ";redcode verbose" will give you even more mail; here you get mail
   every time a new challenger arrives, even if they don't make it onto the
   top 10 list.

That's it!

MORE ON KOTH COREWAR IMPLEMENTATION
       Core size: 8,000 instructions
   Max processes: 8,000 per program
        Duration: After 80,000 cycles per program a tie is declared.

SAMPLE ENTRY:
;redcode verbose
;name Dwarf
;author A. K. Dewdney
;strategy Throw DAT bombs around memory, hitting every 4th memory cell.
;strategy   This program was presented in the first Corewar article.
bomb	dat	#0
dwarf	add	#4,bomb
	mov	bomb,@bomb
	jmp	dwarf
	end	dwarf

Rule variants for "eXperimental" corewar:
The same as above but use ";redcode-x" to start your program.

Your program will be entered into a second tournament with slightly different
rules.  The ruels are:
   - All addressing modes are allowed with all instructions.
   - When a process executes a "SPL" instruction the children processes
     share the PARENT'S cpu time only.  For example:

start  spl loop2
       spl loop3
loop1  jmp loop1
loop2  jmp loop2
loop3  jmp loop3
       end start

In this example, the loop "loop2" will get 1/2 of the CPU time (it gets 1/2
of it's parent's time, and it's parent was the original process) while "loop1"
and "loop3" will each get 1/4 of the CPU time (their parent was a child of the
original process, so they each get 1/2 of 1/2 of the CPU time.)  The order
of execution would be like this:
loop2 <other player> loop1 <other player> loop2 <other player> loop3
   <other player> loop2 <other player> loop1 <other player> ...etc...
----------------------------------------------------------------------
--
				-Bill (wms@iwarp.intel.com)
Hi!  I'm a .signature virus.  Copy me into yours and join the fun!



Subject: King of the Hill
From: kwhyte@math.uchicago.edu (Kevin Whyte)
Organization: Dept. of Mathematics, Univ. of Chicago
Date: 12 Jan 92 20:38:08 GMT
Message-ID: <1992Jan12.203808.23985@midway.uchicago.edu>


   King of the Hill has been going for a while now, and I imagine
we all have had some experience with it.  Strangely, the entrants
don't seem to be getting much better with time ( I can even still
get things in the top ten :) ) Anyway, I just wanted to comment on
something i thought a bit strange:  The program XTC from the '90 
competition was submitted early on and did quite well.  Eventually 
it got driven of the hill.  Well, some of my programs made it to the
hill, but XTC could stomp on all of them, so I re-submitted XTC.  As
of now, it's at #3.  A similiar thing happened with one of my programs
(submitted, made it into the top 5, eventually got kicked off, resubmitted
and again in the top 5).  So why isn't the hill getting tougher?  Are
we just designing programs to beat the ones in the top 10 and then ones to
beat those, which in turn are beaten by the original 10?  I suggest that
anyone who has ever had a program in the top 10 periodically resubmit it,
until it becomes clear that it is truely obscure.  This way, hopefully,
the hill will evolve better and better programs, and therefore no one
without net access will ever have a chance in ICWS tourneys again!

Kevin
:x



Subject: Re: King of the Hill
From: neur0mancer@maple.circa.ufl.edu (Neuro Mancer)
Organization: The CIRCA Underground
Date: 12 Jan 92 23:23:14 GMT
Message-ID: <1992Jan12.230727.4896@math.ufl.edu>


 kwhyte@math.uchicago.edu (Kevin Whyte) writes:

>   King of the Hill has been going for a while now, and I imagine
>we all have had some experience with it...

Well, my 6 instruction program kicked your 2 instruction program off :-).
However, your program could usually beat my program.  Also, Dwarf knocked
my program off.

>So why isn't the hill getting tougher?

>Kevin

Here's how I see it:  the programs in the top 5 are really the best ones.
The Bottom 5 is really easy to break into and they serve as a sort of test
for the top programs.  Don't get too cocky if you can break into the top 10.
(Although I admit that it was great the first time that I did!)
I don't think that there has been enough information and discussion here lately.
I will post my two best programs here for everyone to comment on.  They seem
pretty tough to me so why didn't they win?

======
neur0mancer%maple.decnet@pine.circa.ufl.edu
neur0mancer@oak.circa.ufl.edu (maybe)
73@arms.uucp (checked least often)



Subject: Crazy Jane
From: neur0mancer@maple.circa.ufl.edu (Neuro Mancer)
Organization: The CIRCA Underground
Date: 12 Jan 92 23:23:18 GMT
Message-ID: <1992Jan12.231712.4977@math.ufl.edu>

;redcode
;author Simon Arthur (neur0mancer@oak.circa.ufl.edu)
;name Crazy Jane
;strategy bombs with spl 0 then with DAT's
 
start    mov loc   ,    -2
         sub #390  , start
         djn start , start         
next     mov (loc+2), -10
         jmp next  , <next
 
loc      spl 0    , #-7  ; bomb here
                         ; bomb here
 
 
end start
======
neur0mancer%maple.decnet@pine.circa.ufl.edu
neur0mancer@oak.circa.ufl.edu (maybe)
73@arms.uucp (checked least often)



Subject: Eratosthenes
From: neur0mancer@maple.circa.ufl.edu (Neuro Mancer)
Organization: The CIRCA Underground
Date: 12 Jan 92 23:23:22 GMT
Message-ID: <1992Jan12.231800.5031@math.ufl.edu>

;redcode
;author Simon Arthur (neur0mancer@oak.circa.ufl.edu)
;name Eratosthenes
;strategy Bombs at large intervals.
 
begin    mov loc,@loc
         sub #391,loc
         jmp begin
loc      dat #-7
 
 
 
======
neur0mancer%maple.decnet@pine.circa.ufl.edu
neur0mancer@oak.circa.ufl.edu (maybe)
73@arms.uucp (checked least often)



Subject: dwarfer.red
From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins)
Organization: Ohio University CS Dept., Athens
Date: 13 Jan 92 02:46:56 GMT
Message-ID: <4671@oucsace.cs.OHIOU.EDU>


;redcode verbose
;name Dwarfer
;author Scott Adkins (sadkins@bigbird.cs.ohiou.edu)
;
;strategy Copies a one dwarven fighter out into the core every 200 locations
;strategy and starts each one.  After this is done, it continually refreshes
;strategy each fighter in case they have been damaged.  This program is very
;strategy very fast and has a bit of split bomb immunity built into it.
;
start	mov	d2,	<dst
	mov	d1,	<dst
	spl	@dst
	add	#200,	dst
	jmp	start

d1	mov	d1-1,	d1-1
d2	jmp	d1, 	<d1

dst	dat	#0,	#200
	end	start



Subject: killer.red
From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins)
Organization: Ohio University CS Dept., Athens
Date: 13 Jan 92 02:48:04 GMT
Message-ID: <4672@oucsace.cs.OHIOU.EDU>


;redcode verbose
;name Killer
;author Scott Adkins (sadkins@bigbird.cs.ohiou.edu)
;
;strategy A simple program that copies itself to another location, starts
;strategy that copy, and then spends its remaining lifetime bombing memory
;strategy near itself.  It is more or less a dwarf-like mice program.
;
src     dat     #0,     #10

start   mov     #10,    src
copy    mov     @src,   <dst
        djn     copy,   src
        spl     @dst
        mov     src,    src
kill    mov     dst,    <src
        jmp     kill,   <src

dst     dat     #0,     #777
        end     start



Subject: virus.red
From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins)
Organization: Ohio University CS Dept., Athens
Date: 13 Jan 92 02:49:22 GMT
Message-ID: <4673@oucsace.cs.OHIOU.EDU>


;redcode verbose
;name Virus
;author Scott Adkins (sadkins@bigbird.cs.ohiou.edu)
;
;strategy Copies itself through memory (slowly) to help ensure survival.  It
;strategy also launches two dwarves to help out with cleaning the memory.  It
;strategy then spends the rest of the time splitting to memory locations, 
;strategy hoping that it will execute and enemy program and make it all that
;strategy much harder to win.
;
src	dat	#0,	#0

start	mov	dst,	loc1
	mov	src,	loc2
	mov	#111,	host
	mov	#111,	dst

	spl	dwarf1
	spl	dwarf2
	spl	virus

copy	mov	#30,	src
loop	mov	@src,	<dst
	djn	loop,	src
	spl	@dst
	add	#777,	dst
	jmp	copy

virus	spl	@host
	add	#111,	host
	jmp	virus
                                 
dwarf1	add	#111,	loc1
	mov	loc1,	@loc1
	jmp	dwarf1

dwarf2	sub	#111,	loc2
	mov	loc2,	@loc2
	jmp	dwarf2

loc1	dat	#0,	#0
loc2	dat	#0,	#0
host	dat	#0,	#0
dst	dat	#0,	#0
	end	start



Subject: Re: looking for CoreWars for Amiga
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: 13 Jan 92 15:59:17 GMT
Message-ID: <1676D8C80.DURHAM@ricevm1.rice.edu>

The MADgic Core for the Amiga is also available on soda.berkeley.edu
where you will also find many, many Redcode programs and other
systems and files of interest to the Core War community.

MAD



Subject: Re: King of the Hill
From: wms@iwarp.intel.com (William Shubert)
Organization: Intel iWarp, Beaverton, Oregon, USA
Date: Mon, 13 Jan 1992 17:02:05 GMT
Message-ID: <1992Jan13.170205.1721@iWarp.intel.com>

Mark Durham posted:
>I think the hill would improve if the programs there were judged by not
>only how they do in the tournament run when a new warrior is submitted,
>but also how well they did in past tournaments.

   I'm perfectly willing to make changes to KotH if anybody can come up with a
scoring algorithm that is better than the current one.  I tried to think of
one that was superior, but I couldn't.  One thing I don't want is an algorithm
that favors programs already on the hill; if you enter a program, it should
have the same score regardless of whether it just arrived or it has been there
for months.  A good program is a good program.

>That way a program that had been doing well on the hill would not suddenly
>disappear because of just one bad round.

Actually, this can't happen.  Because the complete tournament is not re-run
with each new entry, but old scores are kept around, a bad round can only
effect 1/10th of your score, MAX.  And because in any given round your program
fights 40 times, let's say "a bad round" means you suffer 10 losses that should
have been wins (that's pretty unlikely anyway).  That a difference of only
30 points; enough for any of the bottom 5 to fall off (which is probably why
they do fall off constantly) but not enough for the top 5.

   One improvement that could definitely be made would be to lengthen the
hill.  I will probably be getting a much more powerful workstation within the
next few months and when it arrives I should be able to keep around the top
25 programs.  Hopefully this will make the top 10 to 15 programs fairly
stable.
--
				-Bill (wms@iwarp.intel.com)
Hi!  I'm a .signature virus.  Copy me into yours and join the fun!



Subject: Re: King of the Hill
From: snewman@Neon.Stanford.EDU (Steven Newman)
Organization: Computer Science Department, Stanford University, Ca , USA
Date: Mon, 13 Jan 1992 19:26:28 GMT
Message-ID: <1992Jan13.192628.22360@CSD-NewsHost.Stanford.EDU>

> [discussion of why the Hill isn't getting tougher]

Well, I think one reason is that it's hard to write really sophisticated
programs in standard Core Wars, but I don't want to start that thread again.
(And no, I haven't submitted anything to the experimental Hill, but that's
just due to lack of time.)

The major reason is that there isn't enough feedback.  The ;strategy lines
are nice to see, but not everyone uses them, and even with them it's hard to
know why your program wins or loses against another.  You really have to see
two programs fighting on a visual display to understand why one beats
another, and how you might modify yours to do better.  In the interests of
stimulating the Hill, I'll post source to my dodgem6 program (which, contrary
to assertions as to the stability of the top 5, has been observed to leap from
position 1 to position 10 or vice-versa in just a few rounds):

;redcode
;name dodgem6
;author Steve Newman (snewman@cs.stanford.edu)
;strategy Write out a bunch of flag values and wait for the enemy
;strategy to bomb one.  Analyze enemy's bomb location.  Copy a dwarf
;strategy type program to a location that appears safe and transfer
;strategy control to it.  Large size is due to a simple one-shot
;strategy redundancy mechanism that helps resist damage in early stage
;strategy of play.


bomb       EQU start-60   ;Presumed to be a DAT 0,0 instruction.

;Write a flag value (77) to 64 well-scattered locations.
start      SUB #248,-15
           MOV #77,<(start-15)
           MOV #77,<(start-15)
           DJN start,#32

;Now repeatedly check the 64 locations until one of them is altered.
search     SUB #248,start
           CMP #77,<start
           JMP hit,<start ;predecrement leaves start pointing to first of
           CMP #77,<start ;     the flag values, as when other CMP fires.
           JMP hit
           DJN search,#0 ;crash after 8000 loops so we don't self-tie

;Buffer so initialization code doesn't act as a target for XTC-type
;searches.
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0

hit        ADD <copyPtr,sum       ;take a checksum of cargo1
           DJN hit,#sumEnd-sum
copyPtr    JMZ cargo1,sumEnd      ;if checksum came to 0, use cargo1
           JMP cargo2             ;otherwise use cargo2

           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0

;Copy the contents of start1...end1 to the bombed location, aligning
;so that dwarf1 goes just before our two flag values (which will be
;obliterated along with the rest of the target area).  Shift forward
;2400 positions (on the assumption that gcd(2400,enemy's bombing
;pattern) >= 4) to deal with programs that start bombing immediately
;behind themselves.
copyOffset EQU 2399+end1-dwarf1
copyLen    EQU end1-start1+1

sum        DAT #122
cargo1     ADD #copyOffset,start
copyLp1    MOV <ptr1,<start
           DJN copyLp1,#copyLen
           JMP @start ;now branch to the copied dwarf

;a buffer zone of 14 zero values to avoid triggering XTC-style bombers
start1     JMP dwarf1
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0

;This is the "dwarf" program that we turn into.
dwarf1     MOV dwarf1+4,<dwarf1+5
           JMP dwarf1,<dwarf1+5

;another length-14 buffer zone
           DAT #0
           DAT #0
           DAT #-41
           DAT #-41
sumEnd     DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
end1       DAT #0
ptr1       DAT #0

;Redundant copy of "cargo".
cargo2     ADD #copyOffset,start
copyLp2    MOV <ptr1+dwarf2-dwarf1,<start
           DJN copyLp2,#copyLen
           JMP @start ;now branch to the copied dwarf

start2     JMP dwarf2
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0
           DAT #0

;This is the "dwarf" program that we turn into.
dwarf2     MOV dwarf2+4,<dwarf2+5
           JMP dwarf2,<dwarf2+5
           DAT #0
           DAT #0
           DAT #-41
           DAT #-41

           END start

This program is a bit complex; the best waty to understand it is to watch it
run.  It was more or less optimized to beat XTC, but does well against almost
any non-parallel program.  The odd use of DJN search,#0 where you'd expect
a simple JMP search (near the beginning of the program) is so that the
program dies, rather than sitting forever, when played against itself; this
gives it about 60 points (for 20 wins and 20 losses) under the Hill scoring
scheme, rather than 40 points (for 40 ties) if this were "fixed".  The
drawback is that if it fights another completely passive program, it will
eventually commit suicide rather than tying.  Maybe it would be better if,
rather than committing suicide after 8000 loops, it entered "dwarf" mode.



Subject: Sargent
From: kwhyte@dickson.uchicago.edu (Kevin Whyte)
Organization: Dept. of Mathematics, Univ. of Chicago
Date: 13 Jan 92 21:04:31 GMT
Message-ID: <1992Jan13.210431.29362@midway.uchicago.edu>

;redcode
;name Sargent
;author Kevin
stomp dat #0,#0
start add offset,bomb
      jmz start,@bomb
      slt us,bomb
      jmp recruit,0
      mov offset,pit
      jmp start ,0
recruit mov #46,recruit
        sub offset,bomb
loop    add step,bomb
        mov bomb,@bomb
        djn loop,recruit
        jmp start,0
labor   mov help,stomp
pit     spl -1,0
        jmp -1,0
help    spl 14,0
bomb    jmp -3,0
us      dat #0,#-20
offset  dat #-23,#23
step    dat #-3,#3



Subject: Fleas
From: kwhyte@dickson.uchicago.edu (Kevin Whyte)
Organization: Dept. of Mathematics, Univ. of Chicago
Date: 13 Jan 92 21:07:24 GMT
Message-ID: <1992Jan13.210724.29530@midway.uchicago.edu>

;redcode verbose
;name Fleas
;author Kevin
start mov <-1,<-1
      jmp start,<-2
begin mov start+1,@target
      mov start,<target
      spl @target,0
      add #200,target
      djn begin,count
      spl start,0
count dat #0,#39
target dat #0,#200
       end begin



Subject: Re: King of the Hill
From: wolfe@bmerh707.bnr.ca (Ian Woollard)
Organization: Bell-Northern Research, Ottawa, Canada
Date: 15 Jan 92 21:39:36 GMT
Message-ID: <1992Jan15.213936.28541@bmerh2.bnr.ca>

In article <1992Jan13.170205.1721@iWarp.intel.com> you write:
>Mark Durham posted:
>>I think the hill would improve if the programs there were judged by not
>>only how they do in the tournament run when a new warrior is submitted,
>>but also how well they did in past tournaments.
>

Of course this is a standard problem, with standard solutions in human
games such as chess, tennis etc.

Suggested 'optimal' solution:

1. Keep all the entrants.
2. Maintain a score from tournament to tournament
3. Randomly play off entrants (as many games as you have time for!)
4. Update the scores based on how good each player is thought to be,
   and whether they won or lost.

Anybody know a good algorithm for 4? I used to have one that I grabbed off the
net from rec.games.chess...

-Ian.    Min. sig. of world unite!


-- 
--



Subject: Re: King of the Hill
From: <JJJ101@psuvm.psu.edu>
Organization: Penn State University, Fayette Campus
Date: Thursday, 16 Jan 1992 00:05:14 EST
Message-ID: <92016.000515JJJ101@psuvm.psu.edu>

In article <1992Jan15.213936.28541@bmerh2.bnr.ca>, wolfe@bmerh707.bnr.ca (Ian
Woollard) says:
>
>In article <1992Jan13.170205.1721@iWarp.intel.com> you write:
>>Mark Durham posted:
>>>I think the hill would improve if the programs there were judged by not
>>>only how they do in the tournament run when a new warrior is submitted,
>>>but also how well they did in past tournaments.
>>
>
>Of course this is a standard problem, with standard solutions in human
>games such as chess, tennis etc.

This a little off subject, but an interesting idea might be to
run all 10 (11?) programs in the core simultaneously. Repeat this
50 times. If first place per round is 10 pts., max score is 500.

Coresize and MAXPROC would need to be raised. This is also a
good scenario to test the "window" idea.

--
James



Subject: Re: Omega?
From: polari!mrp@sumax.seattleu.edu
Organization: Mad Rabbit Productions
Date: 16 Jan 92 04:41:35 GMT
Message-ID: <1992Jan16.044135.12549@polari.uucp>

In article <92016.001449JJJ101@psuvm.psu.edu> JJJ101@psuvm.psu.edu writes:
>I think there is some kind of commercial software called Omega which
>uses a BASIC/English syntax to program tanks.

For the Apple II series, there's Robot War, a game very much like
c-robots but which uses a graphic display (rather than character-based)
for the combat arena and a BASIC-like language and structures.

For the Macintosh series, there's RoboWars, 'bots, and one other game
(MegaBots, I think) that are all essentially the same as Robot War.
Having tried them all, I've found 'bots to be the most interesting,
since each robot may have a variety of weapons, abilities, and defensive
systems.

I've never heard of Omega, though.



Subject: Re: Omega?
From: dkoski@noao.edu (David Koski)
Organization: National Optical Astronomy Observatories, Tucson AZ
Date: 16 Jan 92 23:42:04 GMT
Message-ID: <1992Jan16.234204.13529@noao.edu>

In article <92016.001449JJJ101@psuvm.psu.edu> JJJ101@psuvm.psu.edu writes:
>I think there is some kind of commercial software called Omega which
>uses a BASIC/English syntax to program tanks.
>
>1. Anyone ever hear of this game?

Yes, I have it for the Atari ST.  It is from Origin, makers of Ultima and
Wing Commander.

>2. Is it too aimed at the non-programmer to appeal to corewar/c-bots
>   players?

Well, not really.  You can do some advanced stuff with it like have teams of
tanks cooperating.  It supposedly has 'AI', but I can't see any (unless you
write the code yourself).  It gets fairly boring to watch once you get to
OMEGA class, so I never play it any more.

Anyway the programming can be very verbose if you want, but the allow you
to abbreviate everything.  You can have loops, procedures, etc.  You have
to deal with the equipment your tank has too.  For instance most of my tanks
had a turbo laser, it fired quickly, but didn't do much damage.  I would race
into range and just start blasting my target (without following its movement,
hopefully I would be fast enough to do major damage) and then run away.  I
got all the way to OMEGA class (you must beat a computer tank 70% of the time
to go up in class) using this tank.

>3. A review would be nice.

It was OK.  I paid about $25 for it, and I guess it was worth it.  I use xtank
on my NeXT now, and xtank is better...  free too.

David Koski



Subject: Re: Omega?
From: mcganm@aix02.ecs.rpi.edu (Mark Robert Mcgann)
Organization: Rensselaer Polytechnic Institute, Troy NY
Date: 17 Jan 92 04:27:57 GMT
Message-ID: <qfwr08g@rpi.edu>

In article <1992Jan16.234204.13529@noao.edu> dkoski@noao.edu (David Koski) writes:
>In article <92016.001449JJJ101@psuvm.psu.edu> JJJ101@psuvm.psu.edu writes:
>>I think there is some kind of commercial software called Omega which
>>uses a BASIC/English syntax to program tanks.
>>
>>1. Anyone ever hear of this game?
>
>Yes, I have it for the Atari ST.  It is from Origin, makers of Ultima and
>Wing Commander.
     I own this game for the IBM.  Its actually the reason I looked up this
news group.  I'm looking for other people who own the game who would be 
interested in swapping tanks.  The biggest problem I had with the game was
after I beat all the computer tanks I had nothing to fight by my own.  If
anybody out the is interested please e-mail me.

                              -Mark McGann
                              -mcganm@rpi.edu



Subject: Re: Omega?
From: ajpierce@med.unc.edu (Andrew Pierce)
Organization: UNC-CH School of Medicine
Date: 17 Jan 92 14:04:06 GMT
Message-ID: <1992Jan17.140406.3437@samba.oit.unc.edu>

In article <92016.001449JJJ101@psuvm.psu.edu> JJJ101@psuvm.psu.edu writes:
>I think there is some kind of commercial software called Omega which
>uses a BASIC/English syntax to program tanks.
>1. Anyone ever hear of this game?
>2. Is it too aimed at the non-programmer to appeal to corewar/c-bots
>   players?
>3. A review would be nice.

   There is indeed such a program, in fact, I have it for the Amiga.  It
is a lot of fun.  There is a BASIC/English like command language with
which you write the tank's AI and a section for designing the various
parameters of the tank's physical nature such as weight, engine type,
weaponry systems etc.  Initially, you start out limited in the number of
physical systems you can use.  Gradually, as you advanvce (by defeating
the computer test-tanks) you can add on more and more equipment.  There is
no such limit on the AI and a tank at any level can have the same AI,
however, as new equipment is added (for example a scanner lock/jammer
combination) you need to add new AI to control the new gear.  I have found
that usually when I start from the beginning again, the tank needs to go
through about 2 radical redesigns as it advances.  Ultimately, all
restrictions are removed and you can have whatever gear you want.  This
ultimate step appears to not be the most fun to play though as a tank with
a "sit and wait to kill the other guy" with some rudimentary tit-for-tat
and retreat intelligence seems to have a significant edge.  More fun is to
impose a restriction on the amount of credits usable to build the tank.
   C-bots players would probably love this.  It is identical to c-bots,
except that the tanks fight where there is terrain to figure in, and
different equipment to figure in too.  Also, there is a feature whereby
tanks can communicate with each other which allows "team-tank" strategies
although I haven't messed with that a whole lot.
   The game is sufficiently interesting that I still dig it out from time
to time years after I got it.
   Where to get it:  Origin Systems Inc., P.O. Box 161750, Austin, Texas
78716, or at least this is what it says on my (several years old) box for
it.
     -Andy
ajpierce@med.unc.edu



Subject: POLL
From: solman@athena.mit.edu (Jason W Solinsky)
Organization: Massachusetts Institute of Technology
Date: 17 Jan 92 20:40:23 GMT
Message-ID: <1992Jan17.204023.14582@athena.mit.edu>

Should SPL as it is defined in the International Core War Society Standard
of 1988* remain in any future standard(s)?

YES: SPL should remain unchanged.  This does not preclude altering Core
     War in other ways (e.g. range addressing) or the possible inclusion
     of additional task-launching opcodes and instructions.

NO:  SPL as it exists in ICWS'88 should be changed, replaced, or dropped
     entirely from future standards.

This is merely an opinion poll and is non-binding on the ICWS.

Send replies to:  solman@Athena.MIT.EDU

Votes should be clearly indicated either YES or NO, but comments are
welcome.

* SPL as it is currently defined in ICWS'88 places the new task at the back
of the task queue such that all previously existing tasks (including the
currently executing task with the SPL instruction) will execute one
instruction each prior to the new task executing its first instruction.
Each task has an equal share of the warrior's processor time (one instruction
per turn).

Jason W. Solinsky



Subject: POLL II
From: solman@athena.mit.edu (Jason W Solinsky)
Organization: Massachusetts Institute of Technology
Date: 17 Jan 92 20:54:24 GMT
Message-ID: <1992Jan17.205424.15620@athena.mit.edu>

I am collecting possible implementations of SPL for a future poll. The poll will
list all possible variations of SPL and will ask people that answer it to rank as
many choices as they wish. The choice with the lowest number of first place votes
will then be eliminated and its votes spread amongst the other choices by second
choices. This will be repeated until there are two left. If all the ranked
options on a given ballot are eliminated, then that ballot will be discarded.
This system, used in Cambridge Cuty Council elections, makes sure that very
similar options do not hurt each other. Once one of the options is eliminated, it
will inheret the other's vote. The poll will be non-binding for the ICWS.

The following options have been identified thus far. Please send mail describing
any options not listed.

A) Keep SPL exactly the way it is

B) Keep SPL as it is, but put the new task at the begining of the queue

C) Keep SPL as it is, but put the new task at the end of the queue and BEFORE the
original task.

D) Change SPL by splitting the parents time between its children

E) Change SPL by splitting the parent's time between its children and make sure
that the next time the new task executes is after the next time the old task
executes.

I expect to get ATLEAST 10 other variants.


Jason W. Solinsky



Subject: C-robots testing...
From: JJJ101@psuvm.psu.edu
Organization: PSU
Date: 18 Jan 92 20:31:32 GMT
Message-ID: <92018.153132JJJ101@psuvm.psu.edu>

I took 8 crobot programs and ran each unique group of 4, 5 times.
This is a total of 350 matches. (70*5).

Scoring: 3 points for a win, 1 point each for a tie, 0 points for mutual
         destruction.

Results: (Highest possible score is 525)

pingpo.r  414
sniper.r  135
scan.r    129
h-k.r     108
hak3.r     90
t.r        87
counter.r  57
rook.r      9

Comment1: It took my PS/2 model 30-286, 3 hours to run all the matches
Comment2: All eight programs came with my crobots package.
Comment3: If you would like the results of each match, send e-mail.
          (The file is 2607 lines, so I'm not posting it.)



Subject: Corewars Deluxe Version 1.3
From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins)
Organization: Ohio University CS Dept., Athens
Date: 18 Jan 92 21:23:39 GMT
Message-ID: <4711@oucsace.cs.OHIOU.EDU>

Once again I will announce another delay in the distribution of the
Core Wars Deluxe V1.3 program.  The new version has lots of bugs fixed,
and I am now working on a couple of other things.  Included will be
support for System V and Berkeley Unix, as well as support for X Windows
and Curses.  There is also an option for both X Windows and Curses together
and will automatically detect the type of display you are running on and
set up accordingly.  The reason for the delay is because of the X Windows
module being added and integrated into my code.  I now have a friend helping
me a lot in getting this done, for which I am grateful.  Another thing I will
do before releasing the newer version is to add a little documentation about
the assembler, program, and the display.  I will also add some comments to 
the code, since that time has come.  

The new version will still not support the following:
	Fully operational debugger (maybe in V1.4).
	EQU statements in the Redcode.
	Parenthesis and proper handling of expressions in the Redcode.

I will gladly still take requests for the proram, and I will also be 
posting the program to this Newsgroup (and maybe some others, but here 
first) in the future.   Thank you for your patience and support.  

For those sending in requests, I request the following information:
	The type of system and version of system you are running on...
		(for example:  BSD Unix 4.3 Reno)
	The correct address to send the program to...
		(for example:  sadkins@bigbird.cs.ohiou.edu)

The reason for the last is that some address are non-returnable and hard
to decipher.  I would appreciate addresses so that I can reply faster and
more correctly.  Keep in mind that your address may work fine for you, but
may be not-so-good for me.

Thank you and Happy programming!!! :-)

Scott Adkins
sadkins@bigbird.cs.ohiou.edu



Subject: Update to CoreWar Pro (PC) available at soda
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Organization: Vanderbilt University School of Engineering, Nashville, TN, USA
Date: 19 Jan 92 21:52:55 GMT
Message-ID: <1992Jan19.215255.14094@vuse.vanderbilt.edu>

Finally got to upload the result of some spare time over Christmas to soda:
CoreWar Pro version 3.02 is now available by anonymous FTP from
soda.berkeley.edu as pub/corewar/{incoming|systems}/corwp302.zip

This is an extended ICWS'88 Core War system for PC-compatibles with a
windowing and menu-driven interface and strong debugging support.

What's new:

        A new indirect addressing mode, post-increment indirect (">").

        A number of non-standard instructions are no longer supported. Since
        pre-decrement and post-increment indirect addressing together can be
        used to implement a "software stack", the dedicated
        stack-instructions (GSB, RET, PSH, POP, SSZ) are no longer needed and
        were thus eliminated. The process control instructions SSP and RLS
        were abandoned, because SSP has overwhelming offensive potential
        (pointed out by several people on rec.games.corewar).

        The two operand version of SPL (Split with descendant count) has been
        debugged and renamed to SPC to avoid confusion with ICWS'88 SPL. The
        descendant_count(on/off) switch is therefore superfluous.

        The B-operand of MOV, ADD, SUB, RND and EXC can now be immediate for
        compatibility with ICWS'86 programs.

        An inconsistency in the order of operand evaluation in ADD and SUB
        instructions has been fixed.

        Interface: program prompts now allow editing the default string
        (thanks to Per Pilse for the modified ioreadln library module).

For validation of archive integrity here's the output of "pkzip -v":

 Length  Method   Size  Ratio   Date    Time   CRC-32  Attr  Name
 ------  ------   ----- -----   ----    ----   ------  ----  ----
   8321  Implode   3465  59%  01-19-92  13:15  7170d4c6 --w  CORE.DOC
  60311  Implode  18302  70%  01-16-92  01:32  1b94501a --w  COREMAN.DOC
  78090  Stored   78090   0%  01-19-92  03:14  0940c0bb --w  CORE.EXE
   1103  Implode    579  48%  12-20-91  14:48  b3732b9f --w  CORE.SYS
   1721  Implode    822  53%  12-18-91  23:59  3009b864 --w  CORESTD.SYS
   6418  Implode   2091  68%  10-20-91  01:34  9340a795 --w  COREMUS.DEF
    102  Shrunk      75  27%  12-04-91  02:58  9d090241 --w  DWARF.RED
   1614  Implode    668  59%  11-19-91  01:53  779489ee --w  DAGGER.RED
    518  Implode    304  42%  01-19-92  12:52  51de31c4 --w  XTC.RED
 ------          ------  ---                                 -------
 158198          104396  35%                                       9

DIR CORWP302.ZIP
CORWP302.ZIP   105834   1-19-92   13:15


Your feedback is welcome.

Enjoy,
        Stefan (stst@vuse.vanderbilt.edu)



Subject: Mac: Robo War
From: fau@po.CWRU.Edu (Francis A. Uy)
Organization: Case Western Reserve University, Cleveland, OH (USA)
Date: Tue, 21 Jan 92 19:51:47 GMT
Message-ID: <1992Jan21.195147.4772@usenet.ins.cwru.edu>


Just wanted to mention that the Macintosh has
 a shareware program called RoboWar which is, 
 as far as I can tell, very similar to Tom's
 CROBOTS game.  

RoboWar was written by some California kids
 (I think).  I could look it up when I go home
 if anyone's interested.

There is also another Mac robot-programming 
 game called 'Bot, which was written by someone
 at Harvard and should be available by ftp from
 one of the husc servers.  I've never tried it.
-- 
Francis A. Uy      410.465.1316   "You must rely on the lightning and not
fau@po.cwru.edu    410.461.0960    forecast the dance."   -- Van, quoting
                                   Graves, messing with my mind



Subject: Announcement: 1st rec.games.corewar Crobots Tournament
From: <JJJ101@psuvm.psu.edu>
Organization: PSU
Date: Tuesday, 21 Jan 1992 17:50:32 EST
Message-ID: <92021.175032JJJ101@psuvm.psu.edu>

Announcing the 1st rec.games.corewar Crobots tournament.

1. HOW TO SUBMIT:

Mail one and only one crobots program to jjj101@psuvm.psu.edu OR
jjj101@psuvm.bitnet, with the following header:

//<name>
//<e-mail>
//<prog-name>
//<file>

where <name> is your name. (like J. Smith)
      <e-mail> is your e-mail address
      <prog-name> is the name of your crobots program
      <file> is a LEGAL IBMPC filename with extension .r

Example:

//James Jesensky
//jjj101@psuvm.psu.edu
//Sniper 1.2
//sniper.r


2. WHAT NEXT?

Within 24 hours you should receive a notice, indicating your program
has been received. Within 48 hours you should receive a notice
indicating if the program compiled correctly.


3. WILL MY CROBOTS WORK WITH YOUR CROBOTS?

I have no idea. I'm using Crobots for DOS by Tom Poindexter. If
you have questions of compatibility, send me a note asking for
a copy of my crobot.doc file. It should work with all Amiga versions
if none of the extensions to the original language are used.


4. FORMAT OF TOURNAMENT:

Not 100% sure yet. Basically multiple round robins. CPU cycle limit
is set at 500,000. There will always be 4 hostile robots run
together, that is, 1 on 1 on 1 on 1 instead of 1 on 1 matches.

Scoring for each match:

win  -  3 pts.
tie  -  1 pt each.
mutual destruction  -  no points

A programs total score is the sum of its score for all its matches.
Each program 'fights' in the same number of matches. (Estimate: 1000)

Note: Sniper.r will be used if an even number of programs are needed.


5. DEADLINE!!

The unofficial deadline is Sun 26 at midnight. This may be extended.


6. MISC:

I will be entering the tournament also. Note that I will NOT run my
program against yours before the tournament. For honesty reasons,
I will post my source before the tournament begins. I will glance
at the comments of incoming programs but not the code. I you don't
want me looking at the comments, delete them from the source file.
Also, I won't make any changes to my program until after the tournament.



*END*



Subject: Ideas ...
From: kwhyte@math.uchicago.edu (Kevin Whyte)
Organization: Dept. of Mathematics, Univ. of Chicago
Date: 22 Jan 92 04:06:49 GMT
Message-ID: <1992Jan22.040649.9708@midway.uchicago.edu>


  There seem to be two major components to writing good
core war programs:

  Coming up with a good idea.
  Coding that idea sneakily.

(The general desire to change corewar comes from a desire to 
place greater emphasis on 1 ... I don't know, the harsh efficiency
acid test gives the truly good programs a "rose in the desert"
kind of beauty)

  Now, I'm not really a very good programmer ... at least, not
anymore (I sold my soul to abstract mathematics).  This means
I have several ideas that I can't code.  Some of these I know to
be totally unworkable, and some I would like to see:


MAKING the opponent do useful stuff: Bad idea.  Even if you manage
to get the opponent to spend all of his time doing stuff for you,
your effective speed only doubles.  What you care about is the ratio
of your effective speed to the opponents.  By making them split, you
quickly reduce their effective speed by large fectors, which gives a
gain of much larger than 2.  Now, it is useful to know when you've caught
something (because now you should just bomb all of core with dat #0's
to kill everything, since nothing is fighting back anymore).

Self-Repair: Clearly a nice idea if you can do it.  Unfortunately it
doesn't win on it's own, at best it survives.  Thus you need to run an
attacking program as well.  However, the self repair has to be FAST,
or else you will have split so many times, it won't matter what you're
trying to do.  So, the attacking goes slowly.  So the trade of is 
something like : it is 10x as hard to kill you 
                 you kill other things 20x as slowly.

 Thus a net factor of just slowing down the attacking program.  Now,
it's not impossible that the net effect could be a speed up, but I
can't even come close (+ against programs which bomb with jumps, it
is virtually irrelevant whether or not you repair the code, you still 
lose).

Battery:  The idea is to have several process split off to a jmp 0.
Then, if you need extra speed, you can just change the jump zero
to a jump to your program.  Of course this only makes sense if
you have several other processes running at the same time.  The
"best" idea I've had is to use this as a protection from spl bombs.
Namely, have your code do its loop by telling the battery to jump to the 
beginning of the loop, and dying.  Thus if your code is hit, you will
no longer request processes from the battery (which should be basically
a spl 0 or jmp 1 , jmp 1 , spl -2 type of thing).  The idea is that if
several processes are feeding off this battery at just the right rate
to make it stable, then when one dies, the others will get more and more
as the battery overcharges, largely counteracting  the opponent making
your capured process split.  This doesn't seem really practical 
either, as your opponent will make you split faster than you can split
and do something productive, so you still lose just slightly slower.
The only real use I see is in cooperation with the self-repair idea
to gain time to repair yourself after being hit with split bombs.


Double search.  A search loop someting like:

  add offset, 1
  cmp 100,-100
  jmp bombing routine
  jmp -3
 offset dat #4,#-4

 This checks 2 locations for enemies every 3 cycles instead
of the standard 1 location every 2 cycles.  The draw back is
that the program has to be longer (how do you efficiently bomb
something that you only have an A-field pointing to? The only
way I can think of, is to notice that it is the negative of the 
B-field, and do a subtraction.  So, if it doubles the length of 
the program, it isn't worth it (you kill things 1.33 times as
fast, but get killed twice as fast ... a net loss).  It would
be beneficial for any program which is really large already, but
I don't know of any viable large programs).  



 That's enough for now, I just wanted to stimulate corewar
discussion.

Kevin
kwhyte@math.uchciago.edu



Subject: How to find out if a given instruction is a JMP
From: kokeritz@lne.kth.se (Anders Kokeritz)
Organization: Royal Institute of Technolgy
Date: 22 Jan 92 16:12:51 GMT
Message-ID: <KOKERITZ.92Jan22171251@soda.lne.kth.se>

Is there any way to find out what instruction there is on a given address i 
RedCode? What I really want to do is to test if an address contains a JMP.



Subject: Re: p-robots is fun too.
From: <JJJ101@psuvm.psu.edu>
Organization: PSU
Date: Wednesday, 22 Jan 1992 13:47:21 EST
Message-ID: <92022.134721JJJ101@psuvm.psu.edu>

In article <orman.696100201@pv022c.vincent.iastate.edu>, orman@iastate.edu
(David L Orman) says:
>
>Perhaps this is a little immature for the average C programmer/ Corewar
>player, but there is a Pascal version of C robots called p-robots,  For
>those of you who dont like or are not comfortable with C.
>
>Anyway, Is there any interest in a tourament of this type?

I would assume one could write a flex program to convert a p-robot program
to a c-robot program and vs. versa.

But consider a ?-robot based on a non-procedure programming language.
Some possible examples:

prolog -- This would be interesting.
Scheme -- Scheme is a subset of Lisp; also should be interesting.

Maybe an event driven langauge like HyperTalk(tm).

Other thoughts?

James



Subject: Re: How to find out if a given instruction is a JMP
From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins)
Organization: Ohio University CS Dept., Athens
Date: 22 Jan 92 20:57:34 GMT
Message-ID: <4744@oucsace.cs.OHIOU.EDU>

In article <KOKERITZ.92Jan22171251@soda.lne.kth.se> kokeritz@lne.kth.se (Anders Kokeritz) writes:
>Is there any way to find out what instruction there is on a given address i 
>RedCode? What I really want to do is to test if an address contains a JMP.

The problem is that there is no way to really test for an instruction of 
any type without wasting a lot of time doing it.  I guess it can be done...
Let me see... I can't guarentee the following code to work, but I will give
it a swing...

loc	jmp	124,	0		;To be examined in memory...
	 .
	 .
	 .
dst	dat	#0,	loc		;Pointer to possible jmp instruction
hold	jmp	0,	0		;For holding the contents
zero	dat	#0,	#0		;For adding operations

	add	loc,	hold		;hold is now "jmp 124, 0"
	cmp	loc,	hold		;if they are equal skip next
	jmp	noteq			;nope, do something else
	jmp	equal			;it is a jmp instruction!!!


Now there are problems with all of this... What if the jmp statement has
a different mode in either of the fields?  Then this would naturally fail.
I think in the case of the Leech prorgram, this method would work.  In case
of other types of vampiric programs, it would fail against the following:
	jmp	@0,	124
 	     -- OR --
	jmp	@1
	dat		#124

What do you think?  My way is to just search for a non-zero statement and
ASSUME that it is a jmp statement.  I then use the address to trace back to
the enemy program and bomb that location.  This does not work well against 
programs that bomb with DATs instead of JMPs.

Scott Adkins
sadkins@bigbird.cs.ohiou.edu



Subject: Re: Ideas ...
From: ajpierce@med.unc.edu (Andrew Pierce)
Organization: UNC-CH School of Medicine
Date: 22 Jan 92 22:34:13 GMT
Message-ID: <1992Jan22.223413.17101@samba.oit.unc.edu>


   Hi everyone.  I have been playing at corewars for a few days now,
including KOTH (auger, 7th or 8th grade prog that was on yesterday for a
while).  Sometimes it is possible to make progs that don't fare well in an
all out destructo fight but that can still be fun to look at.  I submitted
one called "Spreel".  What it did is that the prog made an exact copy of
itself and then started a casual bombing routine.  The neat part was that
the child of the parent program then did the same thing, making a child of
itself (a grandchild of the original) and then going into the casual
bombing routine.  The bombing routines were set up such that each process,
if all went well, should be killed by its grandchild.  There was a timer
in the progs such that if the program sensed that it was still alive after
the time at which it should have been killed by it's grandchild, it
assumed that either its child or its grandchild or both had gone wrong and
so it then went back to the beginning and had another child, copied to the
same location as the original child.  Then it would again wait to be
killed by its grandchild etc.  
   It was a beautiful little prog and it was kind of fun to watch as it
delicately stepped through memory, occasionally activating the repair
circuit.  It did reasonably well against a lot of the simpler programs but
didn't have that combination of resistivity, speed and sheer destructive
power that seems to be required to get on the hill (it got massacred).
Still, the idea of modelling "life-like" situations like that with redcode
is still something to kick around.  I notice that various people have
tried a variety of "virus-like" and "parasitic" progs that have had a
greater or lesser degree of success.
     -Andy
ajpierce@med.unc.edu

P.S.  Is the hill really flooded at the moment?  I submitted a prog about
16 hours ago and still no word.
P.P.S  Code for "Spreel" to follow.  Thanks to the others who posted code.
I find that "Fleas" is a good test prog.  Unfortunately, I haven't managed
to get "Sargent" to work.  Is whoever made it out there?



Subject: Re: How to find out if a given instruction is a JMP
From: rogue@cellar.org (Rachel McGregor)
Organization: The Cellar BBS and public access system
Date: 22 Jan 92 22:13:50 GMT
Message-ID: <R02yeB3w164w@cellar.org>

kokeritz@lne.kth.se (Anders Kokeritz) writes:

> Is there any way to find out what instruction there is on a given address i 
> RedCode? What I really want to do is to test if an address contains a JMP.

you can use the CMP instruction or one of its derivatives to see whether your 
target cell contains a JMP instruction, but it will only work if you know the 
data that should be in the cell.  Therefore, you can use JMPs in a trap, 
which you can later check to see if it's been sprung, but unless you're 
lucky, you're not going to find a JMP trap before you step in it.  
*Unless*...

  Considering the fact that most JMP traps are JMP 0 instructions, you can 
code the following:

JMP 2
JMP 0
CMP -1 target

<note that the above is complete pseudocod, since I'm just beginning to 
familiarize myself with redcode protocols>

What you do from there is up to you.

---
"As they say around the [Texas] Legislature, if you can't | Rachel McGregor
 drink their whiskey, screw their women, and vote against | rogue@cellar.org
 'em anyway, you don't belong in office." -- Molly Ivins  | Public Usenet/BBS



Subject: Re: How to find out if a given instruction is a JMP
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: Thu, 23 Jan 1992 00:23:27 GMT
Message-ID: <16776102A8.DURHAM@ricevm1.rice.edu>

I assume that people want to know how to check for instructions with
a particular opcode and do not know (or do not care about) the associated
operands.  The original question was about JMP, so I will use that as
my example.

x     ??? a, b              ; Unknown instruction.
      ...
start MOV x, copy           ; Make a copy for non-destructive test.
      SUB copy, copy        ; Subtract copy from itself to zero operands,
      CMP test, copy        ;    and compare.
      ...
test  JMP 0, 0              ; Opcode of interest and zeroed operands.
copy  ??? a, b              ; Does not matter.  We'll copy over it.

This is not perfect though.  The comparison depends on the modes of the
operands.  JMP <a, #b is not the same as JMP <a, <b.  You have to run
through all of the possibilities:

test1 JMP 0, #0
test2 JMP 0, 0
test3 JMP 0, @0
test4 JMP 0, <0
test5 JMP @0, #0
test6 JMP @0, 0
etc.

Not a pleasant proposition.

Mark A. Durham
MAD



Subject: Core Wars Deluxe Announcement
From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins)
Organization: Ohio University CS Dept., Athens
Date: 23 Jan 92 01:56:03 GMT
Message-ID: <4750@oucsace.cs.OHIOU.EDU>


I finally announce that the program is ready to distribute!!! :-)  Now, the
only problem I have found was that there was many, many requests for the
program, making it difficult for me to send it to everyone.  Since all of 
the requests were generated from this Newsgroup, and since I have heard quite
a few "Yeahs" and no "Nays" about posting the program here, I will now do so.

I will also, from this point on, send the program to any new people who could
not get it from here for whatever the reason.  It will make it easier for me
to get this to as many people as possible.  Also, I will place it in the 
/pub/corewar/incoming directory of the soda.berkeley.edu ftp site.  I will post
the shar archives here, and put the tar archive at the ftp site.  I will be
glad to help anyone who does not know how to get the program using these two
means.

The next 5 postings will be the shar archive.  Be sure to strip off the post
header at the front of the archive before running them through the "sh" 
command.  Good luck and I hope you enjoy it!

Thanks,
Scott Adkins
sadkins@bigbird.cs.ohiou.edu



Subject: On the Value of Speed...
From: fau@po.CWRU.Edu (Francis A. Uy)
Organization: Case Western Reserve University, Cleveland, OH (USA)
Date: Thu, 23 Jan 92 04:14:56 GMT
Message-ID: <1992Jan23.041456.29767@usenet.ins.cwru.edu>


I have noticed that in the documentation of various
 programs posted here, the author will say that a
 particular function is "fast".  Speed is of course
 a good thing, but I wish people would say exactly
 how fast it is.  Is there an established  format
 for these quantitative measures?

To borrow from Life, I call affecting one new
 location per cycle "c", for the speed of light.
 To my knowledge, it is impossible to attain c,
 except for statements like
LOC  DAT 0, -1
     DJN 0, <LOC
    (did I get that right?)
 which merely decrements b fields.

I'm about to get booted.

More later.
-- 
Francis A. Uy      410.465.1316   "You must rely on the lightning and not
fau@po.cwru.edu    410.461.0960    forecast the dance."   -- Van, quoting
                                   Graves, messing with my mind



Subject: Re: How to find out if a given instruction is a JMP
From: ajpierce@med.unc.edu (Andrew Pierce)
Organization: UNC-CH School of Medicine
Date: 23 Jan 92 15:30:05 GMT
Message-ID: <1992Jan23.153005.18744@samba.oit.unc.edu>

In article <16776102A8.DURHAM@ricevm1.rice.edu> DURHAM@ricevm1.rice.edu (Mark A. Durham) writes:
>x     ??? a, b              ; Unknown instruction.
>start MOV x, copy           ; Make a copy for non-destructive test.
>      SUB copy, copy        ; Subtract copy from itself to zero operands,
>      CMP test, copy        ;    and compare.
>test  JMP 0, 0              ; Opcode of interest and zeroed operands.
>copy  ??? a, b              ; Does not matter.  We'll copy over it.

   I don't think so.  In addition to having to test for all variations of
addressing modes, as you mentioned, the basic question is still
unresolved.  What if the test instruction is MOV 0,0 for example.  My
impression was that CMP compared operands only, NOT the instruction as
well.  That is, 

a	mov 0,0
b	jmp 0,0
c	cmp a,b		;comparison returns true
	end c

   If I have mis-understood this, please let me know!
      -Andy
ajpierce@med.unc.edu



Subject: corewars:  Spreel.s
From: ajpierce@med.unc.edu (Andrew Pierce)
Organization: UNC-CH School of Medicine
Date: 23 Jan 92 15:59:04 GMT
Message-ID: <1992Jan23.155904.22005@samba.oit.unc.edu>


   As promised:

; spreel
; by Andy Pierce          (ajpierce@med.unc.edu)
; 1992

leng  dat #0,#24           ; put prog length in B field
x     dat #0,#0
sor   dat #0,#0
dest  dat #0,#0

begin mov #21,bomb
      mov #21,insur
      mov leng,x
      mov #1610,dest        ; new prog is 1610 units forward (7x230)
      add leng,dest
      mov #-2,sor
      add leng,sor

loop  mov <sor,<dest
      slt leng,x
      djn loop,x
      add #4,dest
      spl @dest,0

      mov #-1593,x
kloop mov bomb,@x
      sub bomb,x
      slt insur,bomb
      djn kloop,bomb
      jmp begin

bomb  dat #0,#0
insur dat #0,#0
      end begin


Subject: Re: How to find out if a given instruction is a JMP
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: Fri, 24 Jan 1992 01:29:55 GMT
Message-ID: <167771123B.DURHAM@ricevm1.rice.edu>

In article <1992Jan23.153005.18744@samba.oit.unc.edu>
ajpierce@med.unc.edu (Andrew Pierce) writes:
>   I don't think so.  In addition to having to test for all variations of
>addressing modes, as you mentioned, the basic question is still
>unresolved.  What if the test instruction is MOV 0,0 for example.  My
>impression was that CMP compared operands only, NOT the instruction as
>well.
>   If I have mis-understood this, please let me know!
>      -Andy
>ajpierce@med.unc.edu

You HAVE misunderstood Redcode.  One may compare an immediate mode
A-operand with the B-operand of a target instruction with CMP as in
   CMP #6, loop
or one may compare ENTIRE instructions - opcodes, operands, and modes -
as in
   CMP test, bomb
when using any non-immediate mode A-operands.

Mark A. Durham
MAD


Subject: ClonerII.s, or "fun with Corewar"
From: kdmiller@athena.mit.edu (Kenneth D Miller)
Organization: Massachusetts Institute of Technology
Date: Fri, 24 Jan 1992 04:10:27 GMT
Message-ID: <1992Jan24.041027.18051@athena.mit.edu>

A short time ago, I created a nasty little program called CLONER, and a little
later, a somewhat more optimized version called (surprise!) CLONER II.  It's
function was to copy itself ahead in memory and split to that copy.  However, the
destination is decremented during copy, so that it points to the space IN FRONT OF
the copy.  A tight loop searches for another good spot to hit.  So, here it is...

;CLONER II, written by kdmiller@athena.mit.edu

SRC	mov	 FIX,	-1	;set up the SouRCe counter (and do bonus "attack")
CPY	mov	@SRC-1,	<DST	;fat, unrolled loop to copy...
	mov	<SRC-1,	<DST	;does it in 15 cycles
	mov	<SRC-1,	<DST
	mov	<SRC-1,	<DST
	djn	 CPY,	 SRC-1
DST	spl	 @DST,	 5000	;activate new copy
HNT	jmz	 HNT,	<DST	;search for a new spot...
	jmp	 SRC		;copy again
FIX	dat	 0,	 12	;this is the starting value for SRC-1
	dat	 0,	 0	;death-dealin' data
	dat	 0,	 1
	end	 src

This program does not seem to do well against "Stunners" (SPL 0) and "Vampires"
(JMP bombs), though.  However, it does extremely well against fast, pattern
bombers (like Dwarf for instance).  As the "clones" get wasted, the remaining
tasks can copy even faster.  I have a MARS program with display, and against some
programs it seems to get destroyed, but then it suddenly starts to replicate like
mad, and ends up winning.

Could somebody tell me whether or not my big, unrolled loop is really effective,
given that it makes the program significantly larger?
 
I suppose taking out some of the MOV's and putting in more data wouldn't slow it
down too much, right?  The "3 MOV" version would have one more data in it (just
to make it deadlier...the alternative is to yank out two DAT's).  The "2 MOV"
version would have two more data's, or for speed's sake, no new ones.  Things get
really weird with the "1 MOV" version.  Put in as much or as little "pad" DAT's
as needed.

MOV's	COPY TIME
1	  2xLength	24 (L=12)  14 (L=7)
2	3/2xLength	18 (L=12)  15 (L=10)  12 (L=8)
3	4/3xLength	16 (L=12)  12 (L=9)
4	5/4xLength	15 (L=12)

I intend to test these various versions.  The smaller ones are harder to hit, but
the larger ones replicate significantly faster.  Other possibilities are
eliminating some of the "pad" DAT's on the end, which would reduce lethality at
the expense of speed.  However, having too much DAT slows things down with no
noticeable improvements in killing power.

One disadvantage to lots of MOV's is that it puts restraints on program
length (ex: for 4, the program must be an even multiple of 4 instructions in
length)
-- 
kdmiller@athena.mit.edu   |  Yep, it's KENNY MILLER... 
    ///                   |  DESTINED TO BE THE GREATEST PROGRAMMER
\\\///  Amiga Makes It    |          *** E V E R ! ! ! ***
 \XX/     Possible!       |     (or at least second-greatest...)




Subject: Repost mars.c
From: JJJ101@psuvm.psu.edu
Organization: PSU
Date: 24 Jan 92 18:18:16 GMT
Message-ID: <92024.131816JJJ101@psuvm.psu.edu>

Someone posted a C program mars.c a while ago. Could they repost
it or e-mail it to me.

Thanks
James Jesensky



Subject: Re: ClonerII.s, or "fun with Corewar"
From: ajpierce@med.unc.edu (Andrew Pierce)
Organization: UNC-CH School of Medicine
Date: 24 Jan 92 21:48:27 GMT
Message-ID: <1992Jan24.214827.3767@samba.oit.unc.edu>


   The question was posed about "unrolling the loop" to increase overall
speed.  One of the disadvantages that has to be considered is that the
size of the loop of executing instructions that your program has is
increased and so it becomes more vulnerable to progs that bomb with spl
and jmp instructions.  It was mentioned that for the prog "cloner" it has
trouble against these types of progs.  This could be a contributing
factor.
     -Andy
ajpierce@med.unc.edu



Subject: Corewars executables
From: Electric.Monk@kcbbs.gen.nz (Corey Murtagh)
Organization: Kappa Crucis Unix BBS, Auckland, New Zealand
Date: 25 Jan 92 12:59:14 GMT
Message-ID: <46754.24927648@kcbbs.gen.nz>


  Can anyone tell me where I could get the corewars executables?  I 
don't have a C compiler yet, so I can't compile the source that was 
sent a few messages back.  Oh, yeah, I can't do FTP.  The local system 
won't allow it.

:-) COrey Murtagh - electric.monk@kcbbs.gen.nz



Subject: Re: ClonerII.s, or "fun with Corewar"
From: kdmiller@athena.mit.edu (Kenneth D Miller)
Organization: Massachusetts Institute of Technology
Date: Sat, 25 Jan 1992 04:25:20 GMT
Message-ID: <1992Jan25.042520.21111@athena.mit.edu>

In article <1992Jan24.214827.3767@samba.oit.unc.edu>, ajpierce@med.unc.edu (Andrew Pierce) writes:
|> 
|> One of the disadvantages that has to be considered is that the size of
|> the loop of executing instructions that your program has is increased...

Hmm... I'll resubmit ClonerII with the loop shrunk to a more reasonable size.

Maybe I can get back onto the Hill in normal division (I'm #1 in
experimental...can't get busted by SPL and JMP bombers there hehehehee)

-- 
kdmiller@athena.mit.edu   |  Yep, it's KENNY MILLER... 
    ///                   |  DESTINED TO BE THE GREATEST PROGRAMMER
\\\///  Amiga Makes It    |          *** E V E R ! ! ! ***
 \XX/     Possible!       |     (or at least second-greatest...)




Subject: KotH suggestion
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Organization: Vanderbilt University School of Engineering, Nashville, TN, USA
Date: 26 Jan 92 04:11:10 GMT
Message-ID: <1992Jan26.041110.1473@vuse.vanderbilt.edu>


There has been some talk about modifying how the score is calculated in
KotH, possibly figuring in a "history" of program performance. Personally,
I like it fine the way it works now, because newcomers are not discriminated
against.

On the other hand: While it is relatively easy to get on the hill, staying on
it for some time is hard. Perhaps we should have a "auxiliary" scoring list
that is based on the time a program has been on the hill (or rather the
number of challengers it was pitted against). This history list would have
no impact on the actual ranking, but would simply be included in the status
report as an additional field. Such as:

"Destroyer 1.1" (length 34) by "John Doe", challenged 19 times

If we want to get fancy, we can add some para-military ranks based on seniority
on the hill. Of course, this would only be for show, but this information
could be useful for writing more successful challengers.

What do you think? Would that be easy to implement, Bill?

-Stefan (stst@vuse.vanderbilt.edu)



Subject: Re: KotH suggestion
From: kwhyte@math.uchicago.edu (Kevin Whyte)
Organization: Dept. of Mathematics, Univ. of Chicago
Date: 26 Jan 92 05:06:21 GMT
Message-ID: <1992Jan26.050621.5514@midway.uchicago.edu>

In article <1992Jan26.041110.1473@vuse.vanderbilt.edu> stst@vuse.vanderbilt.edu (Stefan Strack) writes:
>
>There has been some talk about modifying how the score is calculated...


    I had been thinking about a similar thing, but I would suggest
only recording the # of successful challenges to the hill that a
program has survived.  It doesn't seem to make much sense to give
people a bonus for surviving a challenge by an imp.

Kevin



Subject: Re: KotH suggestion
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Organization: Vanderbilt University School of Engineering, Nashville, TN, USA
Date: 26 Jan 92 07:28:17 GMT
Message-ID: <1992Jan26.072817.12191@vuse.vanderbilt.edu>

In article <1992Jan26.050621.5514@midway.uchicago.edu> kwhyte@math.uchicago.edu (Kevin Whyte) writes:
>
>    I had been thinking about a similar thing...

Arguable: given that each program on the hill receives seniority points, the
number of total challenges is probably a good measure of time spend on the
hill, whereas the number of *successful* challenges depends strongly on the
combined quality of the hill. Consequently, as the hill gets tougher and 
tougher, champs would receive fewer and fewer points for averting challenges.
Not quite fair I would think.

-Stefan (stst@vuse.vanderbilt.edu)



Subject: Re: How to find out if a given instruction is a JMP
From: kokeritz@lne.kth.se (Anders Kokeritz)
Organization: Royal Institute of Technolgy
Date: 26 Jan 92 15:07:09 GMT
Message-ID: <KOKERITZ.92Jan26160709@elixir.lne.kth.se>

In article <16776102A8.DURHAM@ricevm1.rice.edu> DURHAM@ricevm1.rice.edu (Mark A. Durham) writes:

   I assume that people want to know how to check for instructions with
   a particular opcode and do not know (or do not care about) the associated
   operands.  The original question was about JMP, so I will use that as
   my example.

	< code follows >

Thanks, but now suppose I want to know the target address of the JMP I
just found, to be able to bomb it. How do I do that?



Subject: KotH
From: wms@iwarp.intel.com (William Shubert)
Organization: Intel iWarp, Beaverton, Oregon, USA
Date: Sun, 26 Jan 1992 18:57:33 GMT
Message-ID: <1992Jan26.185733.1939@iWarp.intel.com>

I like the idea of keeping track of how long a particular program has been on
the top 10 list.

On another note, the backlog was getting way too bad (up to 30 programs at
times) so I put in some effort and modified KotH to run faster.  Programs now
take only 50%-60% of the time they used to to challenge the hill, so things
should improve.  Game play has not changed at all.  In addition, I changed the
reply scripts a bit because people seemed to get confused on how their program
did.

Right now there is only about 90 points between the top and bottom programs on
the top 10.  I think that this indicates that the hill has gotten much tougher;
all programs are about equally as good.  A bad result of this is that programs
move very quickly up and down the list, often going from #1 to off the list
after only a few successful challenges.  All the more reason to keep track of
duration on the list.  Hopefully I'll get a faster workstation soon and be
able to keep a longer hill around.
--
				-Bill (wms@iwarp.intel.com)
Hi!  I'm a .signature virus.  Copy me into yours and join the fun!



Subject: Re: !!!!!! CORRECTION: *** A New Russian Challenge...
From: brown@NCoast.ORG (Stan Brown)
Organization: Oak Road Systems, Cleveland Ohio USA
Date: Sun, 26 Jan 1992 19:02:26 GMT
Message-ID: <1992Jan26.190226.13056@NCoast.ORG>

In article <1992Jan25.201048.7856@unlinfo.unl.edu> msapir@hoss.unl.edu (Mark V. Sapir) writes:

>            REMEMBER TETRIS? THERE IS SOMETHING NEW FROM RUSSIA!
>
>    Unlimited CASH PRIZE for everyone who writes just two short programs!

Yeah, right.  And I gotta bridge to sell ya.
-- 
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA   brown@ncoast.org


Subject: BattleTech games & the PC?
From: amigo@milton.u.washington.edu (The Friend)
Organization: University of Washington
Date: 27 Jan 92 00:29:02 GMT
Message-ID: <1992Jan27.002902.5305@milton.u.washington.edu>


     Is there any games of BattleTech relation (real-time, action type) out
for the IBM_PC line? One good example of a good real-time game is BattleForce
on the Amiga... good game play, plenty of options (you can build your own 
mechs for that matter). I'm looking for something similar to it on the PC.

                                                                 --> Mike



Subject: Re: How to find out if a given instruction is a JMP
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: Mon, 27 Jan 1992 06:37:33 GMT
Message-ID: <1677B8D4.DURHAM@ricevm1.rice.edu>

In article <KOKERITZ.92Jan26160709@elixir.lne.kth.se>
kokeritz@lne.kth.se (Anders Kokeritz) writes:
>Thanks, but now suppose I want to know the target address of the JMP I
>just found, to be able to bomb it. How do I do that?

target    ??? A, B               ; Target of JMP statement
          ...
jump      JMP target             ; JMP statement
          ...
pointer   DAT A, jump            ; Pointer to JMP statement
start     ADD @pointer, kill     ; Start here.  Copies ( 0 + X = X) both
                                 ;    operands from jump to kill
          MOV #0, kill           ; Zeroes out B-field of kill.  Very
                                 ;    important for trick to work.
kill      MOV #0, 0              ; Trick to move A-field to B-field.
                                 ;    Both operands now equal the A-field
                                 ;    of jump (not the same thing as POINT
                                 ;    to the same address - yet).
          ADD pointer, kill      ; These two lines make sure kill points
          ADD #pointer-kill, kill;    to the target
doit      MOV bomb, @kill        ; And we're done!


Let me know if you need a blow-by-blow description of what is happening.
I have a very powerful notation for just such a discussion.

I find these types of challenges VERY interesting.  Unfortunately, I have
spent most of my time figuring out little puzzles like this and very little
time applying the answers to actual warriors.  Most of the time, these
tricks are really too expensive to be useful in actual warriors.

Mark A. Durham
MAD

P.S. I almost completely forgot the MOV #0, 0 trick for moving A-operands
to B-operands.  There was going to be an exchange command - XCH - to do
just that in ICWS'88, but I successfully campaigned against it by discovering
this trick.  And I was wondering why it was dropped just a moment ago!



Subject: RedCode Source: QUARTER
From: hanssgen@iras4.ira.uka.de (Stefan Haenssgen)
Organization: University of Karlsruhe, FRG
Date: 27 Jan 1992 11:29:36 GMT
Message-ID: <ko7r90INNrr0@iraul1.ira.uka.de>


Well, since there seems to be a demand for sources of more-or-less
successful warriors: Here is QUARTER. It scored best in the German
Branch Section Tournaments and it's still around in KotH on the
Experimental Hill (together with two mutations of the original
QUARTER).

BTW, how do you folx like the X-Hill of KotH? Programs that use
SPLit bombs are much less effective there since they don't cripple
other processes of the program they've hit. I kinda like it :-)

This source is for use with symbolic RedCode assemblers that understand
expressions and the "=" operator. It's easier to read than the version
with the expressions evaluated.

---snip---snap---snip---snap---snip---snap---snip---snap---snip---snap---

;
; QUARTER       by Stefan Haenssgen
;
; Copies a killer to every quarter of the core and SPLits into four
; processes, each one bombing its slice of memory.
; Not very subtle but quite powerful since the killers produce a bomb
; with every second instruction and are difficult to hit.
; (The killers destroy each other after they have bombed through their
; quarter, but the battle should be decided before this happens. Speed
; is the important factor)
;

slen    =       8000            ; Core size
dist    =       loop-z1         ; Distance from killer to start of program
                                ; (killers should be at equal distances)

z1      DAT     #slen/4+dist    ; Pointer to copies
z2      DAT     #slen/2+dist
z3      DAT     #slen*3/4+dist

start   MOV     kill    <z2     ; Copy one killer ..
        MOV     loop    <z2     ; .. and ..
        SPL    @z2              ; .. start it
        MOV     kill    <z1     ; (no fancy loops here, we want speed!)
        MOV     loop    <z1
        SPL    @z1
        MOV     kill    <z3
        MOV     loop    <z3
        SPL    @z3
        JMP     loop            ; Start the fourth killer

ptr     DAT     #0              ; Pointer to target (not copied, since ..
                                ; .. core is initialized with "DAT #0")
loop    MOV     ptr     <ptr    ; Bomb with DATs ..
kill    DJN     loop     ptr    ; .. every second location in memory

        END     start

---snip---snap---snip---snap---snip---snap---snip---snap---snip---snap---


Any comments welcome. And please don't just change one or two instructions
and call the program your own ;-)


Hapy CoreWars

	Stefan

-- 
      ,-----,------,--,--,
     /     /      /  /  /   Stefan Haenssgen, Comp Sci, Uni Karlsruhe, Germany
    /  ---/-,  ,-/  /  /  
   /     / /  / /     /   haenssgen@ira.uka.de    or   uk0w@dkauni2.bitnet
  /---  / /  / /  /  / 
 /     / /  / /  /  /   "Use the SOURCE, Luke!" (Return of the RedEye Nights)
'-----' '--' '--'--'   "I feel a great disturbance in the SOURCE"



Subject: Re: KotH
From: md85-epi@dront.nada.kth.se (Urban Koistinen)
Organization: Royal Institute of Technology, Stockholm, Sweden
Date: 27 Jan 92 10:21:50 GMT
Message-ID: <1992Jan27.102150.2244@kth.se>

In article <1992Jan26.185733.1939@iWarp.intel.com> wms@iwarp.intel.com (William Shubert) writes:
[discussion of how programs move up and down quickly]
First a question:
How are scores calculated now?

Below is one or two thoughts on how it could be done:

Keep the scores between the programs.
Place the program with least points at the bottom and don't use it's
results when placing the rest.
Repeat above until there are no programs left to place.

You could do the same but in reverse.

Urban Koistinen - md85-epi@nada.kth.se
Exploring the posibilities of one fat and blind mouse.


Subject: C-robots tournament status...
From: <JJJ101@psuvm.psu.edu>
Organization: PSU
Date: Monday, 27 Jan 1992 11:58:22 EST
Message-ID: <92027.115823JJJ101@psuvm.psu.edu>

More entries are needed in the tournament!!

The deadline is extended until next Friday at midnight EST.

James



Subject: King of the Hill current standings
From: wms@iwarp.intel.com (William Shubert)
Organization: Intel iWarp, Beaverton, Oregon, USA
Date: Mon, 27 Jan 1992 17:34:57 GMT
Message-ID: <1992Jan27.173457.28181@iWarp.intel.com>

   OK, I've gotten some mail requests about this, so it's the weekly King of
the Hill update.

Top top ten on the ICWS '88 hill:
  W/  L/  T                                      Name   Score
232/144/ 64       Snow White and the Seven Dwarfs 1.2     760
229/144/ 67                                 Leech 1.2     754
229/160/ 51                                     Kinch     738
209/152/ 79                                SmallDat D     706
204/157/ 79                                    TheRat     691
204/172/ 64                              Scanner 1.01     676
185/182/ 73       Snow White and the Seven Dwarfs 1.3     628
144/154/142                                      CAKE     574
137/159/144                              Genocide 1.0     555
166/237/ 37                                  TroubleB     535

The ";strategy" lines from Snow White:
;strategy 1.0: 7 dwarfs, one target
;strategy 1.1: bigger dwarfs, and some imps too
;strategy 1.2: sacrifice thoroughness to gain speed


And now for the experimental hill:
  W/  L/  T                                      Name   Score
273/ 58/109                                 CLONER II     928
262/ 76/102                                    CLONER     888
223/186/ 31                                 Leech 2.0     700
217/202/ 21                         Schizo parasite-x     672
214/216/ 10                                  QUARTER8     652
180/166/ 94                                   Quartet     634
201/214/ 25                                Parasite-x     628
192/241/  7                                  QUARTER6     583
166/268/  6                                   QUARTER     504
125/224/ 91                                slowdown-x     466

The ";strategy" lines from CLONER II:
;strategy	quickly copies itself to a new location, splits, and then
;strategy	searches for a new location to copy itself.


Notice that in the experimental hill there is a much greater score difference
between the #1 and the #10 programs.  I think that this is caused by fewer
entries on the x-hill.
				-Bill (wms@iwarp.intel.com)



Subject: Re: C-robots tournament status...
From: cpbeaure@descartes.waterloo.edu (Chris Beauregard)
Organization: University of Waterloo
Date: Tue, 28 Jan 1992 00:40:32 GMT
Message-ID: <1992Jan28.004032.15668@descartes.waterloo.edu>

In article <92027.115823JJJ101@psuvm.psu.edu> <JJJ101@psuvm.psu.edu> writes:
>More entries are needed in the tournament!!
>

	Well, if we weren't limited to one entry apeice...

	As well, d'you have a policy on entries from people whodon't
have net access?  I can gurantee that you could pick up a few more
that way...

>The deadline is extended until next Friday at midnight EST.
>
>James

-------------------------------------------+---------------------------------  
Chris Beauregard                           | Star Trek is the unix
cpbeaure@descartes.waterloo.edu            | of television. 
"If you can't beat 'em, take 'em with ya!" |                 - Me 



Subject: Re: How to find out if a given instruction is a JMP
From: kokeritz@lne.kth.se (Anders Kokeritz)
Organization: Royal Institute of Technolgy
Date: 27 Jan 92 22:54:21 GMT
Message-ID: <KOKERITZ.92Jan27235421@elixir.lne.kth.se>

In article <1677B8D4.DURHAM@ricevm1.rice.edu> DURHAM@ricevm1.rice.edu (Mark A. Durham) writes:
>   Let me know if you need a blow-by-blow description of what is happening.
>   I have a very powerful notation for just such a discussion.

I think I understand what's going on, but I'm very interested in the notation
anyway. I've been thinking of how to best represent the inner works of a 
RedCode program in writing, probably your notation is the solution.

/Anders Koekeritz



Subject: Re: KotH suggestion
From: ajpierce@med.unc.edu (Andrew Pierce)
Organization: UNC-CH School of Medicine
Date: 28 Jan 92 05:07:54 GMT
Message-ID: <1992Jan28.050754.3826@samba.oit.unc.edu>


   What exactly is the scoring procedure for KotH?  Could someone please
post it to the net?  Maybe a system analagous to the chess rating system
would be workable.
     -Andy
ajpierce@med.unc.edu



Subject: Re: KotH suggestion
From: wms@iwarp.intel.com (William Shubert)
Organization: Intel iWarp, Beaverton, Oregon, USA
Date: 28 Jan 92 05:57:38 GMT
Message-ID: <1992Jan28.055738.15759@iWarp.intel.com>

OK, I've posted it before but here is the King of the Hill scoring system.
First I will explain what it basically is, then the optomization I made to it.

   Every time a new program arrives at the hill, all eleven program (the ten on
the hill plus the new challenger) compete.  Every program plays every other
program 40 times, plus itself 20 times.  This gives each program 440 scores
(40 * 10 opponents + 20 * 2 for fights against yourself).
   Every win counts as three points, each tie as one, and no points for a loss.
   This means that every program will get AT LEAST 40 points (twenty ties
against yourself, one point to each side for each tie, gives forty points).
   Now the programs are ranked from most points to least.  Programs 1 through
10 get to stay and fight the next challenger, number 11 disappears.
   To speed things up, King of the Hill doesn't re-fight programs
unneccessarily; when a new program arrives, the old programs play only it.
This also makes the hill a bit more stable than it would otherwise be.

   I've gotten a few suggestions on ways to improve the hill.  One thing I
don't like about chess-style/swiss-style tournaments is that programs only
play programs of about their same skill level; in corewar a program may perform
very poorly against some programs and very well against others, and the
relative "quality" of the programs involved doesn't have much to do with it.
Because of this I think it is really necessary for every program to play
every other program.
				-Bill (wms@iwarp.intel.com)



Subject: Re: C-robots tournament status...
From: <JJJ101@psuvm.psu.edu>
Organization: PSU
Date: Tuesday, 28 Jan 1992 13:01:39 EST
Message-ID: <92028.130139JJJ101@psuvm.psu.edu>

In article <1992Jan28.004032.15668@descartes.waterloo.edu>,
cpbeaure@descartes.waterloo.edu (Chris Beauregard) says:
>
>In article <92027.115823JJJ101@psuvm.psu.edu> <JJJ101@psuvm.psu.edu> writes:
>>More entries are needed in the tournament!!
>>
>
>        Well, if we weren't limited to one entry apeice...
>

Okay...I'll allow up to two entries. (That means you can submit one
or two entries). Just make sure they have unique file names.

--
James



Subject:    koth experiment
From: <ASMQK@ASUACAD.BITNET>
Organization: Arizona State University
Date: Monday, 27 Jan 1992 17:25:35 MST
Message-ID: <92027.172535ASMQK@ASUACAD.BITNET>

I cannot remember the magicword to send a program to the experimental
tournament. Could someone post it.
Would it be possible to add some new command to the koth server
for example get help , get the actual top 10 ?

nandor sieben   asmqk@asuacad



Subject: Re: KotH suggestion
From: wolfe@bmerh707.bnr.ca (Ian Woollard)
Organization: Bell-Northern Research, Ottawa, Canada
Date: Tue, 28 Jan 92 20:22:37 GMT
Message-ID: <1992Jan28.202237.27647@bmerh2.bnr.ca>

Ok. Here's how I think you should do it. Keep a rating for each program.
Whenever two programs play, use their ratings, together with whether they
win or lose as below, to decide what their new ratings are:

(Following stolen unashamedly from FAQ file of rec.games.chess...
Disclaimer: I have never tried this method, I'm just reporting results of
my research...)

Chess Ratings
-------------

Different countries have different rating systems.  The most common 
system in use is called the Elo system, named after its inventor, Arpad 
Elo.  FIDE and the USCF use the Elo system, although in the USCF there 
have been some adjustments and additions in the past which have distorted 
USCF ratings vis-a-vis systems that have been "pure Elo" forever. 

USCF has rating classes as follows (with number in class as of Oct. 1991) 

Senior Master   2400 and above       211 players 
Master          2200 - 2399          842 players
Expert          2000 - 2199        2,475 players
Class A         1800 - 1999        3,938 players
Class B         1600 - 1799        4,910 players
Class C         1400 - 1599        5,274 players
Class D         1200 - 1399        4,793 players
Class E         below 1200         5,968 players

There are more USCF members than the total 28,411 listed here.  These
are just those who have been active in tournaments recently. The
average rating on this list is 1566.  Your rating is determined by
your results and the ratings of the players you play against.

There is no hard and fast relationship between the various rating scales. 
For Grandmasters, their USCF rating *averages around* 100 points higher 
than their FIDE rating.  This difference seems to increase with weaker 
players.  Some attempts are being made by USCF to remedy this.

How Ratings are Calculated: USCF Rating, Simplified
---------------------------------------------------

**For first 20 games, (provisional rating) use the following system:**

Take the rating of the opponent +400 if the player wins.
Take the rating of the opponent -400 if the player loses.
Take the rating of the opponent if the game is a draw.

Average these numbers.  (If unrateds play other unrateds, this requires
several iterations of the above.)

**After 20 games (established rating), use the following system:**

Players rated under 2100 can win/lose a maximum of 32 points per game
Players rated 2100-2399 can win/lose a maximum of 24 points per game
Players rated 2400 and up can win/lose a maximum of 16 points per game

(This maximum is called the K factor.  In a 1/4 K tournament, divide
the above numbers by 4.)

If players of equal rating play, the loser loses half of the maximum, the 
winner gains the same amount.  No change for a draw. 

If players of unequal rating play, the higher-rated player gains fewer 
points for a win, but loses more points for a loss.  (The lower-rated 
player does the opposite, of course.)  A higher-rated player loses points 
for a draw, a lower-rated player gains points.  For players rated 400 or 
so points apart, the maximum rating change is used for an upset, and the 
minimum gain/loss is 1 point if the much higher-rated player wins. 

The true formula for the number of points won/lost versus the ratings 
difference is a curve, but a straight line approximation for players with 
a K factor of 32 points can be used, where every 25 points of ratings 
difference is one additional rating point gained/lost starting from a 
beginning of 16 points for a win/loss, and from zero for a draw. (i.e., for 
a 100 point difference, the higher-rated player gains 16 - 4 = 12 points 
for a win, but loses 16 + 4 = 20 points for a loss.  If a draw, the 
higher-rated player loses 4 points, the lower-rated player gains 4.) 

The actual formula is as follows:  

K = K_Factor
delta_R = Opponents_Rating - Players_Rating
Expected_Wins = 1/(10^(delta_R / 400) + 1)
New_Rating = Current_Rating + K (Actual_Wins - Expected_Wins)

An established player's rating cannot drop below (his rating - 100)
truncated to the next lowest hundred (i.e., a 1571 player cannot drop
below 1400).  This is called the rating's floor.
--
>>Finally, I would like to quote an `expert' on aviation who in a recent TV
interview said that "the common theme to all three of the A320 crashes is
lack of altitude"<<



Subject: KotH scoring and other suggestions
From: kwhyte@math.uchicago.edu (Kevin Whyte)
Organization: Dept. of Mathematics, Univ. of Chicago
Date: 29 Jan 92 00:04:16 GMT
Message-ID: <1992Jan29.000416.29815@midway.uchicago.edu>

  I don't really like the idea of an elo type rating system
for KotH.  My reason, which Bill has already mentioned, is that
the assumption behind giving people more or less points depending
on the rating of the opponent is that a program has an overall
"strength".  That is, virtually no one at elo 1300 will ever beat
someone at 2200.  This is not true in corewar.  As an example, my
program "Kinch" has stayed consistently in the top 5, so one
might think I win alot.  Strangely, it is common for me to get a 
message from KotH saying: Blah has challenged the hill,
                            Kinch wins: 11
                            Blah wins: 19
                            Ties: 10

  Your overall score: ...

Blah has been pushed from the hill.

So what does that mean?  Just that there are types of programs
that can beat me even if poorly written, and some types that
I will always beat (I dare anyone to write a program which splits
alot and beats me more than 5/40).  However this would mean the
ratings could not be expected to converge to any given value.
Plus, unlike chess, the majority of programs are submitted once,
and if seen again, it is in modified form, so how do we intelligently
rate them? 

 Personally, I'm in favor of the 1pt/win scoring system, and I do like
the idea of keeping track of longevity.  

 What do people think of automatically archiving the code of hill
programs once they have sufficient longevity (maybe @soda).  Do any
author want to keep their code secret?  Personally I'd love to be able
to get the code for other programs ... and if my code stops winning
once people know how it works, it deserves it.  (Actually, being able
to get the code for any of the current top 10 by sending a request to
KotH would be ideal.  I don't want to overburden Bill though, and in 
any case having them all available @soda sounds like a good idea to me.)

Kevin



Subject: corewars deluxe
From: terry@piggy.cogsci.indiana.edu (terry jones)
Organization: Jugglers Anonymous
Date: 29 Jan 92 02:01:59 GMT
Message-ID: <TERRY.92Jan28200159@piggy.cogsci.indiana.edu>


i grabbed the corewars deluxe posting the other day and installed it
fine. when i went to look for documentation on how to run it, there
was none in evidence.

is there something i am supposed to know?

i mailed the writer, but he didn't respond.

help?
terry jones     (terry@piggy.cogsci.indiana.edu)



Subject: Re:    koth experiment
From: kdmiller@athena.mit.edu (Kenneth D Miller)
Organization: Massachusetts Institute of Technology
Date: 29 Jan 92 03:23:45 GMT
Message-ID: <1992Jan29.032345.24786@athena.mit.edu>

In article <92027.172535ASMQK@ASUACAD.BITNET>, <ASMQK@ASUACAD.BITNET> writes:
|> I cannot remember the magicword to send a program to the experimental
|> tournament. Could someone post it.

" ;redcode-x " comment line at the beginning, instead of just " ;redcode".

-- 
kdmiller@athena.mit.edu   |  Yep, it's KENNY MILLER... 



Subject: Re: KotH scoring and other suggestions
From: okes@solb1.essex.ac.uk (Oke S)
Organization: University of Essex, Colchester, UK
Date: 29 Jan 92 13:40:12 GMT
Message-ID: <OKES.92Jan29134012@solb1.essex.ac.uk>

In article <1992Jan29.000416.29815@midway.uchicago.edu> kwhyte@math.uchicago.edu (Kevin Whyte) writes:

    What do people think of automatically archiving the code of hill
   programs once they have sufficient longevity (maybe @soda)...

I do not think this is such a great idea. People will write code just to 
beat the current programs on the hill.

		Simon Oke.

--
#### ### ##   ## #### ## #    email: okes@essex.ac.uk
#     #  # # # # #  # ## #    
####  #  #  #  # #  # # ##    
   #  #  #     # #  # # ##
#### ### #     # #### #  #
Live long and prosper.



Subject: EBS Valentine Tournament
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: 29 Jan 92 23:49:53 GMT
Message-ID: <1677DFAC1.DURHAM@ricevm1.rice.edu>

The Electronic Branch Section (EBS) of the International Core War Society
will be holding a Core War tournament beginning February 14, 1992.  For
those who are not familiar with the EBS, the branch section is open to
anyone with access to EMail and charges no fees; therefore feel free to
join in.  It is all very informal at his time.

With the success of KOTH, I had considered cancelling the tournament.
It is clear now however that there is a need to run the occassional LARGE
scale tournament.  So, the tournament is still on.

Unfortunately, I have not yet decided on the format.  We had some success
with a double-elimination tournament this summer (which we never did
complete - my sincere apologies to those who entered then).  This is my
personal favorite format.  Each programmer is given information about the
upcoming round and submits one warrior.  Warriors combat head-to-head against
one other warrior.  The winning programmers progress to the winners'
bracket.  The losers to the losers' bracket.  Those with two losses are
eliminated from the tournament.

Inbetween rounds, programmers receive their upcoming opponent's previous
entry into the tournament.  Each programmer can choose to resubmit her
previous entry or submit a new and different entry.  In this way, the
tournament is designed to determine the best PROGRAMMER, not just the
best program.

During the summer tournament, I would change some of the parameters of
the game (Core size, draw time, etc.) from round to round - always
informing the participants ahead of time of the new parameters.  I do not
think I would do this for the Valentine tournament.

The other choice for the Valentine tournament is a strict round-robin
tournament similar to KOTH but with all of the entries, not just eleven
at a time.

So, I need some input.  Which would you prefer: A) Double-elimination or
B) round-robin?  Mail your preference to me at durham@ricevm1.rice.edu.

Either way, it will be a core size of 8192, maximum tasks of 64, ties
declared after 100 000 cycles, and run under ICWS'88 rules.  I always
watch the matches, so if there is something grossly wrong with your program
you will get a chance to fix it (or sometimes I can fix it for you).
Lastly, all warriors will be posted to the net at the end of the
tournament.  Please be sure to comment your code so it can be easily
understood.  My assembler can handle most anything you throw at it, but
I prefer that operands be separated by commas and EQUates use EQU rather
than =.  For consistent style, I prefer lowercase labels and uppercase
opcodes.  Absolute EQUate labels should be uppercase (FIVE) and you really
should not be using relative EQUates anyway, but if you do leave them
lowercase please.

Questions?  Let me know.
Mark A. Durham
MAD



Subject: Re: KotH scoring and other suggestions
From: ajpierce@med.unc.edu (Andrew Pierce)
Organization: UNC-CH School of Medicine
Date: 30 Jan 92 00:30:35 GMT
Message-ID: <1992Jan30.003035.26093@samba.oit.unc.edu>

In article <OKES.92Jan29134012@solb1.essex.ac.uk> okes@solb1.essex.ac.uk (Oke S) writes:
>In article <1992Jan29.000416.29815@midway.uchicago.edu> kwhyte@math.uchicago.edu (Kevin Whyte) writes:
>>    What do people think of automatically archiving the code of hill
>>   programs once they have sufficient longevity (maybe @soda).  Do any
>I do not think this is such a great idea. People will write code just to 
>beat the current programs on the hill.

   People are already doing this, except that they are doing it blindly.
Those who guess incorrectly simply don't make it on to the hill.  My
current program on the hill is Scanner1.01.  I know for certain that it
will perform well against certain types of programs and perform
poorly against other specific type programs.  This is reflected in the
volatility of its rating.  I has ranged from 1st to 7th, to 2nd and now is
back to 7th or so again.  This is true for other programs too (possibly to
a lesser extent):  type A will beat type B but lose to C, type B will beat
C but lose to A, type C will beat A but lose to B etc. (I fully suspect
that the "who-beats-who" results are NOT transitive).  
   What is the solution?  It might be a good idea to reconfigure the hill
each time.  Thus, instead of a newcomer playing every other program 40 times,
have every program play every other program 4 times (same number of total
battles) and then sort according to the winner of the round-robin
tournament.  This way at least the hill would be reflective of the
relative scores of each prog. to each other.  The way the scoring is done
now, I think the hill is merely reflective of how well each prog. does
against *the newcomer only*.
     -Andy
ajpierce@med.unc.edu



Subject: Tournament
From: nautilus@lachesis.acm.rpi.edu (John M. Twilley)
Organization: The Voice of Fate
Date: 30 Jan 92 06:10:29 GMT
Message-ID: <4g0rkm#@rpi.edu>

The last post was a success...
 
I was wondering.. .Have any of you actually run medium-scale tournaments?
Our student chapter of the ACM is thinking of running a Core War
tourney, and I was wondering if there was any net.wisdom on any possible
problems to worry about, or ideas to incorporate.  Any help would be
appreciated...
Jack.
-- 
John M. Twilley      |  A word is a set of nonwhitespace characters surrounded
nautilus@acm.rpi.edu |  by whitespace characters.  -- Anonymous



Subject: HELP!
From: conjgr@lut.ac.uk (Neil Robertson)
Organization: Loughborough University, UK.
Date: 30 Jan 92 10:41:42 GMT
Message-ID: <1992Jan30.104142.2766@lut.ac.uk>

I posted this program on here a while back hoping that someone could
tell me why it doesnt work.Noone did.

 data:	dat #6
	dat #14
start:  mov <data,<data+1
	jmn start,data
	mov data,4
	mov data+1,4 
	jmp 4 
	end start

Its supposed to copy itself just ahead of itself the jump to this new copy.
Could someone tell me whats wrong PLEASE PLEASE!!! Am i missing something
fundemental?
Heres hoping ...



Subject: Re: HELP!
From: kdmiller@m4-035-18.MIT.EDU (Kenneth D Miller)
Organization: Massachusetts Institute of Technology
Date: Thu, 30 Jan 1992 17:46:33 GMT
Message-ID: <1992Jan30.174633.11827@athena.mit.edu>

In article <1992Jan30.104142.2766@lut.ac.uk> conjgr@lut.ac.uk (Neil Robertson) writes:
>I posted this program on here a while back hoping that someone could
>tell me why it doesnt work...

You're not refreshing the "data" counters in the new program.  See, you're
copying the old, "depleted" counters into the new program, and so the new copy
doesn't work right.  Keep some "fresh" data around, or reload proper values
into the counters ('mov #6, data')

Try it...

I wrote an evil replicating program called CLONER II, so I know how to create
self-replicating programs.  Sort-of.

-- 
kdmiller@athena.mit.edu   |  Yep, it's KENNY MILLER... 



Subject: EBS tournament 14th Feb
From: fraserc@dcs.glasgow.ac.uk (Campbell Fraser)
Organization: Glasgow University Computing Science Dept.
Date: 31 Jan 92 13:35:53 GMT
Message-ID: <1992Jan31.133553.6353@dcs.glasgow.ac.uk>

THE EBS TOURNAMENT 14th February

The case for a round robin tournament.

Corewars never has and never will be transitive.
i.e. If A beats B and
        B beats C then it DOES NOT follow that A beats C.

The realistic aim in writing a corewars program isn't to write a program that
can beat every other program, but to write a program which overall will perform
better than every other program. Only a round robin tournament can accurately
find that program.

If the other proposed system "double-elimination tournament" is used them it is
quite possible for very good ( the best ) programs to be put out in the mid or
early rounds if they are unlucky in who they are drawn against.

e.g. XTC is a very effective program and will probably do very resectably if
entered and the tournament is a round robin. However there will certainly be
a number of programs capable of beating it which could put it out after the
second round if XTC is drawn against them.

Thanks for reading

Campbell

P.S. I haven't tried "double-elimination" but that's just how I see it.
-- 
---------------------------------------------------------------
 fraserc@dcs.glasgow.ac.uk |
---------------------------------------------------------------
| Mail   : Campbell Fraser, Department of Computing Science, |



Subject: Re: EBS tournament 14th Feb
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Organization: Vanderbilt University School of Engineering, Nashville, TN, USA
Date: 31 Jan 92 19:48:22 GMT
Message-ID: <1992Jan31.194822.15606@vuse.vanderbilt.edu>

In article <1992Jan31.133553.6353@dcs.glasgow.ac.uk> fraserc@dcs.glasgow.ac.uk (Campbell Fraser) writes:
>THE EBS TOURNAMENT 14th February
>
>The case for a round robin tournament.
>
>Corewars never has and never will be transitive...

So?! IMHO, just the right amount of chance does every game/competition good.
To find the "objectively best" program, we already have KotH (although a
random element is introduced here by the small competitor number).

What I also like about double-elimination is that it's interactive; you get
to see your opponent's code from the last round and modify yours in
anticipation of his next move (sort of like "Paper, Rock, Scissors" :-)).

>Campbell
>
>P.S. I haven't tried "double-elimination" but that's just how I see it.

Same here, Stefan (stst@vuse.vanderbilt.edu)



Subject: No bombers here.
From: ajpierce@med.unc.edu (Andrew Pierce)
Organization: UNC-CH School of Medicine
Date: 31 Jan 92 21:10:40 GMT
Message-ID: <1992Jan31.211040.21949@samba.oit.unc.edu>


   Hi people.  Well, I have been thinking about the KotH a bit lately and
I was wondering about what other people think about the possibilities for
subtlety on the hill.  The way it seems to me, all programs will
necessarily be of the "bomber" type variety, that is, all variations on
the sit-in-one-place and bomb the hell out of memory with whatever you
happen to like (dat, jmp, spl etc.).  The potential of being put up against
a prog which drops spl's or jmp to a spl routine pretty much means that
all progs will have to be small, fast, and immobile.  Any larger progs
which try to get fancy dramatically increase their effective target size
and since it only takes one hit in any active prog with a spl bomb to
render the whole thing useless, these don't have a chance.  Conversely,
for the experimental hill, where the spl bomb is no more effective than a
dat bomb, it seems that all progs would be of the mice type variety,
trying to replicate themselves as quickly as possible so that they could
never be completely destroyed.
   Any opinions?  Would there be a way to get to a sort of intermediate
state somehow by reducing the power of the spl bomb and yet not reducing
it completely to that of a dat?  Of course as it stands now, the spl
bombers have the disadvantage that spl bombs do not kill, and so
additional "finish them off" code is required which increase the spl
bomber's own target size.  Some sort of compromise would be nice.
     -Andy
ajpierce@med.unc.edu



Subject: Re: No bombers here.
From: wms@iwarp.intel.com (William Shubert)
Organization: Intel iWarp, Beaverton, Oregon, USA
Date: 1 Feb 92 00:15:49 GMT
Message-ID: <1992Feb1.001549.12085@iWarp.intel.com>

While commenting on the KotH hills, Andrew Pierce (ajpierce@med.unc.edu)
wrongly assumed:
>Any larger progs
>which try to get fancy dramatically increase their effective target size
>and since it only takes one hit in any active prog with a spl bomb to
>render the whole thing useless, these don't have a chance.

   Wrong.  The #1 program on the standard hill, "Sleepless 1.2", is in fact
very long and the entire piece of code is executed frequently.

>Conversely,
>for the experimental hill, where the spl bomb is no more effective than a
>dat bomb, it seems that all progs would be of the mice type variety,
>trying to replicate themselves as quickly as possible so that they could
>never be completely destroyed.

   Wrong again.  The experimental hill is about half mice-like programs and
about half one-process-thread programs.  Leech does OK here; it's number
three right now.  Better than mice, in fact, seems to be programs which do
replicate, but do it intelligently.  Simple mice-like programs apparently end
up running too slowly to achieve much of anything and rapidly get destroyed
by vampires; although the vampires can't split the captured processes to
capture huge amounts of time, if enough processes are captured they can still
win.

   I must admit, I am impressed with both hills - I never would have expected
that some of the programs that have shown up on the standard hill would have
performed well at all, but they did.  The experimental hill has been doing OK,
but I'm not sure if the programs present there are all that much more
interesting than the standard hill.
   However, I do plan on trying out other rules variants - in particular
people seemed to want to try setting the maximum write distance.  Before I
make any changes, however, I'd like to get KotH usable for things besides a
tournament so that people can try out ideas for experimental hill before they
submit them.
				-Bill (wms@iwarp.intel.com)



Subject: Re: No bombers here.
From: ASMQK@ASUACAD.BITNET
Organization: Arizona State University
Date: 1 Feb 92 01:56:45 GMT
Message-ID: <92031.185645ASMQK@ASUACAD.BITNET>

Csapda (the first in the experimental hill) is a jmp bomber.
Path: overload.lbl.gov!agate!ames!elroy.jpl.nasa.gov!usc!wupost!darwin.sura.net!gatech!mcnc!samba!ajpierce
From: ajpierce@med.unc.edu (Andrew Pierce)
Newsgroups: rec.games.corewar
Subject: Re: No bombers here.
Message-ID: <1992Feb1.190940.18916@samba.oit.unc.edu>
Date: 1 Feb 92 19:09:40 GMT
References: <1992Jan31.211040.21949@samba.oit.unc.edu> <1992Feb1.001549.12085@iWarp.intel.com>
Sender: usenet@samba.oit.unc.edu
Organization: UNC-CH School of Medicine
Lines: 21
Nntp-Posting-Host: salvo.med.unc.edu

In article <1992Feb1.001549.12085@iWarp.intel.com> wms@iwarp.intel.com (William Shubert) writes:
>   Wrong.  The #1 program on the standard hill, "Sleepless 1.2", is in fact
>very long and the entire piece of code is executed frequently.

   Yes but how does it score against the spl bombing type programs?  It
seems to me that such a program would get massacred by say, Sargent which
specifically hunts out large programs and then bombs them with jumps to a
split routine.  (Does anyone know who wrote Sargent btw?  Nice prog.)  The
overall type of program on the hill seems to evolve in a cyclical fashion
over time (at least from looking at the strategy lines).  Are spl bombers
currently rare on the hill?  (It might be time for a resurgence.)  That is
interesting about Sleepless 1.2 though.  Maybe things aren't really as
cut-and-dried as they seem.
     -Andy
ajpierce@med.unc.edu



Subject: Re: No bombers here.
From: cedman@714-725-3177.nts.uci.edu (Carl Edman)
Date: 1 Feb 92 18:09:09 GMT
Message-ID: <298AE245.15177@orion.oac.uci.edu>

The solution to this problem is - of course :-) - to:

a) To split the CPU slice of the parent between both children
b) To permanently lose the CPU slice of a killed process

This strikes a nice balance between

a) traditional games where a single split bomb can completely take out  
your side and hence the reduction of a programs exposure to bombs is  
the overriding prerogative

and

b) games in which process time is split between the children but the  
CPU slice is redistributed upon death of a process where being hit by a  
bomb becomes completely irrelevant as it doesn't really hurt you and  
the increase in your number of processes (which makes you harder to  
kill) becomes the most important consideration

by having

c) games in which being hit by a bomb (any type) is something which you  
want to avoid (as your side permanently uses a share of processing  
power) without making such a hit the end of the game for one side or  
the other.

I suspect that even if these rules were implemented there might still  
be a tendency to split as much as possible as a single survivor can at  
least guarantee a draw. Two solutions:

a) Make draws even less valuable
b) Allow a victory not only by knock out also by points i.e. if at the  
end of the game one program retains more than 4 (8 ? 16 ?) times as  
much of its CPU slice as its opponent it will be considered a technical  
victory for that program

	Carl Edman



Subject: Re: No bombers here.
From: ajpierce@med.unc.edu (Andrew Pierce)
Organization: UNC Office of Information Technology
Date: 1 Feb 92 19:29:19 GMT
Message-ID: <1992Feb1.192919.20789@samba.oit.unc.edu>

NOTE:  I am posting this for Scott Adkins.  He mailed to me directly
instead of following up to the net.  Here is the article he meant to post:

From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins)
In article <1992Jan31.211040.21949@samba.oit.unc.edu> you write:
>
>                                                            Conversely,
>for the experimental hill, where the spl bomb is no more effective than a
>dat bomb, it seems that all progs would be of the mice type variety,
>trying to replicate themselves as quickly as possible so that they could
>never be completely destroyed.

I am not sure that I completely agree with this.  SPL bombs are still more
useful than a DAT, but much much less effective.  I think the worst kind of
program to have is the mice-type program.  The more spl's that you have in
your program (assuming that the spl's are the core of your program trying to
kill or hurt the enemy program), the less effective your program will be.  
Mice in particular will be very vulnerable to attack just because it is real
slow after a short time.  DAT and JMP bombing programs would be more effective
since they would split much less and never truly slow down as much as what 
mice-like programs would.  Good examples of this are the QUARTER mutations,
where only 4 or 6 copies of dwarf programs are spawned and that is it.  Other
programs will lose against them if they split more than what QUARTER did in
the fight.

After seeing the performance of the SPL command in the X-Koth, I have been
strongly swayed to the "AGAINST" side of changing the SPL command.  I am of
the strong opinion that you do not have to win just by slowing the enemy 
down with the SPL 0 bomb, and I think I have found some very good ways to 
protect myself against such weapons.  Over a period of time, I think anybody
can write a good program, and learn to combat the SPL bombs.

I agree with Andy, that if the SPL bomb is going to be changed, it should 
not be reduced to the power of a simple DAT statement.  That, to me, would
destroy the very essence of Core War programming that I have enjoyed for 
so long... 

Scott Adkins
sadkins@bigbird.cs.ohiou.edu



Subject: Crobots Tournament
From: <JJJ101@psuvm.psu.edu>
Organization: PSU
Date: Saturday, 1 Feb 1992 11:51:35 EST
Message-ID: <92032.115135JJJ101@psuvm.psu.edu>

Here are the 10 entries in the tournament. It will be round robin,
with each unique foursome fighting 20 times. I will probably run
4 rounds, with each round consisting of 5 fights per foursome. I
will post each round's score.

James

Below are the contestants:

//Steve Patrick
//steve@bradley.edu
//Cruiser
//cruiser.r

//Gary Haussmann
//haussman@ucsu.colorado.edu
//Fred 1.0
//fred.r

//J. Pekkanen
//k39645n@saha.hut.fi
//HeatSeeker 1.8
//heatseek.r

//Eugene Hu
//eugene@locus.com
//Hitnrun
//hitnrun.r

//Ray Cromwell
//rjc@gnu.ai.mit.edu
//Marksman V2
//marksman.r

//Chris Beauregard & Royce Vaughn Fay
//cpbeaure@descartes.waterloo.edu
//Seeker v1
//SEEKER.R

//James Jesensky
//jjj101@psuvm.psu.edu
//Stush Version 1.0
//stush-1.r

//Ray Cromwell
//rjc@gnu.ai.mit.edu
//Ambush
//ambush.r

//David Richter
//darichte@rnd.stern.nyu.edu
//Trial 4
//trial4.r

//Greg Bailey
//trmarks@uokmax.ecn.uoknor.edu
//RUNGUN
//rungun.r



Subject: Crobots Tourny: ROUND 1 RESULTS
From: <JJJ101@psuvm.psu.edu>
Organization: PSU
Date: Saturday, 1 Feb 1992 14:58:02 EST
Message-ID: <92032.145802JJJ101@psuvm.psu.edu>

Here is the results atfer Round 1. There are still 3 rounds left to
be played. (The final score is the sum of round 1, round 2, round 3,
and round 4. All 4 rounds are identical.)

To obtain the HUGE output file from round 1, mail to jesensky@endor.cs.psu.edu


              Current Score After One (1) Round of Play

Author(s)                            Program               Score
---------                            -------               -----
Chris Beauregard & Royce Vaughn Fay  Seeker v1             1104
James Jesensky                       Stush Version 1.0      756
Eugene Hu                            Hitnrun                717
Steve Patrick                        Cruiser                261
Greg Bailey                          RUNGUN                 222
J. Pekkanen                          HeatSeeker 1.8          39
Ray Cromwell                         Marksman V2             27
David Richter                        Trial 4                  9
Ray Cromwell                         Ambush                   6
Gary Haussmann                       Fred 1.0                 6

*END*



Subject: Re: No bombers here.
From: pausv@sssab.se (Paul Svensson)
Organization: Scandinavian System Support AB
Date: 2 Feb 92 15:42:55 GMT
Message-ID: <1992Feb2.154255.12368@herkules.sssab.se>

>Wrong.  The #1 program on the standard hill, "Sleepless 1.2", is in fact
>very long and the entire piece of code is executed frequently.

>Yes but how does it score against the spl bombing type programs?...

>In a recent post on r.g.cw, Bill Shubert mentions your program as being
>large, yet successful. Would you enlighten us readers of r.g.cw by
>posting the source for Sleepless 1.2, so we all regain faith in ICWS'88?

============================================================================
Well...
I'll give y'all a little more time to knock Sleepless 1.2 off the hill
before posting the source (and sending in 1.3).
A little more information to help you along:

It is a variation of "sit in one place and bomb the hell out of memory".
It's BIG, FAST, and STUPID,
and does not really refute the fact that fancy programs tend to not do well.
It does not copy any code anywhere.
It does not look at the core, it just bombs DAT.
It does not stop bombing when it's reached around to itself.
It's two strengths are:
	It's FAST (bombs more than 1/2 of the core at light speed).
	It's NOT rendered useless after a single hit by a SPL bomb.
As the name suggests,
it was concocted one night when usenet was boring and IRC slow.
Not having anywhere other than the hill to run my redcode,
I haven't analyzed it very well.
It's not very different from 1.0 and 1.1,
but the first two were not even close to getting on the hill.
Don't ask me why.

This is how Sleepless 1.2 does against itself:
The number of ties seems large for a program so singlemindedly offensive,
I can't really explain that...

>Program "Sleepless 1.2" (length 100) by "Paul Svensson <paul@sssab.se>"
>(contact address "Odysseus.SSSab.SE!pausv@sssab.se"):
>;strategy 1.0: bomb core and eat cycles
>;strategy 1.1: diversified
>;strategy 1.2: more bomb, less jumping around
>Sleepless 1.2 wins: 13
>Ties: 14

And this is how it does agains everyone else;
I've sorted it so that the ones doing best against Sleepless 1.2 come first.
The break even point is at SmallDat D,
the three before it beats it,
while all below that point more or less loose.
SplitBomb is the only one who can be said to "massacre" it.
It hasn't fought Sargent,
but if Kevin could send it in again,
we'll see...

>Program "SplitBomb" (length 12) by "Scott Adkins"
>(contact address "sadkins@bigbird.cs.ohiou.edu"):
>;strategy Slows the opponent down, and then unleashes a single deadly dwarf
>;strategy to finish the job nicely.  Uses "spl -1" similar to XTC, but in a
>;strategy more efficient way, and much, much faster.  Does well against many
>;strategy splitters and bombers, but does poorly against mice and leech.
>Sleepless 1.2 wins: 3
>SplitBomb wins: 37
>Ties: 0

>Program "Snow White and the Seven Dwarfs 1.2" (length 100) by "Paul Svensson <paul@sssab.se>"
>(contact address "Odysseus.SSSab.SE!pausv@sssab.se"):
>;strategy 1.0: 7 dwarfs, one target
>;strategy 1.1: bigger dwarfs, and some imps too
>;strategy 1.2: sacrifice thoroughness to gain speed
>Sleepless 1.2 wins: 10
>Snow White and the Seven Dwarfs 1.2 wins: 17
>Ties: 13

>Program "CAKE B" (length 90) by "S. Halvorsen"
>(contact address "snh@flipper.pvv.unit.no"):
>;Strategy		Cripple And Kill (the) Enemy.
>;Strategy
>;Strategy	This program drops a lot of JMP 0 bombs, and when
>;Strategy	the enemy execute it, he gets stuck.
>;Strategy	After he is stuck, I have all the time i need to
>;Strategy	kill him off.
>;Strategy
>;Strategy	Version B is better against scanners.
>;Strategy	(Only a few B-fields are non-zero.)
>Sleepless 1.2 wins: 15
>CAKE B wins: 21
>Ties: 4

>Program "SmallDat D" (length 100) by "Tor Egge"
>(contact address "tegge@pvv.unit.no"):
>;strategy	Use SPL/JMP to hit mod 4 and mod 5 hiders.
>Sleepless 1.2 wins: 20
>SmallDat D wins: 20
>Ties: 0

>Program "Leech 1.2" (length 47) by "William Shubert"
>(contact address "wms"):
>;strategy Throw around "jmp" instructions.  When the enemy executes one of
>;strategy   these instructions, they jump to a piece of code that forces them
>;strategy   to fork of tons more processes and clear the core.  The last bit
>;strategy   of core a captured process clears will be itself, dying and giving
>;strategy   the Leech the win.
>;strategy 1.2 mod: Move the trap routine far away from my code to make it
>;strategy   harder for leech-killer to find me.
>;strategy For a full listing, just send a letter to wms@iwarp.intel.com
>Sleepless 1.2 wins: 25
>Leech 1.2 wins: 15
>Ties: 0

>Program "TheRat" (length 10) by "William Shubert (& Arne H. Juul)"
>(contact address "arnej@lise.unit.no"):
>;strategy Bomb mod-4 locations with JMPs leading to a splitting &
>;strategy bombing routine, hopefully making the enemy do the work.
>;strategy Modified from wms' Leech 1.1, with a false clue to survive
>;strategy my own antileech routine. Note the small size, I've worked
>;strategy on it!
>Sleepless 1.2 wins: 29
>TheRat wins: 10
>Ties: 1

>Program "Trinity Zwo" (length 7) by "Stefan Strack"
>(contact address "stst@vuse.vanderbilt.edu"):
>;strategy     1) Decrements B-operands at large intervals
>;strategy     2) Cleans up debris with imp
>;strategy     3) Finishes off with mod-2 bomber/imp-stomper
>;strategy (Version 2.0: smaller, should tie less)
>;strategy Submitted: Fri Jan 31 18:58:33 CST 1992
>Sleepless 1.2 wins: 27
>Trinity Zwo wins: 6
>Ties: 7

>Program "Walze" (length 98) by "Stefan Strack"
>(contact address "stst@vuse.vanderbilt.edu"):
>;strategy Submitted: Fri Jan 31 21:21:41 CST 1992
>Sleepless 1.2 wins: 26
>Walze wins: 3
>Ties: 11

>Program "Trinity Zwo.1" (length 99) by "Stefan Strack"
>(contact address "stst@vuse.vanderbilt.edu"):
>;strategy     1) Decrements B-operands at large intervals
>;strategy     2) Cleans up debris with imp
>;strategy     3) Finishes off with mod-2 bomber/imp-stomper
>;strategy Version 2.0: smaller, should tie less
>;strategy         2.1: moved imp away from body
>;strategy Submitted: Fri Jan 31 21:07:44 CST 1992
>Sleepless 1.2 wins: 29
>Trinity Zwo.1 wins: 4
>Ties: 7

>Program "Cake Eater" (length 26) by "Tor Egge"
>(contact address "tegge@pvv.unit.no"):
>;strategy	Bomb core with DAT.
>Sleepless 1.2 wins: 25
>Cake Eater wins: 0
>Ties: 15

>Program "MUTAGEN /PAR" (length 4) by "Stefan Strack"
>(contact address "stst@vuse.vanderbilt.edu"):
>;strategy laces the core with crippling point-mutations and cleans up
>;strategy the debris with systematic deletions (parallel version)
>;strategy Submitted: Wed Jan 29 21:24:38 CST 1992
>Sleepless 1.2 wins: 35
>MUTAGEN /PAR wins: 5
>Ties: 0

>Program "Scanner 1.01" (length 98) by "Andy Pierce"
>(contact address "ajpierce@med.unc.edu"):
>;strategy Quickly kill the core.
>;strategy (minor optimization)
>Sleepless 1.2 wins: 33
>Scanner 1.01 wins: 2
>Ties: 5

>Program "Midget 1.4" (length 5) by "Paul Svensson <paul@sssab.se>"
>(contact address "Odysseus.SSSab.SE!pausv@sssab.se"):
>;strategy 1.0 stealthy prng dwarf
>;strategy 1.1 better prime
>;strategy 1.2 imp proofed
>;strategy 1.3 bug fix
>;strategy 1.4 bug fix
>Sleepless 1.2 wins: 31
>Midget 1.4 wins: 0
>Ties: 9
-- 
Paul Svensson   _   /|   - Every absurdity needs a champion to defend it -
SM5SJS          \'o.0'   Scandinavian System Support    Fax: +46 13 115193
paul@sssab.se   =(___)=  Box 535        _             Phone: +46 13 111660
sunic!sssab!paul   U     SE-581 06  Linkoping, Sweden  Home: +46 13 121021
