Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: flood fill attack bitboards, continuation

Author: Gerd Isenberg

Date: 12:56:57 09/21/02

Go up one level in this thread


On September 21, 2002 at 15:12:17, Gerd Isenberg wrote:

>On September 21, 2002 at 13:11:30, Sean Mintz wrote:
>
>>Could your functions be placed in to some popular bitboard engines (perhaps
>>Crafty or Beowulf?) so that we could measure their performance?
>
>Should be possible, in principle. You need msc++ with processor pack installed
>or intel c++.
>
>You have to consider the mapping of squares to the bits of the bitboard,
>But due to symmectric only the comments may be wrong (except pawns).
>
>I'll try it with IsiChess, where i actually have prototypes like this:
>
>BitBoard CNode::RookAttacks  (UINT sq) const;
>
>The three neccesary instructions that pass a bitboard to edx:eax specially the
>two "movd reg32, mmx" are rather expensive due to amd vector path instructions
>(70 secs indstead of the 57 secs in the loop, no idea with intel PIV).
>
>But in the first step i will use them:
>
>BitBoard CNode::RookAttacks  (UINT sq) const
>{
>#ifdef USE_MMXFILL
>  __asm
>  {
>     movd   mm2, [sq]
>     movq   mm1, [one]
>     psllq  mm1, mm2
>     mov    ebx, [this]
>     movq   mm6, [ebx].m_EmptySquares
>     ... do the getRookAttacksMMX() code
>     movd   eax, mm0     ;  lowboard to eax
>     punpckhdq	mm0, mm0 ; highboard to lowboard
>     movd   edx, mm0     ; highboard to edx
>
>  }
>#else
>  // none mmx code
>#endif
>}
>
>special mmx-version should conditionally replace something like this:
>
>BitBoard CNode::GetAttackedBy(UINT sq) const
>{
>	return
>	     (RookAttacks(sq)   & RookMover())
>	   | (BishopAttacks(sq) & BishopMover())
>	   | (BPawnAttacks(sq)  & GetWPawnBB())
>	   | (WPawnAttacks(sq)  & GetBPawnBB())
>	   | (KnightAttacks(sq) & GetKnightBB())
>	   | (KingAttacks(sq)   & GetKingBB())
>	   ;
>}
>
>The next step might be to write some polymorphs which avoid the expensive
>"movds". But that implies some rearrangement in the source code, which i like to
>avoid. A better idea might be to wait for 64bit hammer and a (hopefully) fast
>"movq  reg64, mmxReg".
>
>Final step might be to gain something from the (may be main) feature, getting
>attacks for multiple pieces of one kind simultaniously. But thats requires
>really source rearrangements.
>
>To generate king moves, it's usefull to have a bitboard with all attacks from
>all opposite colored pieces. This is quite easy to implement, with the same
>effort than getting all pieces attacking one square. Instead of calling
>"GetAttackedBy" for adjacent king squares, only call the new routine
>"getAllAttacked(int side)" once.
>
>I think in eval there is also some potential...
>
>Looking for a set of squares "reachable" in two (ore more) moves might be an
>interesing task here and there...
>
An other idea is to use SSE2 extensions (PIV and hammer, similar instructions)
with 128 bit xmm-registers to generate seperate attack sets for two rooks,
bishops, queens, or two separate attack sets for same black and white piece in
parallel.

>cheers,
>Gerd



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.