(idea) by m_turner Fri Sep 21 2001 at 19:39:42
The dwarf is one of the original programs for Core Wars that was described by A.K. Dewdney in Scientific American Computer Recreations starting in May 1984.

In ICWS-88 the code for a dwarf is: 

bomb  dat #0         | dat #0
start add #4,bomb    | add #4,-1
      mov bomb,@bomb | mov -2,@-2
      jmp start      | jmp -2
      end start      |

The dwarf is one of the simplest members of the 'stone' class of programs (part of the rock, paper, scissors analogy).

Line by line:

dat #0
The 'dat' statement in Redcode is short for 'data' and is an un-executable opcode (a program will 'die' when trying to run it). The dwarf only needs one 'variable' (called 'bomb') to work and thus this memory location has been given the symbolic name 'bomb' for easier reading.

add #4,bomb
Most instructions are made up of two parts called the 'A' field and the 'B' field. Here, the A-field has the literal (designated by '#') value '4', and the B-field refers to the memory location 'bomb' (which later gets reinterpreted as '-1'.

The instruction here is simply: add four to the B field of the the memory location 'bomb' (which is -1 from the current location).

mov bomb,@bomb
The most difficult to understand, and most useful concept of addressing in Redcode is the indirect which is specified with the '@'. Here, the value of the B-field of the location specified is an offset for the instruction and is also used as the 'source' for computing where the instruction operates.

The 'mov' command in this form takes the memory specified in the A-field (the dat statement at 'bomb') and copies it to the memory location some distance down (from the B-field of the bomb). If this happens to fall in the memory used by another program that is later run, that program dies, and the dwarf wins.

Something to note here is that the dwarf is only 4 memory units long and thus neatly bombs clear of itself as it loops around the core.

jmp start
After one bomb pass, the jmp sends the program back to the memory named 'start' (two memory cells backwards) and begins another iteration of the infinite loop that is the dwarf.

end start
This isn't a "real" instruction in the Redcode language but rather is a instruction to the MARS simulator to tell it where the program begins and ends. The program begins running at the 'start' location rather than the 'dat #0' which would kill it even before it ran the first instruction. Furthermore, the end tells the Redcode assembler to stop there and nothing after that point gets assembled.

With ICWS-94 the code for a dwarf becomes slightly more clear - many of the operations in ICWS-88 change how they behave depending on the addressing forms of the instructions. add #4,foo will add 4 to the B-field of the instruction foo while add foo,bar will add the A-field of foo to the A-field of bar, and the B-field of foo to the B-field of Bar (storing the result in bar). This is only one example of the confusion that may occur in trying to read and understand the source.

An ICWS-94 dwarf is: 

ORG start
bomb    DAT.F  0,0
start   MOV.I  bomb,3
        ADD.AB #3044,start
        JMP.B  start
Here, each instruction has a modifier which tells how the instruction behaves. MOV.I has the entire Instruction as what it does rather than just one field. The ADD.AB has the A-field of the instruction read and the B field written to (note that this form of the dwarf doesn't go right in a line but scatters its shots around a bit and actually modifies the MOV instruction instead of using indirect addressing).

Experimental forms of Core wars that place limitations on the maximum distance that can be read from or written to have made the solo dwarf a warrior of days past. However, one can often find parts of a dwarf in other programs.

I like it!