Talk:Board representation

From Wikipedia, the free encyclopedia

I don't buy the foll: By use of a jump table, adding the piece value to the program counter can go directly to the code to generate moves for this type of piece on this square. Although the program is longer than for a conventional move generation methods, no checks for the edge of the board are required, and no moves off the board are considered, increasing move generation speed. Modern CPU caches allow code relevant to the current position to be cached, giving move generation times of a few clock cycles per position. —The preceding unsigned comment was added by [[User:{{{1}}}|{{{1}}}]] ([[User talk:{{{1}}}|talk]] • [[Special:Contributions/{{{1}}}|contribs]]).

What don't you buy exactly? Each piece is checked separately with code like this (on the ARM):

• ANDS R0, Rmask, Rn, LSL #4*(column-1)
• BNE piece_found_on_square_row_column

(this is written out 64 times, once for each square, with early exit tests for Rn=0)

Rmask = 15<<28

n = row number (using registers R1 to R8)

column is in the range 1-8.

The destination for the BNE is:

.piece_in_R0_found_on_square_row_column

ADD table, base, #row*8+column

LDR PC, [table, R0, LSR #26]

The destination branch caused by the final LDR is to a piece of code which knows which piece has been found (which is also in R0), whether it is black or white (sign bit from ANDS) and what square it is (table offset is to this square). All it has to do is generate the moves for a known piece in a known position. As the board is stored in registers, this only takes a few cycles too, but that's another story. Stephen B Streater 17:39, 19 May 2006 (UTC)