Carbonite by Ian Sutton

back to the home page

You are here: maincorewarbook of stones → Carbonite

Table of contents

  1. Introduction
  2. How it works

Introduction

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

^top

How it works

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.

^top

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?