Author: Gerd Isenberg
Date: 11:44:41 02/04/04
Go up one level in this thread
On February 04, 2004 at 13:26:51, Russell Reagan wrote:
>On February 04, 2004 at 10:06:11, Daniel Clausen wrote:
>
>>I'm not quite sure what you mean with "byte square into each bitboard", but I
>>try to answer anyhow. :)
>>
>>A move in my case contains not only information about the from- and the
>>to-square, but also about the type of piece which moves. (and other things).
>>What I do is basically this:
>>
>>makeWhiteMove(Board* b, Move mv)
>>{
>> [...]
>>
>> switch(mv.pieceType)
>> {
>> case KNIGHT: update white_knights;
>> update white_pieces;
>> [...]
>> break;
>>
>> case ROOK: update white_rooks;
>> update white_pieces;
>> [...]
>> break;
>>
>> [...]
>>
>> }
>>
>> [...]
>>}
>>
>>Alternativly, if your move type doesn't contain the piecetype information, you
>>have could look in the pieces[64] array of your board structure. If you also
>>don't have that, then you really have a problem, because then you have to check
>>all bitboards and see in which one the bit is set for your from-square.
>>
>>HTH
>>
>>Sargon
>
>I initially tried it another way, using an array lookup. So for instance, where
>you do something like this:
>
>switch (piece_type)
>{
> case white_pawn: UpdateWhitePawnBitboard(from_square, to_square); break;
> case white_knight: UpdateWhiteKnightBitboard(from_square, to_square); break;
> case white_bishop: UpdateWhiteBishopBitboard(from_square, to_square); break;
> // etc...
>}
>
>I would do something like this:
>
>Bitboard pieces[12]; // a bitboard for each piece type
>
>UpdateBitboard(pieces[piece_type], from_square, to_square);
>
>I'm not sure which is better or faster. My hope is that when I do something like
>pieces[white_pawn] that since white_pawn is a constant, it will know the address
>of that bitboard at compile time, so it will be just the same as if you had a
>seperate bitboard for each piece (white_pawn_bitboard, white_bishop_bitboard,
>etc.).
>
I would prefere that too. Currently i switch with type of move (reversable,
capture, single/double pawn push, ep, promotions, castles) but index the piece
bitboards. Switch (piece) seems not necessary for me, and probably difficult to
predict.
What about following board representation ;-)
Bitboard own;
Bitboard p0;
Bitboard p1;
Bitboard p2;
free pawn bishop knight rook king queen
p2 0 0 0 0 1 1 1
p1 0 0 1 1 0 0 1
p0 0 1 0 1 0 1 0
in make/unmake-move some branchless sse2 stuff:
own:p0 ^= movePropLookup[moveIdx].own:p0
p1:p2 ^= movePropLookup[moveIdx].p1:p2
hash ^= movePropLookup[moveIdx].hash[side];
// castle states, move50 counter ...
Piece and occupied bitboards (no rotated) may easily computed a bit later with a
handfull sse2 instructions, if the xmm-pipe/units are a bit more idle ;-)
Ok, the move index range is rather huge: ~4000 unique moves (coordinates as well
as moving piece) multiplied with six (the number of possible target states, free
squares and capturing all kind of pieces).
24,000 * sizeof(6 bitboards) ond some more, let say 64 byte (a cacheline) per
unique move. Hmm, maybe a bit too huge ...
Gerd
>I've even gone so far as to make the values of white and black and the piece
>types such that they will allow me to do this:
>
>pieces[white|knight];
>
>That way I avoid a two-dimensional array lookup, and I can still write the code
>to be color blind. So for instance, when I want to generate moves for the
>knights, I just do:
>
>Bitboard knights = pieces[side_to_move|knight];
>// ...
>
>Anyway, that's just another way to approach it. The program I wrote that did
>this and used rotated bitboards was slightly faster than Crafty at node counting
>(perft), for whatever that's worth.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.