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 > The '94 Warrior > Issue #8

June 6, 1994                                                          Issue #8
______________________________________________________________________________

This newletter covers the current status of the ICWS '94 Draft hills,
and also attempts to keep up with the latest ideas in how the new standard
will affect corewars in general.  I hope you enjoy it!

If you are unfamiliar with the '94 draft standard, you can learn more about
it by reading the FAQ for this newsgroup.  In addition, the program pMARS
includes a highly recommended tutorial on the new standard.  Feel free
to send me e-mail if you have any difficulty finding either of them, if you
need to have a corewar item mailed to you, or if you have any other questions.

The FAQ is available through anonymous FTP to rtfm.mit.edu, as
/pub/usenet/news.answers/games/corewar-faq.Z
______________________________________________________________________________

CHANGES and CORRECTIONS:

The latest tournament is over, and Jay Han walked away the winner.
Congratulations to Jay on his impressive achievement, and thanks again to
Stefan Strack again for running it.

Jay Han also appears to have won another on-going battle.  His "corestep"
program has left the two competing "optima" programs in the dust.  You can get
the source code for it, or Stefan Strack's varying step version "mopt", by 
anonymous FTP to soda.berkeley.edu.

The pMARS team has been busy as well.  The next release will allow the use of
a-field indirect addressing, and will introduce the ability to use ";assert"
to confirm that your program is running in a core type that it was written
for.  Be sure to download a copy when it is released.

The newsgroup has also had some interesting discussion and results on working
with genetic algorithms to create redcode warriors.  (Using "genetic" methods
to guide the development of "random" programs.)  Watch the newsgroup for
further details.
______________________________________________________________________________

The ICWS '94 Draft Hill:

       Core size:	8000 instrucitons
   Max processes:	8000 per program
        Duration:	After 80,000 cycles, a tie is declared.
Max entry length:	100 instructions

The current ICWS '94 Draft hill on "Pizza":
 #  %W/ %L/ %T                      Name               Author   Score     Age
 1  49/ 34/ 17              Pyramid v5.5     Michael Constant     163      54
 2  48/ 33/ 19              Keystone t33              P.Kline     162      76
 3  40/ 29/ 30                  Torch t3              P.Kline     151      15
 4  43/ 43/ 15             Iron Gate 1.5       Wayne Sheppard     143     253
 5  32/ 21/ 47               B-Panama IX       Steven Morrell     142       4
 6  38/ 35/ 27               Stimpy v2.0     Brant D. Thomsen     142       5
 7  30/ 18/ 52                 Blue Funk       Steven Morrell     142     276
 8  31/ 22/ 47                 Cannonade              P.Kline     140     134
 9  32/ 24/ 44                     NC 94       Wayne Sheppard     140     289
10  41/ 43/ 16                   Aleph 0              Jay Han     140      50
11  43/ 47/ 10                  Rave 4.1        Stefan Strack     139     241
12  38/ 38/ 24               Christopher       Steven Morrell     139     197
13  38/ 39/ 23              Request v2.0     Brant D. Thomsen     138     307
14  40/ 44/ 16              Dragon Spear             c w blue     136     309
15  31/ 28/ 41                   Lucky 3        Stefan Strack     134     269
16  29/ 25/ 46                       TCh         Mintardjo W.     134       6
17  30/ 28/ 42                      Aeka                T.Hsu     132       2
18  31/ 31/ 38 Der Zweite Blitzkrieg - 9      Mike Nonemacher     132     259
19  33/ 36/ 31                   mmfP v2           Karl Lewin     131       7
20   5/  0/  0              Pyramid v5.5     Michael Constant      14       1

The above ordering seems to be a good representation of what has been
happening on the hill for the last couple of weeks.  Michael Constant's
"Pyramid" and Paul Kline's "Keystone" have both been fighting for the top
position, with "Torch" being the only close competitor.  Both "Pyramid" and
"Keystone" are excellent examples of complex programs that push the 100 line
limit, although they are radically different from each other.

Also dramatic are the drop of Mike Nonemacher's "Der Zweite Blitzkrieg" and
Michael Constant's "Sauron" (right off the hill), as both were putting up a
good fight for the top position only a month ago.  Although the hill is fairly
old, the new programs seem to be making a big difference.

The current ICWS '94 Draft hill on "Stormking":
 #  %W/ %L/ %T                      Name               Author   Score     Age
 1  45/ 29/ 26               Sauron v3.6     Michael Constant     160       1
 2  41/ 27/ 32           Killer instinct         Anders Ivner     155      24
 3  36/ 21/ 43         Twimpede+/8000-d1              Jay Han     150      14
 4  44/ 38/ 17               Ntttgtstitd         Simon Hovell     150      25
 5  43/ 38/ 19              Request v2.0     Brant D. Thomsen     148      17
 6  34/ 21/ 44                   Lucky 3        Stefan Strack     147      12
 7  35/ 23/ 42                     NC II       Wayne Sheppard     147      79
 8  35/ 25/ 40               Sphinx v5.1         W. Mintardjo     145      82
 9  43/ 41/ 17            Sylvester v1.0     Brant D. Thomsen     144      61
10  29/ 19/ 53                      ttti        nandor sieben     139      35
11  32/ 26/ 42        JustTakingALookSee            J.Layland     138      78
12  31/ 24/ 45                     Snake       Wayne Sheppard     138      34
13  43/ 47/ 10                  Rave 4.1        Stefan Strack     138       7
14  39/ 40/ 21                      tiny            J.Layland     138      59
15  29/ 20/ 51                    ttti94        nandor sieben     137      30
16  39/ 42/ 19       Beholder's Eye v1.7         W. Mintardjo     137      91
17  38/ 42/ 19               Christopher       Steven Morrell     135      23
18  39/ 43/ 18                      SJ-4            J.Layland     134      28
19  37/ 43/ 20            Fast Food v2.1     Brant D. Thomsen     131      37
20  35/ 40/ 26                    pepper              P.Kline     129       6
______________________________________________________________________________

The ICWS '94 Draft Experimental Hill:

       Core size:	55,440 instructions
   Max processes:	10,000 per program
        Duration:	After 500,000 cycles, a tie is declared.
Max entry length:	200 instructions

The current ICWS '94 Experimental (Big) hill on "Pizza":
 #  %W/ %L/ %T                      Name               Author   Score     Age
 1  49/ 32/ 19              Pyramid v5.3     Michael Constant     166      38
 2  49/ 32/ 19                  ivscan6b            J.Layland     165      11
 3  37/ 17/ 46                   Aleph 1              Jay Han     158       9
 4  46/ 34/ 20             Request-55440     Brant D. Thomsen     157     147
 5  44/ 36/ 20                 Aleph 0/1              Jay Han     153       3
 6  42/ 37/ 21                Vanity IIx        Stefan Strack     147     102
 7  35/ 24/ 41             Variation G-1              Jay Han     146     111
 8  41/ 36/ 24               Stimpy v2.0     Brant D. Thomsen     146       2
 9  44/ 45/ 11                    Squint      Mike Nonemacher     143      85
10  40/ 39/ 20                   Aleph 0              Jay Han     142      10
11  44/ 47/  9                 Rave B4.1        Stefan Strack     140     108
12  31/ 24/ 44 Der Zweite Blitzkrieg - 9      Mike Nonemacher     139     109
13  32/ 26/ 42                  Splash 1              Jay Han     137     112
14  30/ 24/ 47              NotSoBigImps        James Layland     136       7
15  36/ 38/ 26                      Lump            J.Layland     135      92
16  31/ 29/ 40                  Lucky 13        Stefan Strack     133     153
17  40/ 49/ 11                 Plasma v5       Wayne Sheppard     132      49
18  28/ 25/ 47                 Blue Funk       Steven Morrell     131       1
19  27/ 30/ 43       Tail of the Twister      Mike Nonemacher     124      57
20  25/ 33/ 43                      avp2            J.Layland     117       5

On this hill, just as on the standard hill, Michael Constant's quick-scanning
vampire "Pyramid" is a string first-place contender.  However, unlike last
month, there is a program that is giving him some close competition:
"ivscan6b", an updated version of James Layland's notable tournament entry.

Jay Han's "Aleph" series, and Brant Thomsen's "Stimpy" are a couple of other
new programs that seem to have taken a liking to the Big hill.  Perhaps
scanners will be the programs that dominate this hill in the future.

The current ICWS '94 Experimental (Big) hill on "Stormking":
 #  %W/ %L/ %T                      Name               Author   Score     Age
 1  48/ 12/ 40             Variation M-1              Jay Han     184       2
 2  46/ 30/ 24             Request-55440     Brant D. Thomsen     162      54
 3  40/ 20/ 40                  Lucky 13        Stefan Strack     161      20
 4  46/ 36/ 18                    Raiden Richard van der Brug     157       3
 5  45/ 35/ 19                Vanity IIx        Stefan Strack     155       8
 6  35/ 18/ 47              Bakers Dozen       Wayne Sheppard     153      13
 7  40/ 30/ 31               Sauron v2.4     Michael Constant     150       5
 8  30/ 15/ 55         Imperfection v2.3     Michael Constant     146      48
 9  36/ 31/ 33             Variation D-1              Jay Han     142      15
10  44/ 47/ 10                 Rave B4.1        Stefan Strack     141       9
11  42/ 46/ 12                  bigproba        nandor sieben     138      12
12  41/ 46/ 14               Dagger v7.0     Michael Constant     136      14
13  40/ 48/ 11                 The Count              Jay Han     132      44
14  27/ 23/ 50                    BigImp        Alex MacAulay     132      95
15  30/ 29/ 41         jmpWetPaper-94x-a      J.M.Pohjalainen     131       1
16  26/ 23/ 51                   BigImps        James Layland     129     114
17  31/ 35/ 34                Veeble Jr.         T. H. Davies     126      16
18  28/ 37/ 34               Industrious        Stefan Strack     119       4
19  29/ 40/ 31                 Open Arms        Stefan Strack     117       7
20  29/ 41/ 30                      Test        Stefan Strack     116       6
______________________________________________________________________________

HINTS and HELPS:


One of the problems that has been haunting corewar programmers through the
years is the differences in behavior caused by in-register and in-memory 
evaluation of an instruction.  Actually, it's usually not the evaluation
itself that is the problem -- instead, it is the fact that few corewar
programmers know what the difference is between them, or how these differences
affect the behavior of programs.  I'd like to help clarify this difference,
and give some pointers to help you predict what your code will do under each
type.

If you think about it, you can probably guess exactly what "in-memory" and
"in-register" are referring to.  With in-memory evaluation, changes to the
core are made directly to the memory storing the core.  In-register
evaluation, on the other hand, copies the current instruction and the
instructions it points to into registers, and the information in the registers
is then used to update the core.

There are advantages to both types of evaluation.  In-memory evaluation is
much more intuitive.  In other words, it is the way that beginners expect
redcode programs to operate.  In-register evaluation's primary advantage is
that it is faster.  Most of the '88 compliant corewar emulators, including the
one used for the original KotH hill, are in-register.

For those of you that are curious, the '94 draft standard explicitly states
that in-register evaluation should be used.  In fact, much of the reason a new
standard is needed is make this clarification.  Although most code will
function exactly the same under either type of evaluation, there are a growing
number of programs where in-register/in-memory conflicts are a very important
consideration.

One of these programs is Paul Kline's "Torch".  For those of you who missed
it, here is a copy of the source code:

;redcode-94 quiet
;name Torch
;author P.Kline
;strategy very rapid incendiary bombing, core-clear & gate
;macro

step     equ 73
count    equ 1500

gate     dat   <-step+1,<-step
     for 21
	 dat   0,0
     rof
sp       spl   #0,<-step             ; spl half of the incendiary
in       add   #step+step,msm        ; |
msm      mov   sm,>tgt-(step*count)  ; | these 3 execute in reverse order!
msp      mov   sp,@msm               ; |
tgt      djn.f in,>3157              ; gets bombed with spl to start clear
clr      mov   gate,<-13
cp       djn.f clr,>3                ; forward decrement while clearing
     for 32
         dat   0,0
     rof
sm       mov   @0,>step              ; mov half of the incendiary
	 end   sp


This program has a bomb that looks like this:

    sm  mov  sp, >sp
    ...
    sp  spl  #0, <sm+1


As processes execute the MOV statement, they copy the SPL instruction
progressively through the core, starting with the location immediately
following the MOV.  Thus, the more processes there are that execute the MOV
statement, the longer the line of SPL instructions (the carpet) will be.

If this bomb were executed using in-memory evaluation, then the length of the
SPL carpet would always be equivalent to the number of times the MOV
instruction were executed.  However, with in-register evaluation, something
interesting happens when the MOV instruction tries to overwrite the SPL
instruction it uses as a pointer.  Because of the way the values are stored
in the registers, the increment is lost when the SPL instruction is copied
over itself.  Thus, the SPL instruction's B-field stays at 0 and the
carpet never progresses beyond it -- very effectively reducing the threat
of having the enemy capture your own code with the carpet it made after being
bombed.

You get a very similar effect with the DJN.F instruction at "cp".  If the
instruction 3 locations beyond it has a B-value of 0, the DJN stream never
progresses beyond that instruction.  However, unlike the bomb mentioned
earlier, I believe this is the same behavior you would achieve if using an
evaluator with _true_ in-memory evaluation.  (On Stefan Strack's CoreWar Pro,
you get a different interesting effect instead.  The "post-increment" is
performed _before_ the DJN, causing the DJN to bring it back to 0 and drop out
of the loop.)  If nothing else, ambiguities such as this one are very
effective at pointing out the advantages of including actual code for a
corewar emulator in the '94 standard -- it allows us to determine exactly what
a piece of code should behave like.  (I found lines 511-561 and lines 750-1416
[section 5.6] of the February 2 draft of the standard to be very helpful when
working on this issue's hint.  I'd recommend going over them if you would like
to know more about exactly how instructions are evaluated.)

When I first started on this issue's hint, I had hoped to be able to come up
with an exact list of the instructions that differ between in-memory and in-
register evaluation.  As I studied it closer, I have come to understand what a
difficult task that would be.  So, instead, I will simply share the rule
of thumb that I have been using.  If anyone else out there has some additional
advice or cases where they found a program to work differently under in-
register than in-memory evaluation, please pass them along.

Based on my own experience, my advice is to be extra cautious whenever you use
the MOV instruction.  In-register differences will only appear when the issue
of self-reference is involved; this can consist of moving an instruction onto
the instruction doing the moving, or moving an instruction onto the
instruction holding the indirect pointer for your movement.  Although
potential problems exist for other instructions as well, I have never
experienced any of them -- nor can I recall anyone else that ever has.

If you have an instruction that may reference itself, either directly or
indirectly, be prepared to have to work around the problem or even scrap the
program altogether; or, if you can, exploit it to come up with an even better
warrior!  

[Thanks again to Paul Kline for allowing me the use of his code.]
______________________________________________________________________________

Looking to the Future:

There have been several modifications to the pMARS instruction set over the
last couple of months, and there look to be more in the immediate future.
Once again, I strongly encourage everyone out there to experiment with these
modifications and let us know what you think of them.  It will be too late
after the '94 standard is approved!

If you have any comments or questions about the '94 hills or the '94 draft
standard that you think might be of general interest, please let me know.
Also, if there are any particular topics you would like to see covered in
future editions of _The_'94_Warrior_, please send me e-mail on that as well.

Good luck, and happy computing!
______________________________________________________________________________

Brant D. Thomsen, Editor	   Snail mail:	1197 East 6290 South
(bdthomse@peruvian.cs.utah.edu)			Salt Lake City, UT  84121
University of Utah				U.S.A.
-- 
Brant D. Thomsen                  Man will occasionally stumble over the truth,
(bdthomse@peruvian.cs.utah.edu)   but most times he will pick himself up
University of Utah                and carry on.             - Winston Churchill
2002-2005 corewar.info. Logo C. Schmidt