Author: Tony Werten
Date: 23:05:08 09/20/04
Go up one level in this thread
On September 20, 2004 at 17:19:43, Bas Hamstra wrote:
>On September 20, 2004 at 05:14:21, Tony Werten wrote:
>
>>On September 20, 2004 at 04:53:46, Gerd Isenberg wrote:
>>
>>>On September 20, 2004 at 03:16:41, Tony Werten wrote:
>>>
>>>>On September 20, 2004 at 03:06:54, Gerd Isenberg wrote:
>>>>
>>>>>On September 20, 2004 at 02:23:59, Tony Werten wrote:
>>>>>
>>>>>>It isn't doing things parallel like the sliders with Kogge Stone, but at least
>>>>>>it doesn't use those big arrays.
>>>>>>
>>>>>>const KNIGHTC3 // all attacks of a knight on square C3
>>>>>>
>>>>>>pieces=BITBOARD[stm][KNIGHT];
>>>>>>attacks=0;
>>>>>>while (pieces)
>>>>>>{
>>>>>> sq=bitscan_first_and_reset(pieces);
>>>>>> File(sq)>2 ? mask=NOT_FILE_AB:mask=NOT_FILE_GH;
>>>>>> if (sq>C3) attacks=(KNIGHTC3>>(sq-C3)) & mask;
>>>>> <<
>>>>
>>>>correct (when A1=0 and H8=63)
>>>
>>>Sorry for my nitpicking,
>>>but with other mapping sq>C3 doesn't make much sense ;-)
>>
>>No problem. I wrote it down here, before I tested it. It's one of those easily
>>made errors with bitboards.
>>
>>>
>>>>
>>>>>> else attacks|=(KNIGHTC3<<(C3-sq)) & mask;
>>>>> ?? >>
>>>>
>>>>correct. I'm mixing some things here. The |= is for all knight attacks, mostly
>>>>you only want =
>>>>
>>>>>>}
>>>>>>
>>>>>>For king is the same but on square B2. Since most of the time sq>C3 (or B2)
>>>>>>branch prediction should be OK.
>>>>>
>>>>>Even more for sq>=C3 (or b2).
>>>>
>>>>Yeah, that might do some 0.1 % better even :)
>>>
>>>I would say it goes under in some random noise.
>>>Probably same for direct lookup with a bitboard[64] array.
>>
>>Well, it does free 1KB of cache :) My main point was to not use any lookuptables
>>at all, because I didn't like it( now that's a good reason)
>>
>>>What about different routines for white and black knights/kings?
>>>Using f6(g7) for white and c3(b2) for black. During opening and middlegame
>>>branch prediction works even better ;-)
>>
>>Besides lookuptables, I do not want to have black/white code either. ( With the
>>same good reason ) Unfortunately, those nasty pawns keep insisting on walking in
>>different directions.
>>
>>Tony
>
>I have different code for white and black, but I have *never* liked it. It's
>ugly and I will eventually get rid of it.
Pawn are still a problem I think, since the solution is not much nicer:
( assuming the compiler understands the a negative shl is a shr )
BLACK=0
WHITE=1
int LeftSideAttack={-9,7};
int RightSideAttack={-7,9};
pieces=Pieces[stm][pawn];
pawnattacks=(pieces & NOT_FILE_A)<<LeftSideAttack[stm]
|(pieces & NOT_FILE_H)<<RightSideAttack[stm])
AttackedPieces=pawnattacks & Pieces[stm^1][all]
Hmm, actually writing it down, makes it less messier than it was in my head.
That is, if the first assumption is met.
Tony
>
>Bas.
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.