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
|
