Sections
Home
Hills
Infinite Hills
Tournaments
Software
Evolving
Optimizer
Community
Newsletter
Discussion
History
Sections
 
For Beginners
First Steps
FAQ
Guides
Lexicon
Benchmarks
For Beginners
> Home > The Corewar Newsletters > Core Warrior > Issue #1

Issue 7                                                      November 27, 1995
______________________________________________________________________________
Core_Warrior_ is a weekly newsletter promoting the game of corewar.  Emphasis
is placed on the most active hills--currently the '94 draft hill and the 
beginner hill.  Coverage will follow where ever the action is.  If you have 
no clue what I'm talking about then check out these five-star internet locals
for more information:

FAQs are available by anonymous FTP from rtfm.mit.edu as
pub/usenet/news.answers/games/corewar-faq.Z
FTP site is: ftp.csua.berkeley.edu /pub/corewar
Web pages are at:
http://www.stormking.com/~koth                  ;Stormking
http://www.ecst.csuchico.edu/~pizza/koth        ;Pizza
http://pauillac.inria.fr/~doligez/corewar/      ;Planar
______________________________________________________________________________
Greetings.

This week there is another juicy, at least in my hopes, number of Core
warrior. The hint will cover bombers and bombs, including Paul Kline's
contribute and Torch 18 code; Robert Mcrae introduces you to quickscannes
secrets and Planar finishes the continual launch imps topic, and unveils his
new warrior Impfinity 3i.
Many thanks to them and to all contributing to the newsletter.
Last minute new: big (CORESIZE 55440) hill has been reopened at Stormking
server, address: <koth@stormking.com> ;redcode-94x 
Enjoy it and many thanks Tuc.

______________________________________________________________________________
Current Status of the Internet Pizza Server ICWS '94 Draft Hill:

 #  %W/ %L/ %T                      Name               Author   Score     Age
 1  47/ 38/ 14                      quiz              Schitzo     156      78
 2  43/ 34/ 23                 test lp 2          Beppe Bezzi     152       4
 3  38/ 25/ 37                  La Bomba          Beppe Bezzi     151      73
 4  43/ 36/ 22                  Derision           M R Bremer     150      97
 5  37/ 31/ 32                 Torch t18              P.Kline     143     457
 6  37/ 39/ 24               myVamp v3.7             Paulsson     135     425
 7  36/ 37/ 27                endpoint .           M R Bremer     134     102
 8  38/ 43/ 19             Porch Swing +         Randy Graham     134     158
 9  26/ 20/ 54 Fly Fishing w/Plastic Wor           Karl Lewin     131      55
10  38/ 45/ 17                Frontwards       Steven Morrell     131       5
11  33/ 35/ 32                       Phq    Maurizio Vittuari     131     559
12  40/ 48/ 13       Leprechaun on speed         Anders Ivner     131     253
13  33/ 35/ 32              Son & Father    Maurizio Vittuari     130     108
14  36/ 44/ 20             myZizzor v2.0             Paulsson     128       8
15  27/ 27/ 46           Jack in the box          Beppe Bezzi     128     445
16  20/ 12/ 67             Impfinity v3i               Planar     128       7
17  31/ 34/ 36              Father & Son    Maurizio Vittuari     127     107
18  33/ 41/ 25               Armory - A5            Wilkinson     126     596
19  24/ 22/ 54          juliet and paper M R Bremer, B. Bezzi     125      74
20  19/ 21/ 60                     test4          Kurt Franke     118       1

After last week revolution we had a quiet one. Very little to report: quiz
takes the head even if La Bomba is still in top positions, Morrell and
Paulsson submitted new version of their warriors pushed off last week.
Planar's new Impfinity enters the hill, you can see the code in Planar's
corner, Kline attempted a new p-spacer without success. In the bottom Armory
is shuffling a bit, but still resists junger warrior challenges. Franke, one
of beginners hill top scorers, enters the bottom of 94
______________________________________________________________________________
94 - What's New

11  39/ 43/ 19             myZizzor v2.0             Paulsson     135       1
10  23/ 13/ 64             Impfinity v3i               Planar     133       1
19  37/ 47/ 16                Frontwards       Steven Morrell     128       1
20  19/ 21/ 60                     test4          Kurt Franke     118       1
______________________________________________________________________________
94 - What's No More

21  34/ 49/ 17             Scissors v.a1    John K. Wilkinson     119      28
21  31/ 50/ 19             Scissors v.a4    John K. Wilkinson     113       4
21  20/ 17/ 63           TimeScape (1.7)       J. Pohjalainen     122      17
21  14/ 11/ 75                Evolve 6.3       John Wilkinson     118      24

The calm after the tempest, no aged warrior has been pushed off.
______________________________________________________________________________

What's old

18  33/ 41/ 25               Armory - A5            Wilkinson     126     596
11  33/ 35/ 32                       Phq    Maurizio Vittuari     131     559
 5  37/ 31/ 32                 Torch t18              P.Kline     143     457
15  27/ 27/ 46           Jack in the box          Beppe Bezzi     128     445
 6  37/ 39/ 24               myVamp v3.7             Paulsson     135     425
12  40/ 48/ 13       Leprechaun on speed         Anders Ivner     131     253

Veterans surviving last week carnage improve their scores a little. Armory
and Jack in the box are having some problems, while Torch and myVamp are
still very effective.
_____________________________________________________________________________

Current Status of the Internet Pizza Server Beginner's Hill:

 #  %W/ %L/ %T                      Name               Author   Score     Age
 1  45/ 35/ 20          Clear Sighted v1            JS Pulido     156       3
 2  45/ 38/ 18           dualstrat v.0.2         Brian Haskin     152       2
 3  36/ 22/ 41                 teamwork?          Kurt Franke     150      23
 4  44/ 39/ 17          Fire Master v1.5            JS Pulido     148       6
 5  36/ 33/ 31                Lurker 1.1          Kurt Franke     139      21
 6  33/ 29/ 38                  test L 9          Beppe Bezzi     136       4
 7  26/ 20/ 54                    Schizo            J. Doster     132      53
 8  31/ 31/ 38              Hint Test v4           M R Bremer     131      19
 9  21/ 12/ 67           Impfinity v3c11               Planar     130      65
10  21/ 21/ 58               Trapper 1.1          Kurt Franke     121       1
11  20/ 19/ 61                Paper8-III             G. Eadon     120      11
12  32/ 45/ 23                      Look            J. Doster     120      50
13  19/ 18/ 64                 Sheet 1.0            J. Doster     120      63
14  14/  9/ 77             RingWorm_v2.5           Calvin Loh     118      36
15  17/ 17/ 65             RingWorm_v2.4           Calvin Loh     118      51
16  12/  7/ 81              Impfinity v1               Planar     116      97
17  28/ 41/ 31         Good old DJN Test           Karl Lewin     115      16
18  20/ 26/ 53               Loh_tst_1.3           Calvin Loh     114      26
19  10/  9/ 81                NewerPaper          Kurt Franke     111      17
20  27/ 45/ 28        Paper Shredder 2.1          Kurt Franke     108      20

The very active beginners hill shows five new entries in the top ten
positions. Pulido, Haskin and Franke seem ready to make the jump to veterans. 
Bezzi, a new author, at least from when I'm following beginners, enters in
6th position with a warrior that was 3rd in 94 hill :-) 
The morale of the story is that:
The beginners hill level has grown in these weeks, perhaps it's higher than
ever.
All those who have a warrior doing well in -b hill have to try the -94, at
worst you'll score 90 points finding 94 hill hostile to the warrior kind you
are submitting, but with a little luck you can enter and begin making
experience.
_____________________________________________________________________________

HALL OF FAME
* means the warrior is still running.

Pos    Name                  Author          Age     Strategy
 1  Iron Gate 1.5          Wayne Sheppard    926    CMP scanner
 2  Agony II               Stefan Strack     912    CMP scanner
 3  Blue Funk              Steven Morrell    869    Stone/ imp
 4  Thermite 1.0           Robert Macrae     802    Qscan -> bomber
 5  Blue Funk 3            Steven Morrell    766    Stone/ imp
 6  HeremScimitar          A.Ivner,P.Kline   666    Bomber
 7  Armory - A5            Wilkinson         596 *  P-warrior
 8  Phq                    Maurizio Vittuari 559 *  Qscan -> replicator
 9  B-Panama X             Steven Morrell    518    Stone/ replicator
10  Torch t18              P.Kline           457 *  Bomber
11  Jack in the box        Beppe Bezzi       445 *  P-warrior
12  myVamp v3.7            Paulsson          425 *  Vampire
13  NC 94                  Wayne Sheppard    387    Stone/ imp
14  Cannonade              P.Kline           382    Stone/ imp
15  Torch t17              P.Kline           378    Bomber
16  Lucky 3                Stefan Strack     355    Stone/ imp
17  Request v2.0           Brant D. Thomsen  347    Qvamp -> vampire
18  Dragon Spear           c w blue          346    CMP scanner
19  juliet storm           M R Bremer        333    Stone/ imp
20  Frontwards             Steven Morrell    323    One shot scanner

Armory, very near 600 age now, and Phq consolidate their position in the
hall of fame; Torch enters top ten trailing Jack and myVamp, all three well
over 400 age.
Frontwards enters bottom place pushing Timescape off.
______________________________________________________________________________
The Hint

Hello folks, last week Myers introduced the bomber topic with two classic
stones, Blue Funk and juliet storm; these guys are four-five lines long, and
found their effectiveness on their small size and resilience more than on
speed, they are both at 33% c, one bomb every three cycles, and
effectiveness of their bombs, simple dat 0,0.
There is another category of more complex bombers that balance the increased
size with a greater speed and/or deadlier bombs.

Who better than Paul Kline, Torch's author, can speak of this argument.

----------

Your basic 'stone' bomber is based on this fragment:

incr     spl  #step,#-step   <- self-splitter
         add  incr,1         <- step up the pointers
         mov  <0,0           <- decrement one and bomb the other
         djn  -2,<-10        <- loop and sequential decrement
         
Steven Morrell's discussion last issue showed how to optimize this for
maximum bombing duration, but his comment about Emerald is too generous.
I never realized or designed Emerald's pattern, it was just the best
of a large number of step sizes I tried.

Anyway, the above delivers one decrement and one bomb in three cycles.
However it is possible for the opponent to immunify part of his code to
decrements, and thereby reduce this bomber to something much less
than 66% effective speed.  A search through old programs (still a gold
mine!) turns up this one by Paul Kilroy:

;name Ike v.21
;author Paul S. Kilroy
;strategy A bomber with a cool twist

bomb	   spl 0   ,jump
ptr        dat #0  ,#0
inc        add #468,b
start      jmz inc ,@b
b          mov bomb,@464
           mov bomb,@b
jump       jmp inc
           mov 10  ,<-2
           end start

Which is your basic spl-bombing b-scanner with, as he says "a cool twist".
When he finds a non-zero location he uses it as a pointer and bombs through
it, then bombs the found location.  In other words, bombing two locations
without an intermediate ADD.

I was wanting to make this a pure non-scanning bomber, which is easy enough.
But the results were not exceptional.  With this code you get a nice 50%
hard bomber:

bomber   add   #step+step,2
         mov   bomb,@1
         mov   bomb,@0
         jmp   bomber
bomb     dat   #0,step
         
Unfortunately it is a little bigger than the 4-line version and not quite
as fast, even though it delivers real bombs instead of decrements.  It
becomes a little more durable with a leading SPL which keeps single
dat-bombs from killing it.  And it still loses completely to paper.

Anders Ivner's HeremII uses similar code to drop alternating spl and
dat-bombs that are very widely spaced in core.  HeremII works somewhat
against old style paper, but is helpless against Silk.

To kill paper requires some kind of spl-bomb that slows it down enough
to give a sequential clear time to wipe the whole core.  A split-carpet
like Agony's works very well, but this bombing routine won't accomodate
one.  A spl-jmp could be delivered by alternating spl's and jmp's, with
an eventual wrap-around to match spl's to jmp's.  But single spl's and
single jmp's are not only useless against today's paper, they are
actually dangerous, since they can mutate the opponent into a whole
lot of sequential core-clear/bombers.

Enter the mov-spl ('incendiary') bomb, which is a little two-line
program that you drop on the opponent causing him to write and
execute his own spl-carpet.  The important feature of this bomb is that
the components can be well separated - hence alternating bombs.  

Here is the working part of Torch 18, which bombs extensively with
mov-spl bombs, does one core wipe with a spl, then goes into a repeating
forward core-clear with dat.  It also has a nice feature in that if
it is overrun with a djn-stream it immediately starts the forward
dat-clear process, usually killing the nasty opponent.         
         
gate     dat   0,0
     for 3
         dat   0,0
     rof
w2       dat   -7,cp-gate+3
         dat   0,0
wipe     dat   -7,cp-gate+3
sp       spl   #-1-step,-step    ; spl half of the incendiary
in       sub   #step+step,@msp
msm      mov   sm,*tgt+(step*count)-17228
msp      mov   sp,@msm           ; bomb alternately with spl & mov
tgt      jmz   in,#0             ; bombed with spl to start clear
clr      mov   @cp,>gate
cp       djn.b clr,{wipe+1
     for 2
         dat   0,0
     rof
sm       mov   step+1,>step+1    ; mov half of the incendiary

Notice that in the inner loop the instructions are reversed from the
example - instructions following a SPL execute in reverse order.

Torch is bigger than a 4-line stone and will lose most of those battles.
However, those stones are paper-bait even with supporting imps while
Torch has the punch to stay on the Hill.  The current version also
uses a decoy to foil programs like Withershins Thrice and Porch Swing.

Questions for thought:
   What is the best 1-line bomb?
   What is the best 2-line bomb?
   What is the best 3-line bomb?

Answer correctly and you could go straight to the top of the heap .. uh Hill!
  
Paul Kline
pk6811s@acad.drake.edu

----------

Let's speak a bit of bombs; what is the best possible bomb?
The answer to this question is another question: who are you shooting at?

If our enemy is a single process, long warrior like a scanner the answer is
easy, no bomb at all... yes no bomb, taking a cell from somewhere in the
core, usually a dat 0,0 and throwing it in the middle of our enemy is enough
to kill him, and we have no need to include the bomb in our code, reducing
our size. This is the approach of Blue Funk and juliet.

If our enemy is a replicator this is pointless; we have no chance to kill
all paper bodies at the rate they spread. To kill them we have to slow them
first and, at the end deliver our deadly blow at wounded enemy, yes a very
evil act :-) This can be accomplished with more complex bombs either spl 0
followed by jmp -1, as Iron gate does when it finds a target, or with the so
called incendiary, 

        mov   step,  >step    ;alternated with
        spl   0,     -step+1

when the mov is executed it take the spl, step cells away, and moves it
immediatly after the mov itself; if the mov is executed by a multiprocess
paper the effect is creating a spl carpet. Devastating indeed.

If our enemy is a coreclear, something with a very reduced footprint like:

gate    dat     -20,20
wipe    spl     #-20,20

...

split   spl     0,0
move    mov     @1,>gate
jump    djn     -1,{wipe

A dat 0,0 hit at the gate, split or jump instruction won't stop the clear
running, we need something more effective like Tornado's bomb, (I have not
invented it, it's due to Paul Kline if I'm not wrong, I just used it)

        mov     step,1  ;step away there is another one

Using this bomb we have added to our target the 'split' line and the 'gate'
line, increasing our chances to kill.

To finish bombers argument I'll introduce now Tornado, the faster pure
bomber and, BTW, one of my favourite babies. It has never had a great
success alone, its best version stayed on hill little more than 200
challenges, never climbing higher than 10th position, but proved very
effective as component of successful warrior like Jack in the box.

Tornado pushes the indirect bombing one step farther, he lays down two bombs
and uses the second one as pointer for the third reaching a speed of 60% c,
three bombs in a five instruction loop.
This is the version included as scanner/clear killer in the p-warrior Jack
in the box

step    equ     95
count   equ     533

bomber  mov     bd,     *stone
	mov     bm      @stone
stone   mov     *step+2,*(2*step)+2 

stone line is the hearth of the bomber. It can be changed slightly if we
want to use bombs with fixed a or b fields of values different from the step
What's important is that the bomb addressed by b field of stone had one of
its fields with the value step
        
	add     incr,   stone           
jump    djn.b   bomber, #count

Three bombs in a 5 instructions loop means 60% c speed, comparable with that
of a cmp scanner (66%c) and without any problem of being delayed by decoys
and bomb's color. In fact Tornado easily kills any scanner and clear

incr    spl     #3*step,#3*step        
clr     mov     -12,    }bomber+1
djmp    jmp     clr,    <bomber-5

This is not the best clear, giving no imp protection, is those with the
smallest footprint using the bombs as pointers.

...[some empty lines]

bm      mov     step,   1       ;have care that bm be overwritten by another bm
bd      dat     #step, #1

Tornado drops a dat, then a mov step cells away, then takes this mov and
drops it step cells away from it before adding and jumping.
Once finished the run there is a dat bombs 12 cells before the clr line,
this is used to clear core.
This is not the most effective all purpose version of Tornado, v1.8
alternate spl and mov and uses a multipass clear to better resist paper
attacks and a > clear to try catching imps, but is the best fit for the role
of 'scanners/clears killer' in the p-warrior.
Tweaking a litle the code Tornado can be armed with incendiary bombs too;
the incendiary version has been submitted to the hill as Firestorm, and was
included in the p-warrior Brain Wash.

I won't tell you now, without a substantial payment to my bank account :-),
what I have put in La Bomba, and how I use it; stay tuned near Christmas,
with most chances I'll make you a gift.

For next hint I'm waiting your suggestions.

______________________________________________________________________________
Tournament Time
(details at http://www.stormking.com/~koth/nsfcwt.html)
No tournament round this week, Thanksgiving break.

This is the rank after round 6:


Name                    1       2       3       4       5       6       total
							
Steven Morrell          5       10      9       13      14      10      61
P.Kline                 7.5     9       7       11      11      12      57.5
Paulsson                7.5     11      11      9       2       5       45.5
Anders Ivner            5.5     8       4       0       10      14      41.5
Beppe Bezzi             7       7       13      2       8       3       40
M R Bremer              7       4       3.6     5       7       11      37.6
Maurizio Vittuari       6.5     5       6       3       9       8       37.5
John K. Wilkinson       4       6       12      0       13      2       37
Robert Macrae           0       0       0       12      12      13      37
Karl Lewin              0       0       10      4       6       10      30
Randy Graham            0       0       8       10      4       7       29
Derek Ross              3.5     3       3.3     7       3       6       25.8
G. Eadon                1.5     2       5       6       1       4       19.5
Kurt Franke             0       0       0       8       0       0       8
Michael Constant        0       0       0       0       5       0       5
Anders Scholl           0       1       2       1       0       0       4
John Lewis              0       0       3       0       0       0       3
Calvin Loh              0       0       1       0       0       1       2

______________________________________________________________________________
Planar's Corner:

               Continuous imp-launching (final part)

Impfinity v1 is now close to dying of old age, after being published
in Core Warrior 4 and spending most of its life in the bottom half of
the beginner hill.

I was writing version 2 when I realized that binary launching is not 
the only way of launching a continuous spiral.  The JMP/ADD launch can
also be adapted.

I'll first explain JMP/ADD launching.  Old-timers may want to skip
three paragraphs.  This is a JMP/ADD launcher, taken from the FAQ:

    A   spl     1, 0
    B   spl     1, 0
    C   spl     E, 0
    D   jmp     imp, 0
    E   add.a   #step, D
    F   dat     0, 0
    imp mov.i   #0, step

This is how it works:
   [A]
   [B B]
   [C C C C]
   [D E D E D E D E]
   [imp F imp+step F imp+2*step F imp+3*step F]
   [imp+1 imp+step+1 imp+2*step+1 imp+3*step+1]

It's pretty straightforward: we interleave processes at D and E, the
processes at D jump to the spiral, and the processes at E increment
the JMP at D to make it point to the right place for each jump.

How do we convert this into a continuous launch ?  We have to
alternate ADDs and JMPs.  The easiest way to do it:

    Z   spl     0, 0
    A   add.a   #step+1, J
    J   jmp     imp-step-1, 0

Here is what it does:
                       [Z]
                     [A Z]
                   [J A Z]
               [imp J A Z]
  [imp+1 imp+step+1 J A Z]

So this code will alternate ADDs and JMPs and add one process to the
spiral at each turn.  We have to ADD step+1 because the spiral will
advance by one location before we add a process.

The above piece of code is what I call the "pump", because it pumps
processes into the spiral.

There's one little problem because the pump only adds one process per
round.  An incomplete spiral is not viable, its processes will die
within one round.  So we have to keep the spiral alive until the first
ring is completed.  There are several ways of doing this.  I've
considered launching a complete ring with one of the three classical
launchers, and synchronizing the pump to add processes at the right
place.  Finally, I've decided to use a little piece of code to prime
the pump:

    instr   mov.i   #0, step
    primer  spl     0, >1
            mov.i   instr, imp

This will unroll a carpet of imp instructions under the tail of the
spiral.  If you locate the primer at the right place in front of the
spiral, it will be overwritten by the spiral when its job is finished
(or you can arrange for your stone to kill it, or whatever).  Note
that you have to do one MOV in each turn.  A DJN loop will not work
here.

So this is it.  Six lines of code, three of them can be located away
from the three others, and they are only used for a few dozen cycles.
What is left for scanners to find is just three lines.  Pretty good,
no ?

A few ideas occured to me while I was writing this.  I'll give them as
exercises to the reader:

- There may be a way of launching several processes per round with
  something like this:

     Z   spl     Z, }J
     A   spl     1, 0
     B   spl     1, 0
     C   spl     E, 0
     J   jmp     imp, 0
     E   add.a   #step, J
     F   dat     0, 0
     imp mov.i   #0, step

  This will add 4 processes to the imp in each round, so it doesn't
  need a primer for a 3-point imp.  It launches faster but it's
  longer.

- We could incorporate the primer into the pump (build an auto-prime
  pump ?) like this:

     Z   spl     0, >P
     P   mov.i   imp, imp
     A   add.a   #step+1, J
     J   jmp     imp-step-1, 0
     imp mov.i   #0, step

  Hmm, I think I'm going to integrate something like this into a
  future version of Impfinity.

- Because in a core of size 55440 imp spirals have at least 13 points,
  launchers tend to be bigger and easier to kill.  This is not true
  for this launcher, so this technique may be more useful in the
  experimental hill.

Finally, I'll give you the latest version of Impfinity.  I've provided
a reasonable set of constants that are completely different from what
I've sent to the hill.

Impfinity v3i implements the ideas given by Magnus Paulsson in Core
Warrior 2 about how Die Hard might be working.  We now know that Die
Hard has nothing to do with Magnus' guesses, but his ideas are still
good.  I'll quote him:

>Now if you place two spirals on top of each other, and plan in which order 
>they and the rest of the code will be in the execution. In the coreclear the 
>spl processes will be like 4000 processes, spiral, 4000 processes, spiral. 
>That means the clear has to kill spiral in 4000 cycles which isn't possible 
>in a clear.

Right.  And since scanners were the real danger for Impfinity, I've
interleaved the two spirals with two self-splitting stones that eat
most of the processes (because they will be stunned anyway).  When one
of the stone is stunned, the other one keeps going at about the same
speed because it splits almost as fast as the stunned one.  In the
real world, it's more like 2000 processes, spiral, 6000 processes,
spiral. But it does give better protection against core-clears.

>So, because there is a thing called gate which kills spirals. In order to tie 
>you have to have something like 100 processes in a spiral to slow it down as 
>much that it doesn't reach the gate. Now you can't launch such a monster 
>without getting killed before the launch is complete.

Aha, but with continuous launching, you can launch a monster of any
size with a 3-line launcher that scanners (and stones) will find hard
to kill.  And because the self-splitting stones eat most of the
cycles, 60 processes in the spirals are largely enough: by the time
the stones are killed and the spirals advance at full speed, the game
is almost over.

Impfinity v3i starts with an SPL that divides the cycles in half.
Each half is doing the same thing (but with different offsets):
bootstrap the pump, primer, and stone; launch the pump and primer.
The primer will launch the stone after a (short) while.  If I start
the stone too early, the spiral is too short (it doesn't grow much,
once the stone is started).

So we have two stones and two spirals.  The spirals are exactly on top
of each other, so they help keep each other alive.

The stones are synchronized with magic01, magic02, stnof01, and
stnof02, so they won't kill each other (or themselves) until very
late, and one of them turns itself into a core-clear (one-pass,
unfortunately).  Oh, and I have a 7-point spiral, so I can use
anti-3-point bombs, but I have no idea how much good it does.

Finally, I think the stone design warrants a few words.  It is
self-splitting, changes 3 core locations in 4 cycles, throws colored
bombs, and turns itself into a suicidal core-clear if you use the
right magic constant.  And I can make it switch bombs in the middle of
the bombing run (not shown here).  Is it original ?  I don't know.

A little bit of version history:
Version 3e7, which stayed on the bottom half of the '94 hill for some
time, didn't have the twin spirals and stones, and had a slower
bootstrap.
Version 3c11 (sent to the beginner hill after it failed to enter the 
'94 hill) has a slower stone and an 11-point spiral.

I'll put them both on my Web page, along with version 3i, when this
issue of Core Warrior is posted.

;redcode-94
;name Impfinity v3i
;author Planar
;strategy boot,imp,stone,clear
;assert CORESIZE == 8000

; The constants on the lines marked with "C" are all different
; from the version on the hill.
; To synchronize the two stones, I had to do a lot of tweaking of
; magic01, magic02, stnof01, and stnof02.  Thanks to cdb, it only
; took a few hours.

istep	equ	1143
bstep01	equ	2214
bstep02	equ	3285
magic01	equ	(-2)                  ; C
magic02	equ	(-3)                  ; C
fuse	equ	13                    ; C

trash	equ	(Z-200)               ; C
impoff	equ	(Z+500)               ; C
prmof01	equ	(impoff+2*istep+20)   ; C
prmof02	equ	(impoff+5*istep+20)   ; C
pmpof01	equ	(impoff+4*istep-20)   ; C
pmpof02	equ	(impoff+1*istep-20)   ; C
stnof01	equ	(impoff+3*istep-21)   ; C
stnof02	equ	(impoff+6*istep-19)   ; C

	org	boot
Z
boot	spl	boot02

i FOR 2

boot&i	mov.i	{ppmp&i, <ppmp&i
	mov.i	{ppmp&i, <ppmp&i
	mov.i	{ppmp&i, <ppmp&i

	mov.i	{pprm&i, <pprm&i
	mov.i	{pprm&i, <pprm&i
	mov.i	{pprm&i, <pprm&i
	mov.i	{pprm&i, <pprm&i

	mov.i	{pstn&i, <pstn&i
	mov.i	{pstn&i, <pstn&i
	mov.i	{pstn&i, <pstn&i
	mov.i	{pstn&i, <pstn&i
	mov.i	{pstn&i, <pstn&i

	mov.i	>trash-15-i*2, pstn&i
	spl	@ppmp&i, >pprm&i
	mov.i	>trash-i*2, ppmp&i
	spl	@pprm&i, >trash-5-i*2
	mov.i	>trash-10-i*2, pprm&i

ppmp&i	dat	ptr&i+1, pmpof&i+ptr&i+1-pump&i
pprm&i	dat	prime&i+3, prmof&i+prime&i+3-instr&i
pstn&i	dat	jump&i+1, stnof&i+jump&i+1-bomb&i

pump&i	spl	#1, >ptr&i
	add.f	#istep+1, ptr&i
ptr&i	jmp	pump&i-pmpof&i+impoff-istep-1, {200   ; C

instr&i	mov.i	#1, istep
prime&i	spl	#instr&i-prmof&i+impoff, >23          ; C
	mov.i	instr&i, }prime&i
	jmn.b	instr&i-prmof&i+stnof&i+1, instr&i-prmof&i+impoff+fuse

bomb&i	dat	<5334, <2667
stone&i	spl	#stone&i+bstep&i+magic&i, {-1000      ; C
	mov.i	bomb&i, }stone&i
	add.f	#bstep&i-1, stone&i
jump&i	djn.f	stone&i, <-30                         ; C

ROF

FOR (MAXLENGTH-CURLINE)/3
	mov	#1, 1
	mov	#1, @1
	spl	#1, 1
ROF

FOR MAXLENGTH-CURLINE
	dat	#1, 1
ROF

	end

Unless I'm mistaken, Calvin Loh has not published his JMP/ADD
continuous launching design yet.  Does it look like the above ?

<Damien.Doligez@inria.fr>


______________________________________________________________________________
Extra Extra:
Quickscanners
by Robert Mcrae

Core_Warrior_#4 carried a description of scanners. 0.66c or 0.80c is fast, but 
they're not _quick_! Lets look at the central loop of a very basic 0.66c 
scanner and ask what baggage can be removed.


; Code loosely based on simplified Core_Warrior_#4 scanner

inc     add.f 	step, scan	; nudge scan along
scan    sne.i 	100, 112	; scan
        djn.b 	inc, #1000	; repeat 1000 times
attack  <different stuff we can do here; avoid self-bombing>
step    dat 	24, 24



The main loop takes 3 cycles to check 2 locations, hence the 0.66c figure. INC 
nudges the locations which are compared by SEQ instruction, DJN is needed to 
jump back to INC -- this looks like about as fast as we can get. But...

		Quickscanners Use INLINE CODING.

The essential instruction to the above code is the comparison SNE. If we 
"unwrap" the loop into a long list of SNEs with no ADDs (since we hard-code the 
addresses to be scanned) and no DJNs (because we are not looping) then the 
comparison speed hits 2c -- every (executed) instruction is a SNE comparing _2_ 
locations. The result might look like this:

start	sne.i	start+100, start+112
	 mov.ab  #100, target
	sne.i 	start+124, start+136
 	 mov.ab	 #124, target
     	sne.i	start+148, start+160
	 mov.ab  #148, target
	sne.i 	start+172, start+184
 	 mov.ab	 #172, target
	sne.... etc

where target is used by the attack code as a pointer to the locations which 
have failed the SNE test. These may be attacked by any method such as SPL 
carpet, incendiary etc, but before considering attacks, ask whether the above 
code gains more than it loses compared to the scanner we derived it from: 

Good
	We have scanned 8 locations in just 4 cycles (given no hits).
Bad
	The code to scan 8 locations fills 8 locations, so we are very 	
	vulnerable to bombers and scanners.
	We don't know where we've hit till the end of the inline 	
	sequence.
	A maximum-length warrior (100 instruction) can only scan 100 	
	locations, or 1.3% of core. What do we do then?

These features make Quickscans rather specialised tools. They are always 
(AFAIK) used as the _first_ stage of a composite warrior. Scanning less than 
100 locations they cannot guarantee to hit anything, so some fallback strategy 
is needed -- scanner, bomber, whatever -- to handle the warriors they miss. If 
they hit, you should win. If they miss, you've just lost a few tens of cycles.

Since they are run once through and then discarded, the vulnerability to 
bombers is ameliorated. It is a good exercise to calculate how likely a c=0.33 
bomber is to kill a Quickscanner (say) 80 words long. (No, I don't know either, 
but I'd like to :)

Quickscanners will be scanning early in the battle, certainly in the first 100 
cycles, before many bombs have been thrown or replicators sprouted. Anything 
they detect is quite likely to be the enemy warrior code or a decoy close to 
it. This means they can afford to invest a _lot_ of effort on damaging that 
area of core.

This completes the outline and philosophy of Quickscanners (didn't take long:), 
so now onto practical tips. Actually, since asking the right kind of question 
is more useful than reading a recipe, most of the work is up to you...


	Where to Scan?

You occupy 100 cells, and the enemy is at least 100 away. That gives you 7700 
to examine; why not space them evenly? Where should the end points be?


	What Order to Scan?

If you do enough scans so that the spacing between locations is less than 100, 

here is a minor gain to scanning 1st, 3rd, 5th .. n-1th before you do 2nd, 4th 
.. nth. To see why, imagine your target is 100 cells long. Once you have 
scanned the 3rd location and found it empty, you have eliminated _some_ of the 
possible positions of the enemy which would give rise to a hit in the 2nd and 
4th locations. This makes them worse bets than other locations, so leave them 
till later. (How big is the gain here? Is there any cost?)


	Are There Other Forms of QS?

Several. The most interesting makes somewhat more efficient use of space by a 
sequence:

	SNE.i 	start+150, start+250
	SEQ.i 	start+350, start+450
	MOV.ab	#150, Target
	...

Speed is still 2c, but this method packs 4 comparisons into 3 locations at the 
cost of requiring more work in decoding exactly where the hit occurred. This 
method was used in Pyramid and Thermite, which aim to win via their thorough 
QS, but Paul Klein's recently-published Die Hard used the simpler SNE/MOV 
scheme for maximum speed in decoding. He was just aiming to hit often enough to 
do damage with his brainwash, so packing density came second to decoding speed.

Randy Graham came up with a scheme intermediate between a QS and a scanner, in 
which a long block of DAT pointers were used. This scans at "only" c=1, but has 
benefits in robustness (why?) and packing.

	  SNE.i	@ListTop, *ListTop
	  DJN.f -1, -1

	  <attack here>

List    DAT	#7750, #7850
	...
ListTop DAT 	#150, #250

[BTW I should credit the rest of the article too. Most of the things I know 
about Quickscanners came from experimenting with Michael Constant's Sauron-T, 
which is in the 1993 competition archive. Pyramid, a later QS of Michael's, is 
an excellent basis for experiment because it is fully parameterised. Apologies 
for any missed names, mistakes, misrepresentations or misrecollections.]


	How Should I Attack?

Big topic, vital to any warrior so I'm going to digress.

Any attack has to pay off being deadly against being quick to deliver. Classic 
bombers go for fast delivery, but typically of a single <, DAT or SPL. Scanners 
only spend time attacking plausible targets, by ignoring blank areas, so when 
they find something they can afford to take more time and deliver bigger, 
nastier bombs -- SPL carpets, incendiaries etc.

Right at the end of the quick-to-nasty spectrum come Quickscanners. These will 
usually only find one target, but it is very high quality, meaning that there 
is a good chance that the enemy has a substantial fraction of his processes 
working near to the scanned location. We should invest substantial time 
flattening the whole area. I've seen various schemes for this. I like launching 
vampiric JMP instructions which suck enemy processes into a prepared SPL pit. 
Multiple incendiaries could do the trick, and so could SPL carpets, though this 
gets slow if you want to carpet a large area.


	How large Should the Area Be?

Well... not more than +-100 cells from the location scanned. (Why?) This 
decision interacts with the speed of the method of bombing you use. We _hope_ 
we have clobbered the opponents code before he can boot away, but we cannot 
assume it. Another salutary calculation is just how fast we have to be; big 
imps are easy meat (you should probably make that "extinct" meat) but a bomber 
can boot in 20 cycles and leave you pasting his decoy. If he has booted away, 
we can't waste too long bombing air before we fall back on our second 
strategy...

+-50 cells is probably as long as is needed, and you certainly hit diminishing 
returns if you bomb more than every 4th cell. Using a 0.33c bomber and hitting 
every 6th cell takes about 50 cycles to complete. Die Hard hit a smaller range, 
every 8th cell, with a 0.4c bomber for 20 cycles or so. The best solution here, 
as usual, is to experiment. If you can get hold of likely opponents and work 
out how quickly they boot, this will help guide the choices.


	Thermite

[Editor note: Thermite has been posted in Core warrior # 5; you can find it
at Planar's home page -
http://pauillac.inria.fr/~doligez/corewar/rc/Thermite.txt]

I hope that these notes have given sufficient background so that the choices 
made in Thermite (Core_Warrior_#5) make sense. These notes go into a little 
more detail than the in-code comments but see #5 for the source.

Most importantly, I use FOR/ROF rather than typing the addresses! Pyramid goes 
further, with adjustable parameters for number of scans etc. I use the SNE/SEQ 
form of scan to get the scan spacing down to 81 cells. When I have a hit, I 
scan through the 4 alternatives in a short loop. (Spot the weakness here; Randy 
pointed out a wasted cycle or two, but I don't remember where...) I launch an 
SPL bomb straight at my hit, before starting the main vampiric bomb run. I 
believe this reduces the chance of the enemy booting away before the bomb-run 
gets back to the original hit (but why not check?).

The occasional JMN instructions check whether a hit has been made. If it has, I 
jump direct to the bombing routine saving a few wasted scanning cycles. The 
gain is not great, because each JMN test is guaranteed to cost one cycle but 
has a relatively small chance of saving any. (For _real_ enthusiasts, what is 
the spacing of the JMNs which optimises expected speed of hits? I think there 
are more JMNs near the beginning...)

I bite at 0.33c, from about 50 after the hit to 100 before. The asymmetry arose 
because I was keen to bomb "near" the original hit quickly, but didn't mind 
spending a few extra cycles "making sure" on the far end. Does the asymmetry 
pay? What is the chance that I miss a kill by not biting +50 to +100? What is 
the (weak) reason for bombing from -81 to -100?

I use fangs which do an indirect jump via a location well away from the trap. 
This is meant to help against indirect-bombing silks, because I have only 1 
pointer to the trap which is shared by all the bites. My pit concentrates on 
splitting as fast as possible, but why not add a brainwash? Beppe pointed out 
that if you plan to use the QS with a paper, the pit should commit suicide 
eventually because the paper cannot guarantee to kill it. Perhaps use a DJN 
trail wrapping round core? Or should the pit work as a bomber?

How many points do I lose not booting?


There are lots of options to explore. It is easy to add a QS to most 
conventional warriors and the performance gain can be substantial. If you 
already have a reasonable warrior less than 70 cycles long, why not trade in 
the decoy for a QS, which will work for its living..?
______________________________________________________________________________
Questions?  Concerns?  Comments?  Complaints?  Mail them to:
Beppe Bezzi <bezzi@iol.it> or Myer R Bremer <bremermr@ecn.purdue.edu>
2002-2005 corewar.info. Logo C. Schmidt