From 2ce3570dc6aa67f82dd6f02fc4e518be3e33aabf Mon Sep 17 00:00:00 2001 From: Scott Gasch Date: Sat, 5 Sep 2026 00:19:59 -0700 Subject: Maintain pos->bbOccupied incrementally, dedupe its two from-scratch builders chess.h: add POSITION::bbOccupied (full-board occupancy, both colors, every piece including kings), maintained incrementally alongside bbPieces/bbPawns rather than rebuilt on demand -- resolves the open question in EVAL.md section 0 about whether this is worth doing given both generate.c and the planned eval.c mobility rewrite need it. move.c: SlidePiece/SlidePawn/LiftPiece/PlacePiece and their WithoutSigs variants now maintain bbOccupied at the same choke points that already maintain bbPieces/bbPawns -- unconditionally, since occupancy doesn't care about piece type or color. Kings only ever move through SlidePiece/SlidePieceWithoutSigs (never Lift/Place), so no separate king-specific update site was needed. fen.c: populate bbOccupied when parsing a FEN. board.c: VerifyPositionConsistency cross-checks pos->bbOccupied against a from-scratch rebuild, same pattern already used for bbPieces/bbPawns. generate.c/movesup.c/see.c: replace call sites that rebuilt full occupancy via _BuildFullOccupiedBB/_BuildOccupiedBB with direct reads of pos->bbOccupied; delete see.c's _BuildOccupiedBB, which was a byte-for-byte duplicate of generate.c's _BuildFullOccupiedBB (kept only as the from-scratch ground truth for the new consistency check and testgenerate.c's benchmark harness). testsup.c: GenerateRandomLegalPosition builds POSITIONs by poking rgSquare/bbPieces/bbPawns directly, bypassing both move.c and fen.c -- a third construction path the above missed. It never set bbOccupied, so the new VerifyPositionConsistency check failed on every generated position, and since generation retries until a position verifies, the self-test suite spun forever (100% CPU, no progress) instead of crashing outright. Fixed by setting bbOccupied at all four placement sites (both kings, pawn, non-pawn piece). Full self-test suite and precommit_check.sh verified clean afterward. board_representation/EVAL.md: record the bbOccupied decision and rationale, resolving section 0's open question. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01P6g6iF6mD1Hau6nCZCzwYj --- src/board.c | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'src/board.c') diff --git a/src/board.c b/src/board.c index 0b195be..814b045 100755 --- a/src/board.c +++ b/src/board.c @@ -170,6 +170,7 @@ Return value: "Fifty move counter is too high", "bbPieces bitboard doesn't match piece list", "bbPawns bitboard doesn't match pawn list", + "bbOccupied bitboard doesn't match piece list", }; ULONG u, v; COOR c; @@ -179,6 +180,7 @@ Return value: ULONG uNonPawnCount[2][7]; BITBOARD bbPieces[2][8]; BITBOARD bbPawns[2]; + BITBOARD bbOccupied = 0; ULONG uSigmaNonPawnCount[2] = {0, 0}; ULONG uWhiteSqBishopCount[2] = {0, 0}; UINT64 u64Computed; @@ -272,6 +274,7 @@ Return value: uPawnMaterial[u] += VALUE_PAWN; uPawnCount[u]++; bbPawns[u] |= COOR_TO_BB(c); + bbOccupied |= COOR_TO_BB(c); } } @@ -316,6 +319,7 @@ Return value: { bbPieces[u][PIECE_TYPE(p)] |= COOR_TO_BB(c); } + bbOccupied |= COOR_TO_BB(c); uNonPawnMaterial[u] += PIECE_VALUE(p); if ((IS_BISHOP(p)) && (IS_WHITE_SQUARE_COOR(c))) @@ -394,6 +398,12 @@ Return value: } } + if (pos->bbOccupied != bbOccupied) + { + uReason = 23; + goto end; + } + // // Now walk the actual board and reduce the material counts we got // by walking the piece lists. If everything is ok then the -- cgit v1.3