In qsearch at depth 0 we generate only captures and checks.
Queen promotion moves are generated among the captures, but
under-promotion moves (both captures and non-captures) are
never generated even if they could give a discovery check.
This patch fixes this limitation extending generate_pawn_noncaptures()
to generate also check moves when required.
Apart for adding the (rare) case of an under-promotion that gives
discovery check, the patch is also a good cleanup because removes
generate_pawn_checks() altoghter.
This patch does the code clean-up but not enables the functional
change so to allow an easier debug.
No functional change and no performance change (actually a very
very small speed increase).
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
We are generating also king moves that give check !
Of course these moves are illegal so are in any case
filtered out in MovePicker. Neverthless we should avoid
to generate them.
Also simplify a bit the code.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It is in line with attackers_to() and is shorter and
piece is already redundant because is passed as template
parameter anyway.
Integrate also pawn_attacks_from() in the attacks_from()
family so to have an uniform attack info API.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Use the definition in the few places where is needed.
As a nice side effect there is also an optimization in
generate_evasions() where the bitboard of enemy pieces
is computed only once and out of a tight loop.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It is a bit longer but much easier to understand especially
for people new to the sources. I remember it was not trivial
for me to understand the returned attack bitboard refers to
attacks launched from the given square and not attacking the
given square.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Most of them are not required to be public and are
used in one place only so remove them and use its
definitions.
Also rename piece_attacks_square() in piece_attacks()
to be aligned to the current naming policy.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
These functions return bitboard of attacking pieces,
not the attacks themselfs so reflect this in the name.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Instead of pawn_attacks(Color c, Square s) define as
pawn_attacks(Square s, Color c) to be more aligned to
the others attack info functions.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Remove undefined functions sliding_attacks() and ray_attacks()
and retire square_is_attacked(), use the corresponding definition
instead. It is more clear that we are computing full attack
info for the given square.
Alos fix some obsolete comments in move generation functions.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
This patch is built on Tord idea to use functions instead of
templates to access position's bitboards. This has the added advantage
that we don't need fallback functions for cases where the piece
type or the color is a variable and not a constant.
Also added Joona suggestion to workaround request for two types
of pieces like bishop_and_queens() and rook_and_queens().
No functionality or performance change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Use a single template to get bitboard representation of
the position given the type of piece as a constant.
This removes almost 80 lines of code and introduces an
uniform notation to be used for querying for piece type.
No functional change and no performance change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It is used mainly in a bunch of inline oneliners
just below its definition. So substitute it with
the explicit definition and avoid information hiding.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
This avoids calculating the array entry position
at each access and gives another boost of almost 1%.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
previous used move_is_legal to verify that the move from the TT
was legal, and the old version of move_is_legal only works when
the side to move is not in check. Fixed this by adding a separate,
slower version of move_is_legal which works even when the side to
move is in check.
This is another moves serialization macro but this time
focused on pawn moves where the 'from' square is given as
a delta from the 'to' square.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It is very rare we have pawns on 7(2) rank, so we
can skip the promotion handling stuff in most cases.
With this patch pawn moves generation is almost 20% faster.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
A promotion move is not considered a possible evasion as it could be.
Bug introduced by patch
Convert also generate_pawn_blocking_evasions() to new API (7/5/2009)
Bug spotted by Kenny Dail.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Rename to move_is_promotion() to be more clear, also add
a new function move_promotion_piece() to get the
promotion piece type in the few places where is needed.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
We can have false positives, but these are filtered out
anyhow by following conditions so they are harmless.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Tests on Joona luxury iCore7 QUAD show that speed increase
against standrd 64bit routine is between 3% and 4%.
So it seems a good thing to have. Also the user feedback at
startup regarding the compile and the hardware detection can
be an useful debug tool.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
In MovePicker consider killer moves as a separate
phase from non-capture picking.
Note that this change guarantees that killer1 is always
tried before killer2. Until now, because scoring difference
of the two moves was just 1 point, if psqt tables of killer1
gave a lower value then killer2, the latter was tried as first.
After 999 games at 1+0 we have
Mod vs Orig: +245 =527 -227 +6 ELO
Not a lot but patch is anyhow something worth to have.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It shows almost no improvment and adds a good
bunch of complexity.
So remove for now. No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
We don't need different names between a function and a
template. Compiler will know when use one or the other.
This let use restore original count_1s_xx() names instead of
sw_count_1s_xxx so to simplify a bit the code.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Use a better condition to find candidate direct check pawns.
In particular consider only pawns in the front ranks of the
enemy king, this greatly reduces pawns candidates bitboard
that now is empty more then 90% of the time so that we
can early skip further tests.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Be more strict, is not enough dc bitboard is not empty, but
needs to inclde also at least one pawn.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
We can parametrize for the capture direction too.
Also use a single template parameter and calculate (at
compile time) remainin parameters directly in the function.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
In case we have a correct white pawn move but pawn
is black (or the contrary) we fail to detect the
move as illegal.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Instead of loop across all legal moves to find a mate
loop across possible check moves only.
This reduces more then 10 times the number of moves to
check for a possible mate.
Also rename generate_checks() in generate_non_capture_checks()
so to better clarify what the function does.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Avoid calculating piece attacks if there aren't
available check sqaures for the given piece.
About 15% of cases. Not a biggie but still something
especially in the middle game where king is well covered
inside his castle.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It is slower the previous uglier but faster code.
So completely restore old one for now :-(
Just leave in the rework of status backup/restore in do_move().
We will cherry pick bits of previous work once we are sure
we have fixed the performance regression.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
They hide the underlying uniform function call with
no benefit.
A little bit more verbose but now is clear what happens.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
In generate_piece_moves() to be more uniform with other
functions. Unfortunatly the different number of calling arguments
do not allow us to easily integrate in generate_piece_moves()
template family.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Small code tidy up and a little optimization
to avoid calling generate_piece_blocking_evasions()
when blockSquares is empty (30% of cases).
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Now that we have removed sliders checkers attacks
from evasion's set we can simplyfy legality check.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Rewrite as in generate_piece_moves() using a for
loop instead of the slower serializing of the
bitboard with pop_1st_bit()
This will allow also to merge with generate_piece_moves()
when we will drop legality constrain on generate_evasions()
Generated moves are not changed, but are generated in a
different order, this changes the number of nodes at fixed
depth test.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Discovery check candidates are normally empty, so
avoid discovery checks generation in that common case.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Find squares attacked by slider checkers, we will
remove them from king evasions set so to avoid a couple
of cycles in the slow king evasions legality check loop.
Not a biggie, but now generate_evasions() is faster then
generate_non_captures(), before was slower.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
When we generate checks one case is missing: generation
of castling moves that give check to the opponent king.
This is a very rare case but anyway it is a case
and we can do this without slowing down the common
case of no castling checks.
So this is the patch.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Introduced in the patch "movegen: prefer (*mlist++) to mlist[n++]"
This was nasty because due to a mismerge the repo in one PC had the bug,
but the testing one did not, so I had non reproducible results according
to which machine I used for testing.
This hopefully closes a more then one week regression that made me go crazy!
It was found by accident comparing, for other reasons, the sources of the
two PC's.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Use the pinned argument in pos.move_is_legal()
No functional change, simply use pos.move_is_legal() as
was meant to be.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Introduced in "movegen: Introduce generate_pawn_captures()"
when unifiying black and white functions.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Instead of function pointers use templates to
dispatch shift operations.
It is more clear and possibly also faster because
branches are removed at compile time.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Bitwise operators precedence issue here, was
causing an assert.
This is a fallout from recent patches.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Instead of function pointers use templates to
dispatch shift operations.
It is more clear and possibly also faster because
branches are removed at compile time.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Bitwise operators precedence issue here, was
causing an assert.
This is a fallout from recent patches.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It was written pos.black_pawn_attacks(ksq) instead of
pos.white_pawn_attacks(ksq)
Updated to the undrlying pos.pawn_attacks(WHITE, ksq)
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Teoretically a little slowdown. If after testing we
verify the slowdown has impact on ELO we revert the
change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It is more clear, at last for me.
Also cleanup evaluate_rook() and evaluate_queen()
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Marco Costalba