You are here: main → corewar → book of stones → Carbonite
Carbonite is <0.33 stone which covers the core with real dat bombs and after a bombing raid it turns into a coreclear (the source given below is a slight hack of original Sutton's Carbonite):
;redcode-94nop
;name Carbonite
;author Ian Sutton
;assert CORESIZE==8000
stone spl #0 , <-1151+3
mov 197 , inc-(197*3500)
inc add.ab {0 , }0
djn.f -2 , <-1151
bomb dat >-1 , >1
boot mov -2 , @bptr
mov {boot , <bptr
mov {boot , <bptr
bptr mov bomb , *1000
mov {boot , <bptr
jmp.b @bptr , 0
end boot
When booted, Carbonite looks like this:
1005 SPL.B # 0, < -1148 (1)
1006 MOV.I $ 197, $ -1499
1007 ADD.AB { 0, } 0
1008 DJN.F $ -2, < -1151
...
1203 DAT.F > -1, > 1
Process (1) splits another process (2):
1005 SPL.B # 0, < -1148 (2)
1006 MOV.I $ 197, $ -1499 (1)
1007 ADD.AB { 0, } 0
1008 DJN.F $ -2, < -1151
...
1203 DAT.F > -1, > 1
Process (2) splits another process while (1) throws a DAT bomb -1499 cells behind MOV line:
7507 DAT.F > -1, > 1 ; bomb thrown by (1)
...
1005 SPL.B # 0, < -1148 (3)
1006 MOV.I $ 197, $ -1499 (2)
1007 ADD.AB { 0, } 0 (1)
1008 DJN.F $ -2, < -1151
...
1203 DAT.F > -1, > 1
Now the process (1) modifies cell no. 1006. This is a bit complicated so let's have a closer look how it really works:
1006 MOV.I $ 197, $ -1499
1007 ADD.AB { 0, } 0 (1)
The general idea of ADD.AB {0, }0 is that it works
like ADD.AB -1, -1.
After "first half" of the cycle, A-field of 1007th cell is
decremented: the instruction looks like ADD.AB {-1,
}0, but acts like ADD.AB $-1, *0 (we don't care
about postincrement addressing mode in B-field of 1007th cell,
let's assume for a while that there's * instead of
}):
1006 MOV.I $ 197, $ -1499 1007 ADD.AB $ -1, * 0
The .AB modifier means that the ADD
takes A-value from 1006th cell (197) and adds it to the cell that
is pointed by the B-field (via indirection it points 1006th cell).
As the output one receives
1006 MOV.I $ 197, $ -1302
Now, let's get back to proper addressing modes in 1007th line
1007 ADD.AB { -1, } 0 (1)
The "second half" of a cycle is executed: the A-field is incremented and the instruction looks as at the beginning of a cycle:
1007 ADD.AB { 0, } 0
1008 DJN.F $ -2, < -1151 (1)
The warrior looks now like:
1005 SPL.B # 0, < -1148 (3)
1006 MOV.I $ 197, $ -1302 (2)
1007 ADD.AB { 0, } 0
1008 DJN.F $ -2, < -1151 (1)
The second process throws a DAT bomb, third one
splits another process.
After 10644 cycles the stone itself had started and after it had
generated 146 processes the 1007th cell is hit by
DAT.
1005 SPL.B # 0, < -1148
1006 MOV.I $ 197, $ 1
1007 ADD.AB { 0, } 0
1008 DJN.F $ -2, < -1151
Process in line 1006 executes and after next cycle warrior looks like:
1005 SPL.B # 0, < -1148 (1 process in this address) 1006 MOV.I $ 197, $ 1 (48 processes) 1007 DAT.F > -1, > 1 (49) 1008 DJN.F $ -2, < -1151 (48)
Now the warrior (1006th line, namely) works as a simple
coreclear. Notice that the process executing DAT >-1, >
1 instruction modifies the B-field of 1006th cell:
1006 MOV.I $ 197, $ 1 1007 DAT.F > -1, > 1
which outputs
1006 MOV.I $ 197, $ 2 1007 DAT.F > -1, > 1
and the B-field is incremented thus clear pointer is shifted. Since the coreclear stream goes forward (and there's no trick used) Carbonite suicides after next 23898 cycles.
Carbonite's stone was designed to kill clears; a classic d-clear may be an example
;redcode-94nop
;assert 1
;name d-clear
gate dat 0,100
dat 0,0
clear spl #0,#0
mov bomb,>gate
djn.f -1,>gate
bomb dat <2667,15
end clear
The DAT >-1,>1 bomb is very effective against
such a clear. Provided the clear code is loaded into core as
below:
00000 DAT.F $ 0, $ 100 ; some empty core 00011 SPL.B # 0, # 0 00012 MOV.I $ 2, > -12 00013 DJN.F $ -1, > -13 00014 DAT.F < 2667, $ 15
If DAT >-1,>1 hits 0th cell (the gate) the
clear would overwrite its code with DAT.F <2667, 15
executing itself, for the clear pointer, situated in B-field, would
be equal 1. If bomb hits SPL instruction clear is
wounded but, in general, it runs (maybe slowed down a bit). Hitting
MOV lines disables the clear (does not kill it,
however). When the clear is bombed over DJN it looks
as below:
00000 DAT.F $ 0, $ 100 ; some empty core 00011 SPL.B # 0, # 0 00012 MOV.I $ 2, > -12 00013 DAT.F > -1, > 1 00014 DAT.F < 2667, $ 15
13th line constantly alters preceding line and makes it point to
SPL and MOV itself, eventualy. Finally,
when the bomb itself is hit, clear finilizes its run and then is
disabled, with SPL #0, #0 being the only remaining
line.
Now, do you want to proceed to main or corewar section of grabun.com? Or maybe you still want to browse through corewar book chapters?