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.01 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.