Author: Gerd Isenberg
Date: 06:34:36 12/20/02
Go up one level in this thread
On December 20, 2002 at 08:11:41, Uri Blass wrote:
>On December 20, 2002 at 08:00:31, Gerd Isenberg wrote:
>
>>On December 20, 2002 at 07:26:12, Sune Fischer wrote:
>>
>>>On December 20, 2002 at 06:40:45, Gerd Isenberg wrote:
>>>
>>>>>Hi Uri,
>>>>>
>>>>>but a pseudo legal move generator is faster. You have to check if the king is in
>>>>>check only if you must evaluate a position.
>>>>>What is the advantage of a slower legal move generator?
>>>>>
>>>>>Andreas
>>>>
>>>>Hi Andreas,
>>>>
>>>>Not sure about that. Detecting pinned pieces is a rather fast and loopless task
>>>>with bitboards, specially with mmx-fill routines (unrolled for each of eight
>>>>directions). In the same run one could also detect possible covered checkers fo
>>>>the opposite side.
>>>>
>>>>eg. for one direction:
>>>>
>>>>// rooks or queens
>>>>if ( enemyRookMover & allRaysFromSquare[ownKingSquare])
>>>>{ // scan four staight directions
>>>> dirBB = getLeftAttacks(ownKingBB) & getRightAttacks(enemyRookMover);
>>>> pinned |= dirBB & ownPieces;
>>>> covered |= dirBB & enemyPieces;
>>>> ...
>>>>}
>>>>
>>>>Of course it's a bit overhead but the gained information is also usefull for
>>>>other things, as Uri already pointed out.
>>>>
>>>>If there are pinned pieces, one safes making/unmaking invalid moves and there is
>>>>no need (may be only for debug purposes) to look whether a king may be captured.
>>>>
>>>>Gerd
>>>
>>>The overhead of making/unmaking pinned pieces is extremely small.
>>>I count about 0.5-1.5% pinns, the make/unmake move rutines take maybe 20% (in my
>>>case) but I only need to do half a move to see if the move is legal, in total
>>>that's about 0.075% overhead because of illegal pinned moves!!
>>>
>>>I'm pretty sure there is _no way_ you can detect pinns faster and improve on
>>>this overhead.
>>
>>Hi Sune,
>>
>>I'm not sure, specially if we consider hammer or SSE2. I use dumb6fill for 2 or
>>3 directions simultaniously (8 mmx-registers). With SSE2 or hammer it can be
>>done for all 8-directions in parallel, with sliders and king in one 128-bit-xmm
>>register.
>
>Hi Gerd,
>I admit that I do not understand.
>
>hammer,SSE2,dumb6fill?
Hi Uri,
Hammer is AMD's coming 64-bit processor with 16 64-bit general purpose
registers, 8 64-bit MMX-registers and 16! 128-bit XMM-registers.
SSE2 - Streaming SIMD Extensions(2) - P4 and hammer
SIMD - Single Instruction Multiple Data, used by MMX, SSE, 3DNow! and SSE2
dumb6fill - my special term for dumb flood fill algorithms (no parallel prefix
algos like Kogge-Stone) to generate attacks in one direction for sliding pieces,
considering empty or occupied squares. In this special case it uses only
six-unrolled iterations, instead of seven for pure attack generation.
DumbNfill only needs two 64-bit registers for each direction where Kogge-Stone
needs four (Generator and Propagator has to be shifted).
>
>I also did not understand the code that you wrote in previous post and I post
>again in the end of this post but I guess that I need to change my all move
>generator to use it(something that I do not plan to do in the near future) so
>maybe it is better if I start to use bitboard only for pawn structure because I
>could understand better there and it seems that I do not need to change all my
>data structure to use it.
>
>Uri
>
>N.B:the relevant code that I did not understand:
>
>eg. for one direction:
>
>// rooks or queens
>if ( enemyRookMover & allRaysFromSquare[ownKingSquare])
>{ // scan four staight directions
> dirBB = getLeftAttacks(ownKingBB) & getRightAttacks(enemyRookMover);
> pinned |= dirBB & ownPieces;
> covered |= dirBB & enemyPieces;
> ...
>}
getRightAttacks and getLeftAttacks are rook rank attack generators here,
possibly implementated as dumb6fill or Kogge-Stone-Fill.
I have forgotten the "empty squares" parameter in the pseudo code above.
For getRightAttacks one can even use the x^(x-2) trick, instead of fill
iterations.
A pinned piece on a ray is in "between" it's own king and an enemy slider. If we
consider the king as a (meta)slider, the pinned piece is attacked by a slider
and defended by the meta sliding king in opposite direction:
[D]8/6k1/8/8/8/r3N2K/8/8 w - -
getRightAttacks(enemyRookMover) generates a bitboard with bits set at
b3,c3,d3,e3.
getLeftAttacks(ownKingBB) produces a bitboard with g3,f3,e3.
The intersections is e3. We have found a pinned piece (if white) or a potential
covered checker (if black).
If the intersections is empty we have neither a pinned piece or a covered
checker on this ray direction.
The leading condition safes some work, if there are no enemy rooks or queens on
kings file or rank.
I only use one bitboard to aggregate all pinned pieces. The pinned direction is
easily recoverable later, because there is only one own king.
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.