Anti-imp mov bombs

G

Guest

Guest
Archived from groups: rec.games.corewar (More info?)

I was just checking out these bombs for a warrior I'm working on.
Took me a while to see how they work, but got it eventually (Thanks,
Corewin! I was able to just set up an imp spiral then splice a bomb
as first inst.)
A few things about them:
When the bombs get to the end of the spiral, the damage gets a little
wonky (since the bomb uses the next instrs.' B-field to attack, when
it's just normal core weird things happen. What just does happen at
the end of the spiral? Do the processes just start sliding down and
eventually fall off?
secondly, I'm looking at the mov.i #1,<1 form. Are there any other
forms? (Not counting mov.i #1,{1 for a-imps, since that's the only
difference, right?)
Lastly, these are generally delivered by paper, right? Is there a
"standard" or "accepted" way to bomb them?
 
Archived from groups: rec.games.corewar (More info?)

> When the bombs get to the end of the spiral, the damage gets a little
> wonky (since the bomb uses the next instrs.' B-field to attack, when
> it's just normal core weird things happen. What just does happen at
> the end of the spiral? Do the processes just start sliding down and
> eventually fall off?

Yes. mov.i #1, <1 can never write a deadly instruction (DAT) anywhere
(because of the #, it can only copy itself), so it has to rely on the spiral
running into DAT instructions that are already in empty core. The decrement
ensures that it doesn't overwrite those DAT instructions.

> secondly, I'm looking at the mov.i #1,<1 form. Are there any other
> forms? (Not counting mov.i #1,{1 for a-imps, since that's the only
> difference, right?)

I don't know of any radically different bombs (other than the usually less
effective dat >2667, >5334 family), but the a-field doesn't need to be 1,
sometimes this helps to separate bombs for better colouring (but less
effective against djn-streams etc. of course).

> Lastly, these are generally delivered by paper, right? Is there a
> "standard" or "accepted" way to bomb them?

The two most common ways are:

1. Using a mov instruction to lay down a carpet of bombs like so:

spl 1
spl 1
....
spl @0, <y
mov }-1, >-1
....
mov bomb, }x ; <-- this line drops the bomb
....
bomb mov.i #1, <1

This line is executed multiple times by the paper's processes, each time
placing a bomb and incrementing a pointer, so the next bomb is placed in a
different location.

2. Executing the bomb instruction itself within the paper like so:

spl 1
spl 1
....
spl @0, <y
mov }-1, >-1
....
mov.i #1, <1 ; <-- this line drops the bomb
nop 0, x ; <-- here's the pointer
....

The b-field of the next line holds the target pointer (x). The pointer is
decremented each time the bomb is executed so again we get a carpet of mov
bombs. The next line need not be the one shown here, it just needs to have
a target in its b-field. It could even be used to drop more bombs like so:

bomb mov.i #1, <1
mov bomb, {x

or something along those lines.

nPaper II is a good example of a paper that uses both of these techniques
with a-imp bombs.

-jrm
 
Archived from groups: rec.games.corewar (More info?)

John Morahan wrote:

>> When the bombs get to the end of the spiral, the damage gets a little
>> wonky (since the bomb uses the next instrs.' B-field to attack, when
>> it's just normal core weird things happen. What just does happen at
>> the end of the spiral? Do the processes just start sliding down and
>> eventually fall off?
>
> Yes. mov.i #1, <1 can never write a deadly instruction (DAT) anywhere
> (because of the #, it can only copy itself), so it has to rely on the
> spiral
> running into DAT instructions that are already in empty core. The
> decrement ensures that it doesn't overwrite those DAT instructions.
>
>> secondly, I'm looking at the mov.i #1,<1 form. Are there any other
>> forms? (Not counting mov.i #1,{1 for a-imps, since that's the only
>> difference, right?)
>
> I don't know of any radically different bombs (other than the usually less
> effective dat >2667, >5334 family), but the a-field doesn't need to be 1,
> sometimes this helps to separate bombs for better colouring (but less
> effective against djn-streams etc. of course).
>
>> Lastly, these are generally delivered by paper, right? Is there a
>> "standard" or "accepted" way to bomb them?
>
> The two most common ways are:
>
> 1. Using a mov instruction to lay down a carpet of bombs like so:
>
> spl 1
> spl 1
> ...
> spl @0, <y
> mov }-1, >-1
> ...
> mov bomb, }x ; <-- this line drops the bomb
> ...
> bomb mov.i #1, <1
>
> This line is executed multiple times by the paper's processes, each time
> placing a bomb and incrementing a pointer, so the next bomb is placed in a
> different location.
>
> 2. Executing the bomb instruction itself within the paper like so:
>
> spl 1
> spl 1
> ...
> spl @0, <y
> mov }-1, >-1
> ...
> mov.i #1, <1 ; <-- this line drops the bomb
> nop 0, x ; <-- here's the pointer
> ...
>
> The b-field of the next line holds the target pointer (x). The pointer is
> decremented each time the bomb is executed so again we get a carpet of mov
> bombs. The next line need not be the one shown here, it just needs to
> have
> a target in its b-field. It could even be used to drop more bombs like
> so:
>
> bomb mov.i #1, <1
> mov bomb, {x
>
> or something along those lines.
>
> nPaper II is a good example of a paper that uses both of these techniques
> with a-imp bombs.
>
> -jrm

The biggest Adventage of this two Bombs is the fact that they throw
themselve. So thing like this are possible and very aggressive against
Imp's and Paper's

b mov.i #1, <1
djn.b loop, #dist

You can also use Anit A and B imp variants, but the anti-B-imp Bomb will
lose some of its anti-djn-stream Power.

b mov.i #1, {1
mov.i #dist1, <1
djn.b b, #dist2

But another idea i had some time Ago is an Anti-A-Imp Bomb using the
MOD-Instruction.

A-Imp must have the zero in their B-field, so with Poitner you can design a
4c Anti-A-imp Bomb. When using this as bomb

mod.f {2667,{2668

One Spiralarm of the Imp willbe decrement. Additional the A-field will give
2667 mod 2667 = 0, also a zero a field, and the mod-executing sprialarm
will die because of the b-field "division by zero"

Viola...2 Dectrements, 1 zero A-field and a Procees will die.

Should do fine against against 7 armend or higher, but even against
3pointers..



--
Parlez vous Redcode?
 
Archived from groups: rec.games.corewar (More info?)

Sascha Zapf <nc-zapfsa@netcologne.de> wrote in message news:<c9kl1k$8tt$1@newsreader2.netcologne.de>...
> John Morahan wrote:
....

> > bomb mov.i #1, <1
> > mov bomb, {x

Erm... that second mov would be bombing the same location, wouldn't
it?

> The biggest Adventage of this two Bombs is the fact that they throw
> themselve. So thing like this are possible and very aggressive against
> Imp's and Paper's
>
> b mov.i #1, <1
> djn.b loop, #dist

The most usual one in coreclear paper

> But another idea i had some time Ago is an Anti-A-Imp Bomb using the
> MOD-Instruction.
>
> A-Imp must have the zero in their B-field, so with Poitner you can design a
> 4c Anti-A-imp Bomb. When using this as bomb
>
> mod.f {2667,{2668
>
> One Spiralarm of the Imp willbe decrement. Additional the A-field will give
> 2667 mod 2667 = 0, also a zero a field, and the mod-executing sprialarm
> will die because of the b-field "division by zero"
>
> Viola...2 Dectrements, 1 zero A-field and a Procees will die.
>
> Should do fine against against 7 armend or higher, but even against
> 3pointers..

Yeah, great idea!

what about this?
div.b <2667,<5334 ;or mod/div .f
The process executing div would die, damaging the two next points of
the current ring/spiral. Also, having their b-fields decremented, they
would copy its damaged instruction backwards to the next point, (mov.i
#2667,*-1), stopping its advance and, hopefuly, dieing.
Well, don't know if it works, haven't tested it.

Other unusual bombs like mov.i #1,>1, mov.i #0,>2667, mov.i
>-2667,>2667 or mov.i >2667,>5334, and others could be effective
sometimes, but most of them are specific for a certain number of
points and B-imps. I like mov.i #1,<1 and dats the best.
You can find interesting the Mini-Challenge#3, where the goal was to
kill an imp-spiral dropping only one bomb.
www.estadium.ya.com/neogryzor/corewars.htm
 
Archived from groups: rec.games.corewar (More info?)

> > > bomb mov.i #1, <1
> > > mov bomb, {x
>
> Erm... that second mov would be bombing the same location, wouldn't
> it?
>
Oops... that should be
mov.i #x, <1
mov bomb, {y
-jrm
 
Archived from groups: rec.games.corewar (More info?)

"John Morahan" <wunderland@eircom.net> wrote in message news:<Smiwc.1456$Z14.1511@news.indigo.ie>...
> > > > bomb mov.i #1, <1
> > > > mov bomb, {x
> >
> > Erm... that second mov would be bombing the same location, wouldn't
> > it?
> >
> Oops... that should be
> mov.i #x, <1
> mov bomb, {y
> -jrm

Hmm...ya. This loop is somewhat faster, cool. I'm going to try
throwing that into my paper instead of the 2 line version...in fact,
my optimizer is churning through several thousand sets of constants as
we speak.
But what I'm wondering...is it possible to adapt
mov.i #x,<1
mov bomb,{y
djn.f -2,<-1
to work with anti a-imp bombs (mov.i #1,{1)?
As written, it won't work obviously....
I saw nPaper uses
mov.i #1,{1
mov x, <y
but I want it to work in a loop. Can that be done?
 
Archived from groups: rec.games.corewar (More info?)

Hi

> But what I'm wondering...is it possible to adapt
> mov.i #x,<1
> mov bomb,{y
> djn.f -2,<-1
> to work with anti a-imp bombs (mov.i #1,{1)?
> As written, it won't work obviously....
> I saw nPaper uses
> mov.i #1,{1
> mov x, <y
> but I want it to work in a loop. Can that be done?

Yes. A loop containing anti a-imp AND anti b-imp bombs is used in
Wipe Uncle:

mov.i #1, {1
mov.i #bStep1, <1
djn.f -2, <bStep2

As it was recently found in bvowk's evolved anti-imp clears
the following should work significantly better:

mov.i #1, {1
mov.i #bStep1, <1
djn.b -2, #bStep2