new warrior
grabek
here is something i programmed recently. it's a 50% stun bomber that
uses indirect addresing mode for bomb throwing. well, it's the best i
ever have made till now and it scores 118 on koth nop hill (still too few
points to get on it).
;redcode-94nop
;name frenzy v6
;author Lukasz Grabun
;assert 1
org boot
step equ 2936
start add #step+step,2
mov bomb, @1
mov bomb, @1
cl jmp -3, >-8 ;hit to start clear
mov dbomb, >start-4
djn.f -1, >start-4
dbomb dat.f <5334, dbomb-start+7
bomb spl #0, #step
for 83
dat 0, 0
rof
boot mov bomb, 2000
for 7
mov {boot, <boot
rof
jmp @boot, <-1000
if you happen to know of any improvements that can be made... well,
please let me know.
p.s. pvk: thanks for your clear code, it seems to work perfectly.
--
pozdrawiam, grabek
Paul Khuong
> From: core...@koth.org [mailto:core...@koth.org]On Behalf Of grabek
> Sent: 21 novembre, 2001 16:34
> To: Multiple recipients of list COREWAR-L
> Subject: new warrior
>
>
> howdy core warriors...
>
> here is something i programmed recently. it's a 50% stun bomber that
> uses indirect addresing mode for bomb throwing. well, it's the best i
> ever have made till now and it scores 118 on koth nop hill (still too few
> points to get on it).
>
> ;redcode-94nop
> ;name frenzy v6
> ;author Lukasz Grabun
;-)
> ;assert 1
> org boot
>
> step equ 2936
>
> start add #step+step,2
> mov bomb, @1
> mov bomb, @1
> cl jmp -3, >-8 ;hit to start clear
> mov dbomb, >start-4
> djn.f -1, >start-4
> dbomb dat.f <5334, dbomb-start+7
> bomb spl #0, #step
>
> for 83
> dat 0, 0
> rof
>
> boot mov bomb, 2000
> for 7
> mov {boot, <boot
> rof
> jmp @boot, <-1000
>
> if you happen to know of any improvements that can be made... well,
> please let me know.
>
> p.s. pvk: thanks for your clear code, it seems to work perfectly.
Well, actually, yes, there a few improvement that would be possible. The
first is that you could make the step mod 4 ot 5(yup, see where the bombs
hit), which is usually cosidered pretty good when you have a good step size.
Then, the bomb engine. Being a nice not-so-quick bomber, you could switch to
the Tornado engine, which basically is:
add step, bomb3
mov bomb, *bomb3
mov bomb, @bomb3
bomb3 mov [x], @[y]
jmp -4
It is only one line bigger, and you gain some speed... Your choice, in the
end, but try it(oh, understand it first 8)
After that, it's sort of my fault. As i said in the psot, my d-clear isn't
the best one, mainly for one reason: the dat bomb.
It is SO easy and costs nothing to use a better bomb, but i can't remember
what that better bomb is!
I THINK that it is dbomb dat.f >5335, [whatever], but i'm not sure. Look
around in the archives of warriors, or for a post(probably by Paul Kline)
which has that.
Of course, it's not much, but it's free improvement, so....
Also, the clear you use is vulnerable to star-imps(mov.i #2667, *0, fe),
because there is no non zero-dat right after the gate, and it could be made
more resilient to stones at the expense of one line(i think that i've
explained it real quick in an older post).
Finally, you're not using an easy way to rack in wins: a QScan. Usually, you
cna just paste the code in front of your boot code, but it's very
interesting to try and understand how they work(especially for the more
advanced ones, where it becomes very gratifying 8)
That's all that i can say, oh, and, do try to build papers and scanners
after that, they're a bit harder, but also very interesting.
Paul Khuong
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.281 / Virus Database: 149 - Release Date: 01-09-18
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
grabek
first of all, thanks for hints.
>
> Then, the bomb engine. Being a nice not-so-quick bomber, you could switch to
> the Tornado engine, which basically is:
>
> add step, bomb3
> mov bomb, *bomb3
> mov bomb, @bomb3
> bomb3 mov [x], @[y]
> jmp -4
>
> It is only one line bigger, and you gain some speed... Your choice, in the
> end, but try it(oh, understand it first 8)
i've done this already, but it seems that tornado version
seems to score worse. don't know what's the reason for it, but my
frenzy with q^4 scanning engine supplied scores 125 :) and really
frenzy (tornado bomber) only 114.
--
pozdrawiam, grabek
M Joonas Pihlaja
> howdy core warriors...
Hi Lukasz,
> here is something i programmed recently. it's a 50% stun bomber that
> uses indirect addresing mode for bomb throwing. well, it's the best
> i ever have made till now and it scores 118 on koth nop hill (still
> too few points to get on it).
You've picked up the game at an impressive speed. I guess
jumping in the deep end is just the thing. :-)
Frenzy v6 is picking up most of its points off the scanners on the
hill, like a bomber should. The bad news is that against almost every
stone/imp it loses heavily. This is probably due to the form of the
bombing loop:
start add #step+step,2
mov bomb, @1
mov bomb, @1
cl jmp -3, >-8 ;hit to start clear
[..]
bomb spl #0, #step
You start it with only one process so if a dat bomb lands in it
while you're bombing you're dead for sure. Another point is that
the jmp line increments core near the warrior, making for a
bigger target for scanners. (Does the >-8 serve a purpose? I
couldn't tell from a quick glance.)
Now if the stone/imps on the hill were mostly dat 0,0 stones,
then you could get away with changing your loop to be
self-splitting:
bomb spl #0, <step
ptr mov bomb, @cl+step
mov bomb, @ptr
e add #2*step,ptr
cl djn.f -3, <bomb+step ; hit to start clear
[clear code]
The loop is started by jumping to the spl line and after a while
starts executing backwards. I've added a djn stream that is
prodded along by both the djn line and the spl's b-field, with
the end result that it has holes in it so to create a a better
decoy for scanners / one-shots. [The djn stream has the
side-effect of leaking processes into the clear if it encounters
any 1,1 fields -- this can be bad if the clear body is bombed
with a stun bomb by the opponent. Note also for later that the
bombing loop will always have at least one process in it (fed by
the spl line), even in the clearing stage.]
If the opponent hits the loop with a dat 0,0 bomb then you're not
automatically dead, and have a slim chance of surviving an
overrunning imp. Unfortunately on the hill this gets worse
results than the original (113 points vs. 118 unmodified). The
problem is that the assumptions are all wrong -- most stone/imps
most likely aren't dat 0,0 bombers, but throw real dat bombs a la
Carbonite. (I'm only mentioning the self-splitting solution
because a) I thought it might work, and b) it's a stepping stone
to a better solution.) The bombs usually look like dat #offset,
>1 or something similar.
When that kind of bomb hits a self-splitting loop like:
loop: spl #0,0
[...]
dat #ofs,>1 ; dat bombed
mov ?X, ?-Y ; Y a small number.
[...] ; ? almost any addressing mode.
jmp loop
then the loop will suicide, or at least be completely disabled
pretty damn quick. Ouch! Roughly the same thing happens with
dat #ofs,>-1 bombs as well -- Carbonite combines both forms with
dat >-1,>1. [There was a big incentive for stones to move to real
dat bombs since scanners and clears were engineered to be very
resistant to dat 0,0 bombing. The clear in Recycled Bits being a
real bugger, as well as scanners The Machine and myBlur2.]
So where before a self-splitting loop was good for
life-expectancy, real dat bombs are turning it into a liability.
The fix: Use a bombing loop that won't die if it is dat bombed,
but also without self-splitting. Aka an airbag.
The idea is to use a small fixed number of processes that are
scheduled to execute a loop exactly like a single process, and
the clever bit is that the loop is created so that the processes
can detect if the loop is dat bombed, in which case they fall
through to the clear. I doubt I could explain the mechanics of
it as lucidly as Paulsson in his posting of his bomber Airbag, so
I won't even try. Also see Janeczek's Behemot bomber for this
technique.
You might want to work on mutation resistance for your d-clear,
although late in the battle any opposing stone is hopefully
stunned. OTOH, as you do only a fast mod-8 bombing run, you might
not hit the opponent so it still has time to disable your clear.
OTOH #2, adding redundacy will make it bigger reducing points
gained from the bomber's main food supply. In any case the
article on Newt in Core Warrior from a few years back has some
good tips.
Regards,
Joonas
grabek
> while you're bombing you're dead for sure. Another point is that
> the jmp line increments core near the warrior, making for a
> bigger target for scanners. (Does the >-8 serve a purpose? I
> couldn't tell from a quick glance.)
i thought it would be an imp gate (though as inefficient as
one can be :)
> The loop is started by jumping to the spl line and after a while
> starts executing backwards. I've added a djn stream that is
the reason why i didnt put spl 0 before main loop is that i
wanted it to be _quick_. having more proceses makes one harder to
kill, but slows the warrior down. i wanted quick bombing raid and then
clear.
i managed to put my warrior on nop hill; however i dont belive
if it will stay there for long.
and at last but not at least: thank you.
> Regards,
>
> Joonas
--
pozdrawiam, grabek
Paul Khuong
> From: core...@koth.org [mailto:core...@koth.org]On Behalf Of grabek
> Sent: 24 novembre, 2001 15:35
> To: Multiple recipients of list COREWAR-L
> > The loop is started by jumping to the spl line and after a while
> > starts executing backwards. I've added a djn stream that is
>
> the reason why i didnt put spl 0 before main loop is that i
> wanted it to be _quick_. having more proceses makes one harder to
> kill, but slows the warrior down. i wanted quick bombing raid and then
> clear.
You don't jump to the SPL.
So, you only lose 1/x of the speed, where x is the number of process. AND,
that x is going to grow at a pretty good rate, so that the speed loss isn't
really important.
> i managed to put my warrior on nop hill; however i dont belive
> if it will stay there for long.
Still, well done!
M Joonas Pihlaja
On Sat, 24 Nov 2001, grabek wrote:
> the reason why i didnt put spl 0 before main loop is that i
> wanted it to be _quick_. having more proceses makes one harder to
> kill, but slows the warrior down. i wanted quick bombing raid and then
> clear.
Yeah, OK. (Though as pvk pointed out the speed penalty isn't all
that bad and reduces as time goes on.)
Anyway, I tested the airbag hypothesis, and while it does seem to
help (120 points vs. 118 unmodified), it doesn't solve the
problem with stone/imps (except Blacken). Here's the code:
;redcode-94nop
;name airbag frenzy
;author Lukasz Grabun
;strategy testing the airbag hypothesis (mjp)
;assert 1
gate equ (top-4)
step equ 2936 ; 2930
top
add #2*step,ptr
mov stun,@ptr
ptr mov }ck,@ck-1
jmz.a top,{ck
ck stun spl #0,step
mov bmb,>gate
djn.f -1,>gate
bmb dat <-5,2-gate
z for MAXLENGTH-CURLINE-7
dat 0,0
rof
go spl 2
psrc spl 2,top+10
pdest spl 1,top+10+2000
mov <psrc, <pdest
mov <psrc, <pdest
djn >pdest,#5
jmp top+2001
end go
I'm not exactly sure what the problem is, except that the spl #0
bomb isn't stunning the opponent's components for long enough or
well enough. Consider the difference to Behemot's bombs:
spl #2,-X
mov @0,}-1
and
jmp X ; jump to a spl/mov bomb.
If the jmp falls in a loop (even on the last instruction, or a
top spl #0 of a stone), then the opponent should be stunned
effectively quite soon. This works for basically any live
processes, even if they aren't executed very often. Ditto for
the spl/mov pair, assuming it isn't mangled by the loop.
A single spl #0 stun bomb is really only effective when it lands
*within* a frequently executed loop. Landing on the looping
instruction may work, but may cause the opponent to move to its
second phase, without really hampering it. Landing on a leading
spl instruction of a stone is useless unless it contains
important data, and even then the effect is unpredictable.
Even the benign looking mov.i #0,1 bomb used by Recount is
probably more effective in stunning a stone, since it does its
thing regardless of where it lands in the stone's code.
Something just occured to me about the airbag: since only the
looping instruction is unprotected from dat bombing, only 3/4 of
the loop is protected. In a tornado-like bomber, or a bomber
with a bigger payload, it would be better protected. Hm... time
to have a better look at what Behemot does.
> i managed to put my warrior on nop hill; however i dont belive
> if it will stay there for long.
Congratulations! (It's a huge rush, isn't it? My first warrior
on -94 had a short and euphoric life too. :) )
Joonas
grabek
> gate equ (top-4)
> step equ 2936 ; 2930
>
> top
> add #2*step,ptr
> mov stun,@ptr
> ptr mov }ck,@ck-1
> jmz.a top,{ck
> ck stun spl #0,step
> mov bmb,>gate
> djn.f -1,>gate
> bmb dat <-5,2-gate
>
>
> z for MAXLENGTH-CURLINE-7
> dat 0,0
> rof
> go spl 2
> psrc spl 2,top+10
> pdest spl 1,top+10+2000
> mov <psrc, <pdest
> mov <psrc, <pdest
> djn >pdest,#5
> jmp top+2001
> end go
first of all, i'd like to thank you both. the discussion that
had been raised here helped me a lot; currently i'm working on
multiple frenzy with airbag checking... don't know yet what it is
going to be :)
the second matter: i executed airbag frenzy code; it seems to
work properly, but there's one thing i just cant get along with.
there're four paralleral (?), independent processes executing the
code. in the main loop there's add #2*step, somewhere instruction.
it seems that it is executed 4 times, so the bomb's destination is,
well, altered.
dont know whether im expressing myself in enough clear way. :)
--
pozdrawiam, grabek
M Joonas Pihlaja
On Sun, 25 Nov 2001, Paul-V Khuong wrote:
[snip the b-scanning version score]
> DROPPED?
>
> How well did frenzy do before adding the b-scan VS
> papers?
Here are the results for all four versions. Speculation on the
on-hill warriors below.
frenzy v6 splitting airbag scan
- Paper-likes
Inky 28-170-52 37-145-68 39-151-60 16-217-17
nPaper II 36-168-46 21-142-87 29-152-69 7-214-29
The Phantom Men 8-105-137 4- 91-155 4- 85-161 6-116-128
No surprises here, except the scarsity of paper on the hill.
I'm not sure if Inky really is a paper though as on the hill it
scores much too high for one.
- Stone/imp
Quicksilver 65-152-33 33-141-76 64-164-22 58-182-10
Son of Vain 54-134-62 12-131-107 59-120-71 78-108-64
Olivia 61-125-64 18- 89-143 67- 96-87 71-137-42
Uninvited 63-144-43 35- 99-116 80-119-51 84-143-23
Qtest 41-159-50 41- 98-111 37-125-88 44-165-41
AxID Burn 49-152-49 25-134-91 63-138-49 61-152-37
Blacken 64-114-72 56- 70-124 91- 69-90 103-104-43
I put Qtest in with the stone/imps as it scores most like one
against the frenzies. Could actually be a heavy stone -> paper,
as the airbag and b-scanning versions do worse than the original,
and the splitting version mostly ties.
The splitting version does manage to convert many losses into
ties, but unfortunately does the same to wins. From the number
of losses incurred, I'm guessing Olivia, AxID Burn, and Uninvited
use real dat bombs (Son of Vain and Quicksilver are known to).
Blacken and Qtest probably don't. The splitting version had a
djn-stream, so if there are lots of 1,1s in some warrior this
would show up as reduced wins.
Mostly the airbag converts losses into wins, sometimes ties.
The b-scanning version clearly gets the most wins. A bit odd
that these stone-fortified versions lose more heavily to
Quicksilver and Qtest than the original
- Bomber
Fire and Ice II 64-141-45 73-158-19
Behemot 102-129-19 101-106-43 76-137-37 87-145-18
- Unknown
Revival Fire 87- 81-82 42-107-101 87- 85-78 71-150-29
Keyser Soze 84- 84-82 73- 79-98 87-101-62 98-123-29
Revival Fire is probably an airbagged and turbo-charged Recount.
Not sure about Keyser Soze. Maybe a bomber or bomber/scanner of
some sort.
- Scanner
Hazy Lazy 93-107-50 83-128-39 96-115-39 87-131-32
HSA x 112- 91-47 120- 95-35 106-110-34 98-123-29
Test S M1 128- 70-52 114- 85-51 136- 69-45 127- 89-34
KenshinX test13 127- 89-34 130- 83-37 124- 87-39 119- 86-45
Kenshin test 21 131- 77-42 127- 84-39 135- 76-39 144- 77-29
Eraser II 146- 72-32 141- 71-38 140- 74-36 111- 95-44
Hazy Lazy is one mean scanner. Look at those wins!!
Eraser II apparently is colouring core and triggering the
scanning version's fall to d-clear early. Somebody send in a
bomb dodger and tell the rest of us.
HSA x is a bit strange -- look at the difference in wins it gets
from the scanning version vs. the original. It too might be
colouring core, but for a HSA that sounds strange. In that case
it should be tricked into wiping the d-clear's stream quite
quickly, unless it finds the bomber body first (which could be
the case if it uses a step <= 10 or so).
- One-shot
G3 126- 98-26 135- 93-22
If it's anything like G2 (I haven't tested), we're most likely
hitting the clear while he's scanning. The djn stream in the
splitting version is getting us more wins.
> If you look at the nop hill, you'll see a warrior by
> me as the 21st warrior^_^ It uses the same b-scan
> idea, but in a "normal" mov },{ 3-line stone. To help
> VS papers, instead of only going to the d-clear, it
> also launches an imp.
OK, so do you have something like
??? {Y,{Y ; what's here?
mov X},{Y
jmz.b -2,{Y ; scan every fourth location
; go launch imp / d-clear.
[Snipped too much: is it a good idea to add redcode as
a...]
> language that i ahve mastered in an application for
> what is basically a nerds' summer camp? ^_^
Absolutely! See if you can get some of the other attendants to
give Core War a shot. Maybe organise a mini-tournament or
something. You'd have to be judge/organiser and so wouldn't be
allowed to enter, but you could give a few lectures on core war
strategy / history.
But then I've never been to a summer camp and have no idea what
it actually is, so add grains of salt etc. What is it people do
at summer camp anyway?
Joonas
Paul Khuong
> From: core...@koth.org [mailto:core...@koth.org]On Behalf Of M
> Joonas Pihlaja
> Sent: 27 novembre, 2001 11:09
> To: Multiple recipients of list COREWAR-L
>
>
>
> On Sun, 25 Nov 2001, Paul-V Khuong wrote:
>
> [snip the b-scanning version score]
> > DROPPED?
> >
> > How well did frenzy do before adding the b-scan VS
> > papers?
>
> Here are the results for all four versions. Speculation on the
> on-hill warriors below.
everything 8)
> frenzy v6 splitting airbag scan
> - Paper-likes
> Inky 28-170-52 37-145-68 39-151-60 16-217-17
> nPaper II 36-168-46 21-142-87 29-152-69 7-214-29
> The Phantom Men 8-105-137 4- 91-155 4- 85-161 6-116-128
>
> No surprises here, except the scarsity of paper on the hill.
> I'm not sure if Inky really is a paper though as on the hill it
> scores much too high for one.
Re Inky's type: Well, it's one weird warrior:reams HSA, but loses a lot VS
Lazy Hazy. So, it could be a very aggressive paper, bombing/coreclearing a
lot. However, Hazy Lazy also shows weird scores for a scanner, so...
[snip]
> Mostly the airbag converts losses into wins, sometimes ties.
> The b-scanning version clearly gets the most wins. A bit odd
> that these stone-fortified versions lose more heavily to
> Quicksilver and Qtest than the original
>
> - Bomber
> Fire and Ice II 64-141-45 73-158-19
> Behemot 102-129-19 101-106-43 76-137-37 87-145-18
>
> - Unknown
> Revival Fire 87- 81-82 42-107-101 87- 85-78 71-150-29
> Keyser Soze 84- 84-82 73- 79-98 87-101-62 98-123-29
>
> Revival Fire is probably an airbagged and turbo-charged Recount.
> Not sure about Keyser Soze. Maybe a bomber or bomber/scanner of
> some sort.
>
> - Scanner
> Hazy Lazy 93-107-50 83-128-39 96-115-39 87-131-32
> HSA x 112- 91-47 120- 95-35 106-110-34 98-123-29
> Test S M1 128- 70-52 114- 85-51 136- 69-45 127- 89-34
> KenshinX test13 127- 89-34 130- 83-37 124- 87-39 119- 86-45
> Kenshin test 21 131- 77-42 127- 84-39 135- 76-39 144- 77-29
> Eraser II 146- 72-32 141- 71-38 140- 74-36 111- 95-44
>
> Hazy Lazy is one mean scanner. Look at those wins!!
Hazy lazy probably is NOT a scanner
> Eraser II apparently is colouring core and triggering the
> scanning version's fall to d-clear early. Somebody send in a
> bomb dodger and tell the rest of us.
I'll do so in the weekend if you don't ahve the time to launch a test with
clisson ;-)
>
> > If you look at the nop hill, you'll see a warrior by
> > me as the 21st warrior^_^ It uses the same b-scan
> > idea, but in a "normal" mov },{ 3-line stone. To help
> > VS papers, instead of only going to the d-clear, it
> > also launches an imp.
>
> OK, so do you have something like
>
> ??? {Y,{Y ; what's here?
> mov X},{Y
> jmz.b -2,{Y ; scan every fourth location
> ; go launch imp / d-clear.
Erhm..Wait, this has no relation with the no-add step 4 stone ;-)
I think it's time i post it, anyway, so:
start mov @0, <1
mov {-50, <3999;3998 might be better..not sure
djn.f -2, @-2
end start
> [Snipped too much: is it a good idea to add redcode as
> a...]
> > language that i ahve mastered in an application for
> > what is basically a nerds' summer camp? ^_^
>
> Absolutely! See if you can get some of the other attendants to
> give Core War a shot. Maybe organise a mini-tournament or
> something. You'd have to be judge/organiser and so wouldn't be
> allowed to enter, but you could give a few lectures on core war
> strategy / history.
>
> But then I've never been to a summer camp and have no idea what
> it actually is, so add grains of salt etc. What is it people do
> at summer camp anyway?
You know, i have NO idea ^_^ It's gonna be my first time (thank god i was
never sent away to summer camp before), but i guess you could go to
www.shad.ca and take a look.
Finally, and most important, it IS possible to run the b-scan AND airbag ^_^
The problem:somewhat bigger footprint 8(
gate equ (top-4)
step equ 2936 ; 2930
ptr dat.f x, x+step
[something that point to a non a-zero cell]
bmb spl #z,0
[space]
top
add.f step, ptr ;3/4 gate ;-)
mov >ck, }ptr ; "
mov <ck, >ptr ; "
ck jmz.b top, {bmb
step spl #step*2-1, step*2-1
mov db, >gate
djn.f -1, >gate
db dat.f <whatever,-gate+1
Anyway, i leave you with that, and i'll go work on a core thrasher ->
spl/dat stone-resistant clear later.
M Joonas Pihlaja
[snip some code]
> the second matter: i executed airbag frenzy code; it seems to
> work properly, but there's one thing i just cant get along with.
> there're four paralleral (?), independent processes executing the
> code. in the main loop there's add #2*step, somewhere instruction.
> it seems that it is executed 4 times, so the bomb's destination is,
> well, altered.
Hmm... maybe I posted a buggy version. It's supposed to boot
five processes so that they execute the loop just as if there was
only one process.
spl 2 ;create 5 parallel processes
spl 2
spl 1, X
djn >-1, #5 ; boot 4 procs, last one falls thru to jmp
jmp X+1 ; boot final proc.
The djn line boots four processes to X, X+1, X+2, X+3 like this:
1 add
2 mov
3 mov
4 jmz
Then the loop executes once and a fifth process (left behind at
the jmp X+1 line) is booted to the first mov line:
4 add
1 5 mov
2 mov
3 jmz
When these execute in order you should get
add-mov-mov-jmz-add-mov-mov-jmz- ...
See also Paulsson's post of myBlur2.
Incidentally, Behemot uses a neat way of booting the processes:
It boots one extra line at the top of the warrior which is booted
to address X, and then feeds N+1 parallel processes to jmp
>ptr_to_X to get processes at X, X+1, ..., X+N. The instruction
at X+N is a branch to X+1, so after the processes have executed
once, we have the required scheduling for the processes. Also,
the instruction at X is only executed once, so it uses a mov {0,0
instruction to erase itself with a dat 0,0. Cool!
Joonas