From 6c045be8a37a8eae1ea6aed250944e22af2335a1 Mon Sep 17 00:00:00 2001 From: Scott Gasch Date: Fri, 4 Sep 2026 01:27:59 -0700 Subject: Add bbPieces incremental piece-location bitboards (migration plan section 1) Board-representation migration, section 1: add POSITION.bbPieces[2][8] (per-color, per-piece-type location bitboards, indexed like the existing uNonPawnCount) as incrementally-maintained state, not a per-Eval()-call rebuild -- the structural fix for why the earlier attack-presence-bitboard work measured slower, not faster. - chess.h: bbPieces[2][8] field; extern decls for data.c's g_RookRayToEdge/g_BishopRayToEdge/g_KnightAttacksBB ray tables and their Initialize* functions (needed by the planned bitboard-backed GetAttacks/CountKingSafetyDefects primitive, section 3). - fen.c: populate bbPieces during piece placement; zeroing is free via the existing memset(p, 0, sizeof(POSITION)). - move.c: maintain bbPieces at all 6 non-pawn piece-movement functions (SlidePiece/LiftPiece/PlacePiece and their WithoutSigs siblings used by UnmakeMove) -- covers every move type: normal moves, captures, both-side castling, promotion with/without capture, en passant, and every undo. - board.c: extend VerifyPositionConsistency's existing non-pawn piece-list walk with a parallel bbPieces reconstruction-and-compare, rather than a separate bespoke check. - data.c/main.c: pulled ray-to-edge/knight-attack tables from stash (needed by section 3, not section 1 itself, but zero-risk to land now). Also, while verifying: COOR_TO_BB was a table lookup (BBSQUARE[idx]) measured ~5-7% slower than the pure-ALU shift already sitting unused in SLOWCOOR_TO_BB (whose "SLOW" name reflects a stale assumption about variable shifts never actually tested on this hardware). Switched COOR_TO_BB to the shift; fixed testbitboard.c's existing but broken (dead-code-eliminated, silently reporting "0 cycles/op") comparison benchmark for both while at it. Verified via gmake TEST=1 (including TestMakeUnmakeMove's explicit en-passant/promotion-with-capture/both-castling coverage) and debug_smoke_test.sh, both clean; release build clean and runs normally. Nothing reads bbPieces yet -- pure addition, zero behavioral risk. See board_representation/MIGRATION.md for the full plan. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01Jntky4yGUTyQVaGCXms4F2 --- src/chess.h | 43 ++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 42 insertions(+), 1 deletion(-) (limited to 'src/chess.h') diff --git a/src/chess.h b/src/chess.h index 5e1d4a5..1f874b9 100755 --- a/src/chess.h +++ b/src/chess.h @@ -647,6 +647,17 @@ typedef struct _POSITION // 0 and 1 are the sum, // 2..6 are per PIECE_TYPE + // Per-color, per-piece-type location bitboards -- "where are my + // knights/bishops/rooks/queens" -- indexed by PIECE_TYPE exactly + // like uNonPawnCount above (slots 0/1/PAWN/KING unused, same + // convention). Maintained incrementally in move.c at every site + // that already updates cNonPawns[]/uNonPawnCount[] (see + // board_representation/MIGRATION.md), not rebuilt -- O(1) per + // move. Pawns use pHash->bbPawnLocations[2] (pawn-hash-keyed, + // already established) instead; king is a single square + // (cNonPawns[color][0]), a bitboard adds nothing. + BITBOARD bbPieces[2][8]; + ULONG uWhiteSqBishopCount[2]; // num bishops on white squares SCORE iMaterialBalance[2]; // material balance @@ -1318,7 +1329,16 @@ _assert(CHAR *szFile, ULONG uLine); #define TO64(x) ((x) & 0x7) + ((0x7 - ((x)>>4)) << 3) #define COOR_TO_BIT_NUMBER(c) (((((c) & 0x70) >> 1) | ((c) & 0x7))) #define SLOWCOOR_TO_BB(c) (1ULL << COOR_TO_BIT_NUMBER(c)) -#define COOR_TO_BB(c) (BBSQUARE[COOR_TO_BIT_NUMBER(c)]) +// Was BBSQUARE[COOR_TO_BIT_NUMBER(c)] (an L1 load off a 64-entry table) +// -- measured (testbitboard.c's TestBitboards, fixed to use a volatile +// sink so the comparison isn't dead-code-eliminated) consistently ~5-7% +// slower than the pure-ALU shift on this hardware, so switched to match +// SLOWCOOR_TO_BB's expression. "SLOW" in that macro's name reflects a +// stale assumption (variable-count shifts being slow) that doesn't hold +// on modern silicon; BBSQUARE itself stays -- still used directly (not +// via this macro) where callers already have a bit index in hand and +// indexing it avoids recomputing COOR_TO_BIT_NUMBER redundantly. +#define COOR_TO_BB(c) (1ULL << COOR_TO_BIT_NUMBER(c)) #define SLOW_BIT_NUMBER_TO_COOR(b) ((((b) / 8) << 4) + ((b) & 7)) #define BIT_NUMBER_TO_COOR(b) ((((b) & 0xF8) << 1) | ((b) & 7)) @@ -2002,6 +2022,18 @@ extern BITBOARD BBPRECEEDING_RANKS[8][2]; extern BITBOARD BBADJACENT_FILES[8]; extern BITBOARD BBADJACENT_RANKS[9]; +// Ray-to-edge / knight-attack occupancy tables (data.c) -- built once +// at startup, consumed by ray-walk mobility code and (per +// board_representation/MIGRATION.md) the planned bbPieces-backed +// GetAttacks/CountKingSafetyDefects primitive. +extern BITBOARD g_RookRayToEdge[4][128]; +extern const int g_RookRayDeltas[4]; +extern const FLAG g_RookRayPositiveDir[4]; +extern BITBOARD g_BishopRayToEdge[4][128]; +extern const int g_BishopRayDeltas[4]; +extern const FLAG g_BishopRayPositiveDir[4]; +extern BITBOARD g_KnightAttacksBB[128]; + void InitializeWhiteSquaresTable(void); @@ -2014,6 +2046,15 @@ InitializeSwapTable(void); void InitializeDistanceTable(void); +void +InitializeRookRayTables(void); + +void +InitializeBishopRayTables(void); + +void +InitializeKnightAttackTables(void); + #ifdef DEBUG ULONG CheckVectorWithIndex(int i, ULONG uColor); #define CHECK_VECTOR_WITH_INDEX(i, color) \ -- cgit v1.3