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