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/board.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'src/board.c') diff --git a/src/board.c b/src/board.c index 5ad0d17..0c5f4df 100755 --- a/src/board.c +++ b/src/board.c @@ -168,6 +168,7 @@ Return value: "More pieces on board than accounted for in piece material", "Extra pieces on board that are not accounted for", "Fifty move counter is too high", + "bbPieces bitboard doesn't match piece list", }; ULONG u, v; COOR c; @@ -175,6 +176,7 @@ Return value: ULONG uPawnCount[2] = {0, 0}; ULONG uNonPawnMaterial[2] = {0, 0}; ULONG uNonPawnCount[2][7]; + BITBOARD bbPieces[2][8]; ULONG uSigmaNonPawnCount[2] = {0, 0}; ULONG uWhiteSqBishopCount[2] = {0, 0}; UINT64 u64Computed; @@ -183,6 +185,7 @@ Return value: ULONG uReason = (ULONG)-1; memset(uNonPawnCount, 0, sizeof(uNonPawnCount)); + memset(bbPieces, 0, sizeof(bbPieces)); u64Computed = ComputeSig(pos); if (pos->u64NonPawnSig != u64Computed) { @@ -305,6 +308,10 @@ Return value: goto end; } uNonPawnCount[u][PIECE_TYPE(p)]++; + if (!IS_KING(p)) + { + bbPieces[u][PIECE_TYPE(p)] |= COOR_TO_BB(c); + } uNonPawnMaterial[u] += PIECE_VALUE(p); if ((IS_BISHOP(p)) && (IS_WHITE_SQUARE_COOR(c))) @@ -348,6 +355,15 @@ Return value: uSigmaNonPawnCount[u] += pos->uNonPawnCount[u][v]; } + for (v = KNIGHT; v < KING; v++) + { + if (pos->bbPieces[u][v] != bbPieces[u][v]) + { + uReason = 21; + goto end; + } + } + // // Note: the 0th spot in the array is the sum of all non pawns // -- cgit v1.3