Issue 80 31 January, 2002
_______________________________________________________________________________
Core Warrior is a newsletter promoting the game of corewar. Emphasis is placed
on the most active hills - currently the '94 draft hill, the beginner hill and
the '94 no-pspace hill. Coverage will follow where ever the action is. If you
haven't a clue what I'm talking about then check out these five-star Internet
locals for more information:
FAQs are available from:
http://www.koth.org/corewar-faq.html
http://homepages.paradise.net.nz/~anton/cw/corewar-faq.html
Web pages are at:
http://www.koth.org/ ;KOTH
http://www.ecst.csuchico.edu/~pizza/koth ;Pizza
http://para.inria.fr/~doligez/corewar ;Planar
http://www.ociw.edu/~birk/corewar ;C.Birk
Newbies should check the above pages for the FAQs, language specification,
guides, and tutorials. Post questions to rec.games.corewar. All new players
are infinitely welcome!
_______________________________________________________________________________
Greetings...
Far too much time has passed since the previous issue of Core Warrior, with
the Pizza hills being unavailable for the duration. However, there is good
news too. A flurry of work has taken place on Koenigstuhl, which now homes
8 infinite hills. (ICWS, 88, 94, P-Space, Open, Big, Tiny, LP).
As usual a number of top notch warriors have been posted. Recommended
reading includes the code for Moore's Fire and Ice II, and Janeczek's
Behemot.
-- John Metcalf
_______________________________________________________________________________
Current Status of the Internet Pizza Server ICWS '94 Draft Hill:
# %W / %L / %T Name Author Score Age
1 38.6/ 37.6/ 23.8 Digital Instinct Christian Schmidt 139.7 3
2 28.2/ 17.1/ 54.7 Son of Vain Oversby/Pihlaja 139.3 1
3 41.7/ 49.6/ 8.6 Razor Michal Janeczek 133.9 15
4 26.0/ 18.8/ 55.1 nPaper II Paul-V Khuong 133.2 85
5 27.2/ 23.1/ 49.7 Olivia Ben Ford 131.2 17
6 22.6/ 14.7/ 62.7 Mini Return Of The Jedimp John K W 130.4 28
7 34.6/ 39.3/ 26.1 test Paulsson 130.0 12
8 30.6/ 33.0/ 36.4 Enough is enough! John Metcalf 128.2 8
9 34.1/ 40.6/ 25.2 Combatra David Moore 127.6 40
10 34.6/ 41.8/ 23.5 Behemot Michal Janeczek 127.4 14
11 25.9/ 25.2/ 48.9 Uninvited John Metcalf 126.7 51
12 22.1/ 18.2/ 59.7 Cinammon John Metcalf 126.0 53
13 33.1/ 40.5/ 26.4 Wizard 13 John Metcalf 125.8 16
14 19.5/ 13.5/ 67.0 The PhantIMP Menance Ben Ford 125.4 18
15 22.8/ 20.3/ 56.9 KafuFFLe John Metcalf 125.2 33
16 22.3/ 19.5/ 58.2 Tie Factory Christian Schmidt 125.1 54
17 22.3/ 19.9/ 57.8 Revival Fire P.Kline 124.7 1
18 24.3/ 25.4/ 50.3 Quicksilver Michal Janeczek 123.3 33
19 26.6/ 30.0/ 43.3 Vilex Ken Espiritu 123.2 80
20 19.6/ 16.3/ 64.1 Return of the Fugitive David Moore 122.9 109
21 29.0/ 35.1/ 35.9 Keyser Soze Anton Marsden 122.9 13
22 22.0/ 21.2/ 56.8 LoN GeV Simon Wainwright 122.8 9
23 21.9/ 22.1/ 56.0 Fifth Third Ben Ford 121.7 20
24 21.6/ 21.5/ 56.9 test JKW 121.7 26
25 25.6/ 29.6/ 44.9 Velvet Fist Ayan Chakrabarti 121.6 3
26 23.3/ 26.2/ 50.5 Brigadeer M Joonas Pihlaja 120.3 24
Top 25 Averages:
27.1/ 27.0/ 46.0 127.2 29
Age since last issue: 9 ( 26 last issue, 18 the issue before )
Days since last issue: 345 ( 104 last issue, 209 the issue before )
Average age: 29 ( 26 last issue, 34 the issue before )
Average score: ??? ( 136 last issue, 138 the issue before )
Average movement: ??? ( -2.2 last issue, -6.0 the issue before )
Warriors surviving: 18 ( 10 last issue, 14 the issue before )
The top 25 warriors are represented by 14 independent authors, Metcalf with 5,
Ford and Janeczek with 3 each, Moore, Schmidt and Wilkinson each have 2. The
remaining 8 redcoders have just the one warrior each. ( 13 authors last issue,
9 the issue before )
See below for a message from Pizza regarding the Corewar hills:
_______________________________________________________________________________
Subject: A special message from the Pizza Server
Date: 21.11.01, 21:45
Hi there! We're writing you because some time in the last couple months
you wrote us, and we weren't there! The server was broken because the
sysadmins moved it from an HPUX box to a Sun box and the elves for the
longest time were not able to log in and rebuild and fix things.
For you KOTH users, the pizza hill has been moved. Unfortunately for us
and for you, We don't know where it went. May we suggest checking the
newsgroup for more info. Naturally we'll be linking to the new page
once we hear where it's located.
Thank you for your patience and support!
Sincerely,
The Internet Pizza Elves
_______________________________________________________________________________
94 - What's New (Sorted by rank and score)
# %W / %L / %T Name Author Score Age
1 41.4/ 35.7/ 23.0 Digital Instinct Christian Schmidt 147.1 0
1 28.1/ 16.9/ 54.9 Son of Vain Oversby/Pihlaja 139.4 0
6 32.5/ 32.8/ 34.8 Enough is enough! John Metcalf 132.2 1
16 24.6/ 21.5/ 53.9 LoN GeV Simon Wainwright 127.7 1
17 22.3/ 19.9/ 57.8 Revival Fire P.Kline 124.7 1
24 21.7/ 20.4/ 57.8 Return of the Stormbringe Christian Schmidt 123.0 1
24 26.8/ 30.8/ 42.4 Velvet Fist Ayan Chakrabarti 122.7 1
25 33.4/ 43.2/ 23.4 Light Sprain Dave Hillis 123.6 1
Players entering hill since last issue: 7 ( 12 last issue, 5 the issue before )
Average rank of new entries: 14 ( 10 last issue, 11 the issue before )
Two strong new entries here from Schmidt and Oversby/Pihlaja. Welcome to
Ayan, whoose Velvet Fist enters the lower reaches of the hill.
_______________________________________________________________________________
94 - What's No More (Sorted by age)
# %W / %L / %T Name Author Score Age
26 29.7/ 41.0/ 29.3 Ultima Christian Schmidt 118.4 42
26 36.7/ 51.5/ 11.9 Shapeshifter Michal Janeczek 121.8 37
26 19.4/ 20.0/ 60.6 The Dark One Christian Schmidt 118.9 31
26 23.3/ 26.2/ 50.5 Brigadeer M Joonas Pihlaja 120.3 24
26 19.9/ 21.0/ 59.1 Return of the Stormbringe Christian Schmidt 118.8 6
26 28.9/ 38.4/ 32.8 Carme Zul Nadzri 119.3 3
26 26.4/ 35.9/ 37.7 Recount P.Kline 116.8 3
26 32.8/ 44.0/ 23.2 Light Sprain Dave Hillis 121.7 2
_______________________________________________________________________________
94 - What's Old
# %W / %L / %T Name Author Score Age
20 19.6/ 16.3/ 64.1 Return of the Fugitive David Moore 122.9 109
4 26.0/ 18.8/ 55.1 nPaper II Paul-V Khuong 133.2 85
19 26.6/ 30.0/ 43.3 Vilex Ken Espiritu 123.2 80
16 22.3/ 19.5/ 58.2 Tie Factory Christian Schmidt 125.1 54
12 22.1/ 18.2/ 59.7 Cinammon John Metcalf 126.0 53
11 25.9/ 25.2/ 48.9 Uninvited John Metcalf 126.7 51
9 34.1/ 40.6/ 25.2 Combatra David Moore 127.6 40
_______________________________________________________________________________
The Revised Hall of Fame: * indicates the warrior is still active.
Pos Name Author Age Strategy
1 Recycled Bits David Moore 164 P-warrior
2 The Stormbringer Christian Schmidt 142 Q^2 -> Stone/imp
3 Return of the Fugitive David Moore 109 * Q^4 -> Paper/imp
4 Self-Modifying Code Ben Ford 108 P-warrior
5 death by redcode Simon Wainwright 91 Q^2 -> Bomber
6 nPaper II Paul-V Khuong 85 * MiniQ^3 -> Paper
7 Vilex Ken Espiritu 80 * P-warrior
8 Stonewashed Christian Schmidt 78 Q^3 -> Paper/stone
9 Jade Ben Ford 75 Q^4 -> Stone/imp
10 Stranger John Metcalf 73 Q^3 -> Bomber
11 EvoP 3 Ken Espiritu 71 Q^3 -> Paper/imp
12 The Fugitive David Moore 70 MiniQ^2 -> Paper/imp
13 One Step Beyond John Metcalf 67 MiniQ^3 -> Stone/imp
14 Snowman John Metcalf 64 P-warrior
15 Draken Fire Ben Ford 63 Q^3 -> Bomber
16 Trefoil the original Steve Gunnell 56 P-warrior
17 Tie Factory Christian Schmidt 54 * Q^3 -> Paper
= Fixed Ken Espiritu 54 Qscan -> Paper
19 Cinammon John Metcalf 53 * MiniQ^3 -> Paper/imp/wimp
20 Pattel's Virus Ben Ford 52 P-warrior
= Exor Ken Espiritu 52 Q^3 -> Paper
21 Uninvited John Metcalf 51 * MiniQ^3 -> Stone/imp
= The Outsider Simon Wainwright 51 QScan -> Stone/imp
= Galatea Ben Ford 51 Q^2 -> P-warrior
24 Icen Ben Ford 50 Q^3 -> Paper
= Silver Talon 1.2 Edgar 50 Scanner
26 No More Innocuous Leonardo Liporati 49 Q^4 -> Paper
= trefoil 23 226 Steve Gunnell 49 P-warrior
= Puddleglum John Metcalf 49 Q^3 -> Paper/stone
29 Circle of Fire John Metcalf 48 P-warrior
= Shadow Christian Schmidt 45 Q^2 -> Paper/stone
31 Twin Christian Schmidt 44 P-warrior
= Origami Harquebus mjp 44 P-warrior
33 Stylized Euphoria Ken Espiritu 43 Q^4 -> Paper/imp
34 Slippery Eels Ben Ford 42 Q^3 -> Paper
= Even Less Innocuous TeamQ3 42 Q^3 -> Paper
= Spooky Wench John Metcalf 42 Q^3 -> Stone/imp
= Ultima Christian Schmidt 42 P-warrior
38 myBlur2 Paulsson 41 Scanner
= WingShot Ben Ford 41 Oneshot
40 Combatra David Moore 40 * Boot-distance calculator
= Digitalis 5 Christian Schmidt 40 Q^3 -> Clear/imp
= Alive and K(qu)icking Leonardo Liporati 40 MiniQ^3 -> Paper
= Freight Train v0.2 David Moore 40 '88 Q^2 -> Stone/imp
44 Shapeshifter Michael Janeczek 37 P-Warrior
45 Vain Ian Oversby 36 Q^2 -> Stone/imp
= Jaguar Christian Schmidt 36 Q^3 -> Stone/imp
47 Wintermute John Metcalf 35 MiniQ^3 -> Stone/imp
48 Qshot Christian Schmidt 34 Q^2 -> Oneshot
49 Quicksilver Michael Janeczek 33 * Q^4 -> Stone/imp
= KafuFFLe John Metcalf 33 * MiniQ^3 -> Paper/stone
= SnooPy P.Kline 33 P-warrior
= chained to the system Simon Wainwright 33 *Unknown*
Not much change here since last issue.
_______________________________________________________________________________
Current Status of the Internet Pizza Server Beginner Hill:
# %W / %L / %T Name Author Score Age
1 53.6/ 30.2/ 16.2 Light Sprain Dave Hillis 177.0 40
2 52.8/ 35.4/ 11.8 Ankle Breaker Dave Hillis 170.1 41
3 39.5/ 27.5/ 33.0 Agni Ayan Chakrabarti 151.6 20
4 43.4/ 35.6/ 21.0 Gomjabbar VI Ingo S Kacza 151.2 43
5 46.2/ 41.9/ 11.9 Grand Mal 1.1 Ransom Smith 150.5 93
6 36.4/ 23.6/ 40.0 test RF B1 Gino Oblena 149.1 5
7 39.6/ 33.0/ 27.4 MorphinMerlin Jeremy K 146.3 91
8 35.4/ 25.5/ 39.2 test RF A4 Gino Oblena 145.3 6
9 39.6/ 40.2/ 20.3 Seek&Destroy Ayan Chakrabarti 138.9 70
10 26.1/ 16.0/ 58.0 Liquid Crystal John Morahan 136.1 18
11 29.5/ 23.3/ 47.1 Un___ortant 1.1 Ransom Smith 135.7 13
12 39.5/ 43.4/ 17.1 8thTest Gino Oblena 135.7 1
13 38.3/ 44.8/ 16.9 Zaphod Ayan Chakrabarti 131.8 31
14 36.9/ 42.2/ 20.9 Advanced Spooner Josef Jahn 131.6 95
15 38.9/ 47.7/ 13.4 Xord Monominer XOSC:01 Gino Oblena 130.0 2
16 29.1/ 29.1/ 41.8 Simpleton Ayan Chakrabarti 129.1 29
17 38.9/ 49.0/ 12.1 Safai Ayan Chakrabarti 128.8 19
18 36.7/ 46.2/ 17.1 Even More Advanced (read: Josef Jahn 127.2 97
19 38.2/ 49.7/ 12.2 JGFTestQ Gino Oblena 126.7 4
20 22.0/ 20.4/ 57.6 Watcher John Metcalf 123.5 63
21 24.6/ 26.0/ 49.4 Caladan III Ingo S Kacza 123.1 50
22 33.8/ 46.1/ 20.1 BhootRaj Ayan Chakrabarti 121.6 21
23 29.2/ 38.2/ 32.6 Disaster Area 2.0 Stefan Foerster 120.2 44
24 21.9/ 25.6/ 52.5 Hyper Advanced (read: sux Josef Jahn 118.2 82
25 33.2/ 48.6/ 18.2 Hot Knife Wayne Sheppard 117.8 36
26 29.3/ 43.5/ 27.2 Xord Catapult v2.q4f Gino Oblena 115.1 3
Top 25 Averages:
36.1/ 35.6/ 28.3 136.7 40
For the short length of time Pizza was up, the beginners' hill saw 66
successful challenges. Six warriors reached retirement age, Mob Boyz,
Pimp King, Heatseeker, Arkenstone, Kenshin d and the boy's a time bomb.
______________________________________________________________________________
Current Status of the KOTH.ORG '94 No Pspace Hill:
# %W/ %L/ %T Name Author Score Age
1 38/ 24/ 38 Quicksilver Michal Janeczek 151.5 589
2 36/ 22/ 42 Son of Vain Oversby/Pihlaja 150.4 416
3 46/ 42/ 12 G3-b David Moore 149.3 97
4 36/ 24/ 40 Inky Ian Oversby 148.9 306
5 45/ 41/ 14 Hazy Lazy ... Steve Gunnell 148.6 169
6 43/ 41/ 16 Behemot Michal Janeczek 146.1 650
7 36/ 26/ 38 Uninvited John Metcalf 145.3 509
8 35/ 25/ 40 Olivia Ben Ford 144.9 555
9 33/ 22/ 44 nPaper II Paul-V Khuong 144.6 827
10 37/ 31/ 32 Blacken Ian Oversby 143.1 1074
11 45/ 47/ 8 test John Metcalf 143.1 1
12 35/ 27/ 39 Revival Fire P.Kline 142.6 295
13 40/ 41/ 19 Little Jewel X Lukasz Grabun 138.4 5
14 41/ 44/ 15 Deep Freeze X Lukasz Grabun 138.4 16
15 36/ 34/ 30 Keyser Soze Anton Marsden 138.1 528
16 43/ 50/ 7 He Scans Alone x P.Kline 137.1 155
17 30/ 23/ 47 paper/stone test simon 136.3 102
18 41/ 46/ 13 Kenshin D Steve Gunnell 136.3 31
19 32/ 27/ 41 Qtest Christian Schmidt 136.0 349
20 27/ 19/ 54 Mr Sheen B Steve Gunnell 134.5 8
The hill has aged by 471 and only 7 warriors remain from last issue's hill
status. Among those which perished are Eraser II (age 781), Jinx (662), Jade
(600), Phantom Menace (465), G2-b (413), Stalker (393), Vain (141),
Brigadeer (127) and Phantasm 50 (119).
_______________________________________________________________________________
The '94 No Pspace Hall of Fame: * indicates the warrior is still active.
Pos Name Author Age Strategy
1 Blacken Ian Oversby 1074 * Q^2 -> Stone/imp
2 nPaper II Paul-V Khuong 827 * MiniQ^3 -> Paper
3 Eraser II Ken Espiritu 781 Scanner
4 Jinx Christian Schmidt 662 Scanner
5 Behemot Michal Janeczek 650 * MiniQ^3 -> Bomber
6 Jade Ben Ford 600 Q^4 -> Stone/imp
7 Quicksilver Michal Janeczek 589 * Q^4 -> Stone/imp
8 Olivia Ben Ford 555 * Q^4 -> Stone/imp
9 Keyser Soze Anton Marsden 528 *
10 Uninvited John Metcalf 509 * MiniQ^3 -> Stone/imp
11 The Phantom Menace Anton Marsden 465
12 Boys are Back in Town Philip Kendall 441 Scanner
= Zooom... John Metcalf 441 Scanner
14 Son of Vain Oversby/Pihlaja 416 * Qscan -> Stone/imp
15 G2-b David Moore 413 Twoshot (?)
16 Stalker P.Kline 393 Scanner
17 Qtest Christian Schmidt 349 *
18 Vain Ian Oversby 330 Q^2 -> Stone/imp
19 Omnibus John Metcalf 327
20 Win! David Moore 322 Scanner
21 Inky Ian Oversby 306 *
22 Revival Fire P.Kline 295 *
23 Recovery Ian Oversby 280 MiniQ^2 -> Paper/stone
24 The Fugitive David Moore 274 MiniQ^2 -> Paper/imp
25 Jaguar Christian Schmidt 269 Q^3 -> Stone/imp
Blacken moves into four figures and is still going strong. More than half of
the current hill has a place in the Hall of Fame, artificial aging at work?
Can anyone help fill out the missing strategies?
_______________________________________________________________________________
Extra -
Son of Vain by Ian Oversby and Joonas Pihlaja
The original Vain was designed and implemented for the '94 draft hill.
At that time, the hill was very diverse with a good selection of
p-spacers, imp/stones, papers and scanners. Gigolo had recently left
the hill and p-spacers were in the acendancy - there were around 5 or
6 on the hill most of the time. My initial write-up of Vain can be found on
google groups at
http://groups.google.com/groups?selm=20010426161203.09498.00001092%40ng-mk1.aol.com
For a stone to do well on the hill it was clear that it should take
some points from other stones and papers in addition to thrashing
p-spacers and scanners. To trash a p-spacer it was enough to be
resilient enough against any anti-stone component in a paper that
the stone was frequently fighting pure stones / scanners or bombers.
My initial research led me to believe that most of the papers on the
hill were based on either RetinA by Paul Kline or CC-Paper by Franz.
RetinA is a defensive self-fixing paper using some mov instructions
to fix neighbours in case they have been hit by a spl carpet.
Timescaper paper:
s1 spl @0, #step1
mov }s1, >s1
s2 spl @0, #step2
mov }s2, >s2
; -- bombing
mov {s2, <s3
s3 jmp @0, #step3
A timescape style paper looks like the following with three copying
modules marked s1, s2 and s3. CC-Paper replaces the final copying
module with a simple coreclear.
Both RetinA and CC-Paper are quite good against complex bombers and
scanners but weak against imp/stones. Worse for them, a very
aggressive stone can cripple enough paper modules early in the round
that it is possible for the stone to score a win. In particular
the original Vain scored very well against Fixed and Vigor, both
RetinA style papers which survived until the hill wipe.
>From the early development stages, Vain performed well against the
imp/stones on the hill. Paul Kline observed that numbers work
very well against stones in Core Warrior 32:
"A single stand-still program is at a disadvantage against an
opponent running at multiple locations. Kill one part and
the others run faster."
Additionally, the stones of that time did not generally throw real dat
bombs and d-clear was very resilient vs increments, decrements or dat
0,0.
Vain performed somewhat less well against scanners than most stones
because of his size. Indeed, I imagined his presence should attract
all manners of scanners, one-shots and vampires. However the score
was not as poor as I imagined. I can think of a number of reasons
why this might be the case. Perhaps most importantly, stunning the
clear does not make much difference for several cycles - the stone
might still land the fatal bomb. Another significant factor seemed
to be the step-size. As most scanners are at least 8 instructions,
a coarse step was fine against them. One-shots have not done well
on the '94 hill in the past few years as everybody submitted
several versions of their warrior with slightly different boot
distances until they slaughtered any poor one-shot tenuously clinging
to its position.
Vain entered the hill in a similar position to Newt and they scored
similarly until Core Warrior 67 when Newt dropped several places
and Vain rose a little. It seems that Newt is a stronger warrior
according to the relative positions on the Koenigstuhl so the
reason for this performance on the '94 hill is unclear to me. If
anyone has any ideas I would be very interested to hear them.
** -- Joonas' Bit -- **
The overall strategy of Son of Vain (SoV) is the same as in Vain -- a
stone to keep the scanners away, a d-clear to give an edge over other
stone/imps, and imps to protect against paper. The intention was to
beef up Vain so that it could stand against modern warriors, perhaps
tacking on a newer quickscan and sliming the boot a bit. Somehow,
SoV's evolution turned into the search for the holy grail of Core War:
The ultimate warrior with no weaknesses. Obviously we never found it,
but sure had an interesting time looking.
* Vain, ancestors
-----------------
Redundancy is a factor in almost every warrior from papers and
imp/stones to intricate multiple component warriors. This is seen
especially in the warriors that influenced Vain's development:
Nimbus 1.2 by Alex MacAuley
- Huge imp spiral + parallel delayed dat wipe. The idea was to use
the imp as an offence to disrupt the opponent and leave the clear
to mop up the cripples.
Smooth Noodle Map by Matt Hastings
- A small, fast and disruptive bomber followed by paper and/or dat
clear + bombing. (_The Core War Newsletter_, Fall 1992 and Winter
1993 issues.)
Vagabond by Paul Kline
- Stone -> Anti-imp paper. Paul's debriefing gives valuable insight
into creating a successful warrior -- be resilient and be prepared.
(_Push Off_, October 25, 1993)
Impfinity by Planar
- A stone/stone/imp/imp. Philosophically the most influential
warrior in Vain's development. Carefully calibrated twin stones
and imp launchers for redundancy, with the stones mutating into
clears during end game. (Also, the stones split fast enough to
shrug off a scanner's stun attack for a while.)
And finally, not directly attributed, but sharing similar features:
PacMan v3 and v6 by David Moore
- A parallel stone and delayed clear. The stone is particularly
disruptive, with the clear killing it after a suitable number of
cycles.
The common features in all these warriors are asymmetry and redundancy
-- they handle multiple types of opponents by having a primary attack
coupled with a secondary component that takes over if the first is
wounded or killed.
* From Vain to Son
------------------
Now for some spade work. The first thing to do was to probe Vain for
its weaknesses. Here are some results (quickscans were turned off in
Vain and the opponents):
enemy Vain ties enemy Vain ties
* Clears/One shots * Scanners
One Shot 52 24 24 Boys Are Back in 51 25 24
Frontwards 42 30 28 myBlur 2 49 31 20
ostest2 41 25 34 Blur 2 46 40 14
goonie 25 29 26 Ice (from Fire&) 42 45 13
HSA 40 55 5
* Paper/Stone * Paper
Recovery 23 11 66 nPaper II 48 4 48
Shadow 1 8 91 Recovery Pulp 21 9 70
Puddleglum 0 10 90 Sad 16 13 71
unrequited love 10 3 87
No More Innoc 0 4 96
Fixed 1 34 65
* Stone/Imps
Nine Seven Six 21 15 64 Baseline Deluxe 2 11 87
Newt 16 2 82 Jade 2 14 84
IcePick 4 21 75 Jaguar 1 9 90
The Stormbring 3 8 89 Wintermute 0 10 90
Vain has trouble with one-shots and clears, which we found out was due
to the component boot distances. The active components were booted
after the warrior body, quite close to each other, and a one-shot
would quite often miss the decoys and stun the whole warrior. Also,
many of the newer scanners give Vain grief again due to its component
boot distances and largish components.
Most papers (omitted) scored like No More Innocuous, virtually all
ties. However, as the results show, anti-imp paper are a real threat
against Vain. This is also true for the son.
Results against stone/imps are encouraging -- Vain has the lead.
Newer stone/imps like Jaguar or The Stormbringer aren't all that
vulnerable. (Note that SoV development started in December 1999, so
the warriors we tested against are from that time.)
The goal then, was to beef up Vain against one-shots and clears while
at least retaining performance again stone/imps. Note that P-spacers
weren't targetted specifically as SoV was to go on -94nop. [Vain
however was written for the -94 hill.]
* The stone
-----------
The Rosebud stone in Vain is five lines long, throws bombs at .33c,
and uses a djn-stream. It doesn't include its own bomb, so it moves
bits of core (usually dat 0,0) around hoping to hit the opponent.
Newer scanners (The Machine or myBlur 2, for instance) are optimised
against this type of bomb so that they fall into their second phase,
usually a clear, when the scanning loop is hit by a dat 0,0. Some
spl/dat wipes such as the wipe from Recycled Bits or The Core Clear
are also optimised against dat 0,0 throwing stones.
After a few iterations of redesigning Rosebud, we decided that keeping
that design wasn't good for us. What we really wanted was to thwart
anti-dat clears and scanners with real dat bombs, just like Carbonite
and most other stone/imps. The stone should bomb for a long time
preferably hitting every core location, so that if an opponent stone
cripples the clear, the stone would at least have a chance of killing
the opponent. It should end in a dat wipe for good measure to cover
any spots the bombing missed, and it should have a minimal footprint.
An original design goal was also to make the stone's long bombing run
be able to sometimes defeat paper, like Rosebud. This never worked
out as our other constraints restrict the maximum length of the
bombing run to about 8000 bombs and 8000 decrements. We just couldn't
get a long enough bombing time and still have a good bomb spread.
Another conflicting constraint is that we wanted to make the stone
component brittle.
At this point our design looks pretty normal, like Carbonite:
stone: spl #0, 0
mov bmb, 1-TIME*step
add #step, -1
djn.f -2, <1234
... dat 0,0 ...
bmb: dat >-1,>1
They say that necessity is the mother of invention, but in this case
it turned out to be Paul Kline and John Metcalf. In issue #65 Kline
published a method for creating a small 3-line stone that bombs almost
all of core by modifying its step size during the battle. Why hadn't
this technique been used in a stone/imp before? Well, those stones
look more or less like this:
mov }1-N*2, 1-step
tgt: sub.x #step, -1
jmp -2, }-2
The way this one works is best seen through the debugger. In short,
it starts an a-field increment stream at tgt-N*2 that will hit every
second cell and finally the 'tgt' line, mutating the '#step' field
after N bombs. This happens in subsequent passes, every 4000 bombs.
The initial step needs to be chosen so that no bombs hit the stone
while it is running. The increment stream and step have to be
carefully calibrated, and the easiest way to do this is to use only
one process in the loop.
We need to have a multi-process stone as the clear and imp launcher
are started in parallel with it. The obvious modification to Kline's
stone is to add an spl at the front, but this doesn't work as
expected. The timing is all wrong, and the jmp line can't be
converted into something useful such as djn. The number of processes
fed to the stone would need to be very carefully calibrated, but we
never went with this further. We need a different mechanism to mutate
bits of the stone.
Scouring various stones we found the crucial idea in John Metcalf's
Puddleglum. Its stone (Spooky Wench?) looks like this:
sStep equ 3039
sTime equ 3357
sGo: spl #0, 0
spl #0, 0 ; aggressive stone (Spooky Wench?!)
sLp: mov sBmb, @sP
sSel: add #sStep, sP
sP: djn.f sLp, {sSel-sStep*sTime
sBmb: dat 2, >1
Look at it in cdb. Note that the bomb pointer is actually the djn.f
line's b-field! When the djn executes, the mov line has just put an
sBmb right where the djn's b-field points, so the bomb pattern ends up
being:
dat 1, >1 ; a-field of sBmb is decr. by djn's {
dat -1, -1 ; decremented.
...
dat 1, >1
dat -1, 1
...
Instead of having a '2' in the bomb's a-field, we could have any
offset, making this similar to the Torch bombing engine (with
decrements as the second bomb at .33c and .33c bombing totalling to
.66c), rather than a .33c bomber with a two-line payload like
Puddleglum. Puddleglum's stone is probably the first to use this
technique.
By carefully programming the step size and decrement offset we can
make the decrement land anywhere we want, and we want it to land on
the '#sStep' field. But only the a-field should be mutated, so we
changed the djn to an a-field decrement. In any case, while not as
disruptive as .f decrements, we feel that a-decrements are the next
best thing. [While it is certainly possible to a-decrement protect
scanner or stone loops, most aren't. Also, against typical paper
modules a-decrements are doing more damage than other forms. See the
article on Newt v0.2 in issue 69.
This is what the stone looks like:
; step: first step size before mutation.
; hop: offset of decrement from bomb.
; time: number of bombs before first mutation of step size.
; label tgt: target of first mutation (see below).
stone: spl #0, 0
mov bmb, @2
tgt: add #step, 1
djn.a -2, {(tgt-hop)-(step*time)
... dat 0,0 ...
bmb: dat 1+hop, >1
The resilience to process timing changes in Puddleglum's form is
paramount -- the decrements are always in sync with the bombs. It
doesn't really matter how many processes are fed into the stone, or
whether any fall off the djn.a line, as those events don't change the
bomb pointer.
The >1 b-field in the bomb was chosen because eventually we want the
bomb to hit the add line of the stone, mutating it into a forward
clear like in Carbonite.
Note that in addition to mutating the stone's step, we can also mutate
the decrement line's 'hop' to change the stone's pattern. This won't
affect where the bombs land though, so can only be used to realign the
decrements so as to finally hit the add line. We can also mutate the
mov line's a-field to change the bomb pointer, but in this case we
must make sure that the line 'bmb-1' has been bombed before. This has
the potential to mutate the 'hop' again to a previous value (or
another value), as the bomb at 'bmb' may have been mutated earlier.
Another technique for realigning the bombs is to bomb the djn line,
changing the bomb pointer to 1. This technique is used in the bomber
from Recycled Bits to prolong the bombing time. It slows our bomber
to .25c though, so should be done only late in the battle.
OK, it all works out in theory. How do we find good constants to make
the stone work in practice? Our approach was to program a custom
simulator that runs the stone and records where the bombs and
decrements land. Then weed out those constants that either hit the
stone body too soon, or have bad bomb spread. A big speedup came from
the fact that bombs and decrements are thrown linearly, which lets us
skip over the majority of cycles where we can prove that nothing
interesting happens, and lets us concentrate on the the cycles where a
bomb or decrement lands on prespecified cells. A further time savings
is that in some versions of the program we actually run the simulation
backwards in time -- this lets us efficiently force the constraint
that we want the last bomb to land on the add line (mutating the stone
into a forward clear).
In our tests it was beneficial to make the stone weaker than the form
given above. It should be made a brittle as possible so that if
anything touches it, such as an opponent stone bomb, it should
preferably self-destruct and let the processes in the clear take over.
The final form is:
spl 0, 0
stone spl 0, 0
mov bmb, @2
add #step, @-1
djn.a @-1, *st+(tgt-hop)-(step*time)
... dat 0,0 ..
bmb dat >hop, >1
The { in the djn.a line was changed to * so that the stone wouldn't
start an a-decrement wipe when damaged, possibly hurting our clear
component. We couldn't come up with something that would reliably
self-destruct in case the stone itself was wiped by an opponent's
djn.f stream -- this version usually only stops producing more
processes. Our best hope is for our clear to put the crippled stone
out of its misery before long.
One idea to make the stone even more brittle is to use spl }0, {0
instructions instead of spl 0,0 instructions, as in some versions of
Carbonite. Unfortunately this doesn't work as expected -- a bomb
eventually hits the spl at stone-1, which has live processes. When
they execute the bomb instruction they increment the b-field of stone,
and the stone ends up looking like this:
dat >hop, >1
stone spl }1, {1 ; when executed, decrement mov line
mov TRASH, @2
add #step, @-1
djn.a @-1, *st+(tgt-hop)-(step*time)
... dat 0,0 ..
bmb dat >hop, >1
Granted, when stone-1 line is hit the number of processes live at the
stone line is known, so the mutation caused by the spl }1,{1 line at
stone could be compensated for at least for a while. [Compensated by
having bmb-1, bmb-2,... bombed before a process mutates the mov line.]
It's just too much trouble for the effort.
* Clear
-------
The d-clear form is from Digitalis 2:
dgate dat 0, 1234
dmop dat 0, dclr+5-dgate
... dat 0,0 ...
dclr spl #0, 0
mov dmop, >dgate
djn.f -1, >dgate
This has the advantage of having a small footprint as the bomb line
(dmop) is moved away from the clear body. In our tests we found that
this form has problems when fighting other stone/imps. Namely if the
clear is decremented it would start hogging processes and not clear
with a good bomb any more. Hogging processes when the clear is
decremented is good, because in that case we are probably fighting
another stone/imp and want the clear to take over. But the processes
end up being scheduled so that the clear moves in spasms, which isn't
so good after all.
Another problem with the clear above is that while the stone is alive
it doesn't gather many processes. This hurts us when the stone is
crippled but not dead since the clear doesn't have enough steam to
wipe over it. We decided to add another spl to the clear and
decrement protect it. This form of clear should survive a single a-
b- or f- decrement stream, and also any random a-decrements from
stones (like Newt or Impfinity v4g1, for example).
dgate dat 0, 1234
dat.a <2667, dclr+7-dgate
dat.a <2667, dclr+7-dgate
... dat 0,0 ...
dclr spl #0, 0
spl #0, {dgate
mov dgate+2,>dgate
djn.f -1, >dgate
As now both the stone and the clear have two spls at the top, the role
of process scheduling during booting is highlighted.
* Imps, launchers, and the quickscan
------------------------------------
Yer basic 3-point imps. Fairly early on we decided on the
Vortex/EvolImp launcher for its small size/efficiency ratio. B-field
imps seem more resilient, but on the hill nPaper II beats us up
anyway. Which is strange. But then most anti-imp papers can and do
serious damage to SoV.
The imp instruction is 'mov.i #10,2667', with the idea that if the imp
hits a clear that uses the a-field as its clear pointer, then the
clear would overwrite itself if it is placed 10 cells of further from
the gate. The #10 was probably better than #1 in tests for some
particular clear...
As for the quickscan, David Moore had published his faster version in
Return of the Fugitive so we chose that. It is a nuisance to work
with as it is sensitive to the locations of the decode tables, but we
never got around to reprogramming it to be more flexible. Instead we
created a database of suitable parameters and chose among them during
optimisation.
The maximum separation between scanned locations is limited by a pair
of scanning instructions in that code, which dictates that the one of
the decoding tables and the attack routine must be spaced as far apart
as possible in the code. We implemented approximate decoding to help
bring the separation limit higher, but there wasn't any noticeable
effect. Unfortunately we didn't figure the real problem out until
later.
* The Boot
----------
The most trouble we had was putting the components together so that we
wouldn't be clobbered by an opposing qscan attack. The problem is
that without the quickscan we have a minimum of 14 non-empty cells,
not counting the quickscan, its attack, or any of the boot. Compare
this with your typical paper which has maybe 11-14 cells sans
quickscan+attack, including boot.
non-empty cells
launcher 1 + 3 | 4
stone body + bomb 4 + 1 | 5
clear body + bomb 4 + 1 | 5 = 14 non-empty cells
The form of the quickscan requires that one of the decoding tables and
the quickscan attack be at opposite ends of the warrior. The
quickscan attack is 7 lines, and the decoding table is 3 cells, so
it's not possible to put the imp-launcher at the top of the warrior,
like some other stone/imps (Vain, Newt v0.2). This means we need to
boot the imp launcher, since we can't afford to leave it unbooted with
live processes *behind* either the decode table or qscan attack, which
a one-shot is sure to find (and then to stun anything behind it). For
the same reason we didn't start the imp-trail inside the warrior, but
wanted to boot the imp instruction as well.
Even Blur-like scanners are a threat to processes that are directly
behind some big decoy at the start of the battle -- the scanner finds
the decoy and may not find anything else in the time it takes to stun
the processes that are behind it.
We also need to boot some auxiliary data that the stone and clear
need.
non-empty cells
boot clear bomb+data 2 + 1 | 3
boot stone bomb+misc 1 + 1 | 2 = 19 non-empty cells
Considering the amount of stuff we need to boot, an unrolled 1c boot
is out of the question (it would take an additional 11 cells + some).
In any case, the boot needs to send four parallel processes to the imp
launcher, and we might as well use those four processes to boot most
of the continuous data. A part of the boot looks like this:
spl 1
spl 1
mov <clr_src, <clr_dst ; boot clear body.
mov <sto_src, <sto_dst ; boot most of stone body.
mov <imp_src, <imp_dst ; boot imp launcher.
spl @sto_dst ; start stone.
jmp @imp_dst ; start launcher.
By now it's obvious that SoV is positively obese! During booting the
main threat is an opponent quickscan attack. It is usually a fast loop
that bombs every 6-12 cells, so adding the rest of the necessary boot
code to the above would make it near certain that SoV's boot would be
wounded. Instead we opted for a secondary piece of boot code that
runs in parallel with the primary boot above. It boots all the
miscellaneous bits and pieces, and starts the clear. This technique
is used in Freight Train v0.2.
An additional optimisation is that the secondary boot starts an
unbooted d-clear if the primary boot failed. This costs us an extra
line in the secondary boot. There's almost no penalty against
non-quickscanning warriors, and the extra redundancy helps against
other stone/imps. Against papers and stone/papers there is a slight
loss, but on the balance it does help.
Considering the boot distances of the components, the clear and imp
launcher are booted quite close in front of the main warrior body,
with the stone further on in core. There's not much in decoy being
placed above the clear and imp launcher so one-shots tend to trip up
on the dead quickscan code. The imps are launched late enough in the
battle that they don't create significant visible matter for one-shots
or once-through scans until the stone has had time to rev up some
processes.
* Optimising
------------
Having a clearly outlined strategy and killer components is wonderful,
but they won't be worth much unless properly optimised. One problem
we had was that the constants for individual components, boot
distances, and process scheduling interact with each other in often
strange and mysterious ways.
We ended up with a system of virtual KotH, where we generate candidate
warriors more or less at random, and scoring them against a set of
benchmark warriors. The warriors that stay on the hill the longest
with a high score should be the most resilient against the benchmark.
There are a myriad of details that are more relevant to warrior
optimisation in general than Son of Vain per se, so we won't delve on
them. Many kudos to Ken Espiritu and Robert Macrae for sharing their
thoughts on benchmarking, optimisation, and general helpfulness.
Especially with the myriad of details.
* Weaknesses
------------
At the time SoV entered -94nop it had an 8 point lead on the rest of
the hill, which we quite fancied. Even though that couldn't last
forever, it is still holding up reasonably on the hill. As with Vain,
anti-imp replicators can hurt SoV quite badly. The best at this are
the Pulp derived papers and Planar's paper from Bipolar. Combined
with a stone, anti-imp paper really hurts. eg. Recovery and Inky.
Newer anti-dat scanners with airbags give SoV a hard time too.
myBlur2 by Paulsson and Moore was specifically optimised against, but
that was the only such scanner available at the time.
;redcode-94nop
;name Son of Vain
;author Oversby/Pihlaja
;assert 1
load0 z for 0
rof
ofs equ (-2) ; offset boot distances by this much.
; stone constants
step equ 6457 ; primary step
hop equ 3643 ; decr. ofs from bomb
dbofs equ 9 ; bomb distance from stone
tgt equ 2 ; first mutation target
time equ 2293 ; bombs before first mutation
sdist equ (2599+ofs) ; boot distance
; clear constants
dgate equ (dclr-9)
dwipeofs equ (-947) ; offset of clear trail from stone
ddist equ (7328+ofs) ; boot distance
dmopa equ <2667 ; mop a-field
; spin constants
ldist equ (7426+ofs) ; boot distance
ldecoy equ (5956+ofs) ; decoy distance
idist equ (7471+ofs) ; imp trail dist.
; qscan constants
a1 equ 3922 ; factors and scan offsets
a2 equ 1999
b1 equ 609
b2 equ 6686
b3 equ 4763
c2 equ 2149
d equ 5014
; qbomb constants
qrep equ 13 ; repeats of bomb loop
qinc1 equ 7 ; attack step
qhop equ 60 ; offset of bomb
;;-- primary boot
;;
boot spl misc , >b1 ; start secondary boot
t2 spl 1 , >b2 ; t2 = qscan decode table
spl 1 , >b3
mov <dsrc , <ddst
mov <ssrc , {sdst
mov <lsrc , {ldst
sdst ddst spl load0+sdist+4, load0+ddist+4
ldst jmp load0+ldist+4, <chk_flag
dat 0,0
dat 0,0
dat 0,0
dat 0,0
dat 0,0
dat 0,0
;;-- imp launcher
;;
lsrc
spin spl #1 , 4 ; the a-field is checked by misc boot.
add.a #2667 , 1
djn.f spin+idist-ldist-1-2667,<spin-ldist+ldecoy
dat 0 , 0
dat 0,0
dat 0,0
t3 dat.a qhop , c2 ; t3 = qscan decode table
dat 0,0 ; & attack bomb.
dat 0,0
dat 0,0
dat 0,0
;;-- clear
;;
imp mov.i #10 , 2667
db dat.a >hop , >1 ; dat bomb for stone
dmop dat.a dmopa , dclr+8-dgate ; dat bomb for clear
dat 0,0
dat 0,0
dat 0,0
dat 0,0
dat 0,0
dat 0,0
dsrc
dclr spl #0 , 4
spl #0 , {dgate
mov dgate+2 , >dgate
djn.f -1 , >dgate
dat 0,0
dat 0,0
dat 0,0
dat 0,0
dat 0,0
dat 0,0
dat 0,0
dat 0,0
dat 0,0
dat 0,0
;;-- qscan body
;;
qscan seq qb + d , qb + d + b2
jmp q1
sne qb + d * a1, qb + d * a1 + b2
seq <t1-1 , qb + d * (a1-1) + b2 ; t1-1 + a1-1
djn.a q0 , {q0 ; == qb+d*(a1-1)
sne qb + d * a2, qb + d * a2 + b2
seq <t1 , qb + d * (a2-1) + b2 ; t1 + a2-1
jmp q0 , {q0 ; == qb+d*(a2-1)
sne qb + d * b1, qb + d * b1 + b1
seq <t2-1 , qb + d * (b1-1) + (b1-1); t2-1 + b1-1
jmp q0 , {q2 ; == qb+d*(b1-1)
sne qb + d * b3, qb + d * b3 + b3
seq <t2+1 , qb + d * (b3-1) + (b3-1); t2+1 + b3-1
jmp q0 , }q2 ; == qb+d*(b3-1)
seq qb + d * (b1-2),qb + d * (b1-2) + (b1-2); must follow the
djn q0 , {q2 ; <t2-1 scan
sne qb + d * c2, qb + d * c2 + b2
seq <t3 , qb + d * (c2-1) + b2 ; t3 + c2-1
jmp q0 , }q0 ; == qb+d*(c2-1)
sne qb + d * b2, qb + d * b2 + b2
seq <t2 , qb + d * (b2-1) + (b2-1); t2 + b2-1
; == qb+d*(b2-1)
jmp q0 , >a1 ; q0-1 and boot-1
t1 jmp boot , >a2 ; must be dat 0,0's.
;;-- stone
;;
spl0
ssrc ;spl 0 , 0
st spl 0 , 4
mov -1+dbofs, @2
add #step , @-1
djn.a @-1 , *st+(tgt-hop)-(step*time)
dat 0,0
dat 0,0
dat 0,0
dat 0,0
dat 0,0
dat 0,0
dat 0,0
dat 0,0
;;-- misc. boot
;;
; bmbdist: address of stone bomb.
; gatedist: address of clear gate.
; wipedist: address of clear wipe start.
bmbdist equ (sdist+dbofs)
gatedist equ (ddist+dgate-dclr)
wipedist equ (sdist+dwipeofs-ddist+dclr-dgate)
misc mov imp , load0+idist
mov db , load0+bmbdist
pmop mov dmop , load0+gatedist+2
mov spl0 , {sdst
mov dmop , <pmop
mov.x #wipedist, <pmop
spl @ddst ; start clear.
chk_flag djn.a dclr+1 , *ldst+4
dat 0,0
;;-- qbomb
;;
; dat 0,0 ; dat be here.
q0 mul.b *2 , qb
q1 sne {t1 , @qb
q2 add.b t2 , qb
mov t3 , @qb
qb mov t3 , *d
sub #qinc1 , qb
djn -3 , #qrep
jmp boot
end qscan
* Scores
--------
Here are the results against our test suite. Wins and score are counted for
SoV.
Opponent %W %L %T Score
SnooPap 15.0 27.6 57.4 102.4 ; SnooPy Paper
nPaperII 9.0 14.1 76.9 103.9
RotF 8.7 11.3 80.0 106.1
KafuFFLe 16.7 11.6 71.7 121.8
RotJ 16.2 8.9 74.9 123.5
SafetyInNumbers 18.7 10.7 70.6 126.7
Recovery 25.5 22.4 52.1 128.6
Jaguar 22.0 9.9 68.1 134.1
Quicksilver 24.2 13.8 62.0 134.6
Wintermute 25.4 11.7 62.9 139.1
myBlur2 35.7 32.3 32.0 139.1
ostest2 35.6 29.6 34.8 141.6
Shadow 26.2 10.8 63.0 141.6
TheMachine 33.7 25.3 41.0 142.1
DigitalDragon 32.5 22.2 45.3 142.8
Puddleglum 29.0 14.6 56.4 143.4
CoreClear 33.5 22.5 44.0 144.5
Jade 26.6 7.7 65.7 145.5
OneShot 41.7 31.1 27.2 152.3
BoysAreBackInTow 41.0 29.6 29.4 152.4
Newtv0.2 33.8 13.8 52.4 153.8
Vain 34.1 14.3 51.6 153.9
TheStormbringer 32.8 10.6 56.6 155.0
SnooScan 43.8 29.8 26.4 157.8 ; SnooPy scanner
BaselinePlus 36.2 13.2 50.6 159.2
Goonie 47.1 28.7 24.2 165.5
frontrds 40.9 15.9 43.2 165.9
Fixed 41.3 16.3 42.4 166.3
Stalker 47.4 27.0 25.6 167.8
rbwipe 51.9 29.6 18.5 174.2 ; Recycled Bits wipe
SilverTalon1.2 50.8 20.6 28.6 181.0
Zooom 55.0 18.5 26.5 191.5
Phantasm50 59.3 21.2 19.5 197.4
HSA 65.1 26.7 8.2 203.5
_______________________________________________________________________________
Extra Extra - Mischief by John Metcalf
Mischief is a scanner created to illustrate the neglected .75c scan loop.
3 locations are scanned in a 4 instruction loop. One interesting point to
note is how the scan handles a find at *sPtr.
Anything uncovered by the scan is attacked with a spl carpet, similarly to
scanners such as He Scans Alone.
For the endgame, Mischief plays a dat clear. Newbies and beginners might
find their scanners / bombers gaining a few precious points by replacing
their d-clear with a similar dat clear. Can you explain why?
Here's the code:
;redcode-94nop
;name Mischief
;author John Metcalf
;strategy .75c scan -> clear
;assert CORESIZE==8000
st equ 13
fi equ 1961
sWipe equ (sPtr-1)
gate equ (attack-2)
sPtr dat fi+st, fi
for 5
dat 0,0
rof
attack mov sPtr, sWipe
wipe mov sBmb, <sWipe
mov >sWipe, >sWipe ; carpet
jmn.f wipe, >sWipe
reset mov.ba @a, @a ; reset
loop sub a, @a
sne.x *sPtr, @sPtr ; scan
a sub.x #-2*st, sPtr
jmz.f loop, @sPtr
slt sPtr, #dBmb+3-sPtr
jmp attack
djn reset, #16
sBmb spl #0, {0
clear mov dBmb, >gate
djn.f clear, {gate
dBmb dat >1, 2-gate
end loop+1
_______________________________________________________________________________
Extra Extra Extra - Oneshot '88 by John Metcalf
As indicated by the unimaginative name, Oneshot '88 is a typical example
of a oneshot, this time implemented for the ICWS '88 standard hill. Which
other strategies are still waiting for an effective implementation in '88?
;redcode
;name Oneshot '88
;author John Metcalf
;strategy .66c scan -> .66c clear
;assert CORESIZE==8000
st equ -11 ; -13 ; -12 ; -10 ; -14
fi equ -110 ; -106 ; -100 ; -108 ; -114
; 141.6 144.0 145.7 141.3 145.9 : David Moore's '88 Benchmark
; 143.7 141.1 137.7 139.2 135.4 : Warriors from KOTH (published)
kill dat <2667, <kill-sptr
clear spl 0, <kill-sptr-8
cloop mov @sloop, <sptr
mov @sloop, <sptr
bomb djn cloop, <kill-5
steps dat <st*2, <st*2
sloop add steps, @cloop
sptr cmp fi+st, fi
jmp <sloop
jmp sloop
end sptr
_______________________________________________________________________________
Questions? Concerns? Comments? Complaints? Mail them to people who care.
Beppe Bezzi <giuseppe.bezzi@galactica.it>, Philip Kendall <pak21@cam.ac.uk>,
Anton Marsden <anton@paradise.net.nz>, John Metcalf <grumpy3039@hotmail.com>
and Christian Schmidt <schmidt@mail.uni-mainz.de>
|
