Revert "Do not extend at low depths if not in PV"

On Joona's QUAD:
Orig - Mod: 414 - 373

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Revert "IID in pv also when TT move depth is too small"

After almost 900 games we are at -2 ELO

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Last conversions to Score in evaluate.cpp

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Convert ThreatBonus to Score

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Convert RookOn7thBonus and QueenOn7thBonus to be Score

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Convert mobility bonus tables to Score

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Convert apply_weight() to handle Score

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Convert MaterialInfo and PawnInfo to use Score

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Introduce PieceSquareTable[16][64]

Instead of MgPieceSquareTable[16][64] and EgPieceSquareTable[16][64]

This allows to fetch mg and eg values from adjacent words in memory.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Convert Position to use Score struct

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Introduce Score struct

Save mid and end game scores in an union so to
operate on both values in one instruction.

This patch just introduces the infrastructure and changes
EvalInfo to use a single Score value instead of mgValue
and egValue.

Speed is more or less the same because we still don't use
unified midgame-endgame tables where the single assignment
optimization can prove effective.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Fix correct name of int64_t type

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Do not extend at low depths if not in PV

Only check extensions are allowed.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

IID in pv also when TT move depth is too small

Try an internal iterative deepening not only when we don't
have a TT move but also if search depth is more then 4*OnePly
higher then TT move depth.

On some tests it seems that in around 20% of cases ttMove changes !

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Better big-endian support wording in Makefile

Suggested by Joona.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Enable POPCNT only through Makefile

Also remove some fallback templates that prevent a
compile error in case the user runs 'make icc-profile-popcnt'
from a non supported machine.

We want to loudly fail in that case instead of silently
fallback in a non-popcount compilation.

Updated documentation too.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Add popcnt-support in Makefile

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Small code-style touches in movegen.cpp

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Fix a small warning under icc

Variable 'f' in 'for' loop scope hides same named
one in outer scope.

Of curse no functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Big-endian compatible pop_1st_bit()

Thanks to Eric Mullins we have now endian friendly
pop_1st_bit() and also is removed the need to use
-fno-strict-aliasing compiler option with GCC.

Speed is almost as fast, very small difference if any in
perft test, so I assume almost no difference in real games.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Fix a compile error in debug mode

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Enable PH_TT_MOVES during evasion generation

This allow us to avoid the generation of the
evasion moves if we already have a TT move, and
in case we have a cut-off we skip evasion generation
altoghter.

Node count is changed because now we try TT move _before_
to generate evasions. The search on the TT move alters the
piece lists so that when we come back to generate evasions
we build the move list with a diferent order and this alters
the node count.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Extend move_is_legal() to work also when in check

This patch is a prerequisite to use TT phase
during evasions.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Move locals definitions at the function start

It seems to me function are easier to read now.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Retire MovePicker::discovered_check_candidates()

It is now no more needed to know dc candidates
inside MovePicker, so avoid calculating there.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Rewrite generate_pawn_moves() and simplify evasions

Big cleanup and semplification of pawns evasions that
now are pseudo-legal as the remaining moves. This
allow us to remove a lot of tricky code.

Verified against perft: no functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Generate pseudo-legal moves in generate_evasions()

This allow a big semplification in move generation
that will be committed with the next patch. And makes
handling of evasions similar to the other type of moves.

This patch plus the next seem to improve also on
the performance side because after 640 games to
verify there are no hidden regressions we are at +9 ELO

Verified with perft no functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Optimize generate_evasions()

Generate captures of checking piece and blocking
evasions in one go.

Also reduce of one indentation level early returning
when we have a double check.

Verified with perft no functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Speed up perft

There is no need to do / undo the move at the last ply

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Remove SEE optimizations

Don't seem to help, perhaps because we
return an approximate SEE score instead of the
real negative score so that we have some bad capture
or evasion sub-optimal ordering that compensates
the speed up.

Anyhow after 999 games at 1+0
Mod vs Orig +240 =514 -245 -2 ELO

So almost no harm to remove and make the code simpler.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Reorder evasions

Always try ttMove as first. Then try good captures ordered
by MVV/LVA, then non-captures if destination square is not
under attack, ordered by history value, and at the end
bad-captures and non-captures with a negative SEE. This
last group is ordered by the SEE score.

After 999 games at 1+0
Mod vs Orig +254 =546 -199 +19 ELO

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Another see() shortcut

Because we only generate legal moves we can assume
a king cannot be recaptured, so we can safely return
immediately with the captured piece score. If the move
turns out to be illegal it will be pruned anyhow,
independently from SEE value. This gives a good speed up
especially now that we SEE-test all the evasions that
are always legal and very often are king moves.

Another optimization catches almost 15% of cases, unfortunatly
we have already calculated the very expensive attacks, so
benefits are not so big anyway.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Shortcut see_sign() when SEE is known negative

This patch cuts 30% of SEE calculations, as a drawback
a returned negative value is no more always correct if
a shortcut is found.

This could impact move order when based on negative see
score as example bad captures and evasions.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Remove castling moves in check generation

Check generation is used only in qsearch and
only at Depth(0), castling moves that give check
are very rare overall and even almost not exsistent
at Depth(0).

So retire this almost never used code that adds
a small but consistent slow down in the normal path.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Optimize check generation

Because discovery checks are very rare it is better to handle
them all in one go and strip from usual check generation
function.

Also rewrite direct checks generation to use piece lists instead
of pop_1st_bit()

On perft test we have a +6% of speed up and is verified we
generate the same moves, although in a different order.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Implemented perft

Patch from Joona with extension to benchmark and inclusion
of Depth(0) moves generation by me.

Note that to test also qsearch and in particulary checks
generations a change in the end condition is needed.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Evaluation threat values after 39089 games

Verified against tuning branch.

After 100 games at 1+0 on Joona QUAD

Mod - Orig: 527.5 - 471.5 (+20 elo)

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Fix build under gcc

Also some warnings squashed.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Add threat evaluation

Give a bonus for each kind of attacked piece. Bonus
value is based on the type of attacked piece and the
type of attacking one.

Penalize pieces attacked by enemy pawns, also in
this case penality value depends on the type of
attacked piece.

This patch oboletes as redundant the increased mobility
count of the attcked squares that is then removed.

After 956 games at 1+0
Mod vs Orig  +262 =462 -232 51.57%  493.0/956 +11 ELO

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Micro optimize mobility calculation

Take out of mobility loop a constant expression.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Unify capture and promotion tests

Small code cleanup and a bit faster too.

The only functional change is that in extension
in pv node we extend promotions and not only captures
when condition met.

This is practically an undetectable change and has
no impact on strenght.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Don't prune TT move in qsearch even if SEE < 0

Even if SEE is negative there is always a good possibility
that TT move is a cut move anyway. For instance a lot of
BXN exchanges that have negative SEE can very easily be
good exchanges.

A nice side effect is a bit reduced frequency of
see_sign() calls.

After 643 games at 1+0
Mod vs Orig +174 =327 -142 52.49%  337.5/643 +17 ELO

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Pick best moves one per cycle instead of sorting

When the move list is very small, like captures normally
are, it is faster to pick the best move with a linear
scan, one per cycle.

This has the added advantage that the picked capture move is
very possibly a cut-off move, so that other searches are
avoided. For non-captures it is still faster to sort in
advance.

Because scan-and-pick alghortim is not stable, node count
has changed.

After 885 games at 1+0
Mod vs Orig +196 =510 -179 50.96%  451.0/885

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Avoid a needless locking in sp_search()

Only in less then 2% of cases we have a new sp->bestValue,
so check before to lock and save a costly locking
most of the times.

Patch suggested by Joona.

No functional search.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Similarize pruning code in search() and sp_search()

Use futility pruning also in split points.
Do not use history pruning in split points when
getting mated.

After 1000 games on Joona QUAD
Orig - Mod: 496 - 504

Added an optimization to avoid a costly lock in the
very common case that sp->futilityValue <= sp->bestValue.
A test on a dual CPU shows only 114 hits on 23196 events,
so avoid a lock in all the other cases.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Use an homegrown insertion sort instead of std::sort()

It is stable and it is also a bit faster then std::sort()
on the tipical small move lists that we need to handle.

Verified to have same functionality of std::stable_sort()

After 999 games at 1+0
Mod vs Orig +240 =534 -225 50.75%  507.0/999  +5 ELO

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Do not prune the move if we are still under mate

If after the first tried 2 + int(depth) moves we still
have no any move that takes us out of a mate then do
not prune the following move, it is more important to
escape mate then speed up search.

This fixes an odd behaviour regarding mates, as example
the following diagram is a mate in 4, not in 3 as bogusly
reported before this patch.

1B2n3/8/2R5/5p2/3kp1n1/4p3/B3K3/8 w - - bm #4;

The performance impact should be minimal, the increment
in searched nodes is less then 0.1 %%

Idea and patch by Joona

After 999 games at 1+0
Mod vs Orig +193 =604 -202  -3 ELO

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Minor improvement in eval of unstoppable pawns promoting one ply apart.

Marco's new code for evaluating two unstoppable passed pawns where
one pawn promotes a single ply before the other tried to detect
cases where the pawn that promotes first could immediately capture
the pawn that promotes a ply later, but didn't work in cases where
the two pawns are on the same file. An example of this is the
following position:

8/8/3K4/2P5/2p5/3k4/8/8 w - -

With the new code, such positions are handled correctly.

Fix a crash when reaching PLY_MAX in a check position

In this case we call evaluate() being in check and this
is not allowed.

Bug found testing with reduced PLY_MAX value as suggested
by Miguel A. Ballicora on talkchess.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Add a new rule on promoting pawns in evaluate_passed_pawns()

Add a rule about the situation when one side queens exactly
one ply before the other. To avoid difficult (but luckly rare)
cases we only handle the case of free paths to queen for
both sides.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Fix x-ray attack from behind in evaluate_passed_pawns()

Fix a condition for x-ray attack of a queen or
a rook behind a pawn of us. Previous condition does
not check if the enemy slider behind our pawn is
really attacking the pawn.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Small cleanup and in evaluate_passed_pawns()

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Revert "Use std::stable_sort() instead of std::sort()"

Unfortunatly std::stable_sort() implementation in gcc is
horrendously slow. We have a big performance regression on
Linux systems (-20% !)

So revert the commit and wait to fix the issue in a different
way, perhaps with an our home grown sorting, that should be
comparable in speed with std::sort()

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Use std::stable_sort() instead of std::sort()

Standard does not mandate std::sort() to be stable, so we
can have, and actually do have different node count on
different platforms.

So use the platform independent std::stable_sort() and gain
same functionality on any platform (Windows, Unix, Mac OS)
and with any compiler (MSVC, gcc or Intel C++).

This sort is teoretically slower, but profiling shows only a very
minimal drop in performance, probably due to the fact that
the set to sort is very small, mainly only captures and with
less frequency non-captures, anyhow we are talking of 30-40 moves
in the worst average case. Sorting alghortims are build to work on
thousands or even milions of elements. With such small sets
performance difference seems not noticable.

After 999 games at 1+0

Mod vs Orig +234 =523 -242 -3 ELO

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Unroll color loops in evaluate_passed_pawns()

Speed increase is on 1.5% on Intel pgo build.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Use piece_list to scan the pawns in evaluate_pawns()

No functional change and small speed increase.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Fix pieceList initialization in Position::clear()

We want piece list to be terminated with SQ_NONE.

This happens with all the pieces but the pawns that
being 8 make the inner loop exit just before writing
the SQ_NONE value at the tail of the list.

This bug was hidden because currently we don't use
piece list to scan pawns, but this will change in the
future and in any case an initialization should be done
correctly for the whole array to avoid subtle bugs in
the future.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Unroll color loops in get_pawn_info

This allow to resolve a lot of addresses at compile time
instead of an indirect access at runtime.

Speed up on pgo compile is of 1.3%

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Small micro-optimization in get_pawn_info()

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Restore pliesFromNull counter

It is not equivalent because the check for the
50 moves rule get badly affected.

// Draw by the 50 moves rule?
if (st->rule50 > 100 || (st->rule50 == 100 && !is_check()))
    return true;

So we _really_ need two counters.

Thanks to Joona and Tord to be patience with a silly guy ;-)

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Fix an off-by-one bug in extract_pv()

In case we reach ply == PLY_MAX we exit the function
writing

pv[PLY_MAX] = MOVE_NONE;

And because SearchStack is defined as:

struct SearchStack {
  Move pv[PLY_MAX];
  Move currentMove;
  .....

We end up with the unwanted assignment

SearchStack.currentMove = MOVE_NONE;

Fortunatly this is harmless because currentMove is not used where
extarct_pv() is called. But neverthless this is a bug that
needs to be fixed.

Thanks to Uri Blass for spotting out this.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Rewrite previous patch using only one counter

Use only rule50 and retire pliesFromNull.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Do not claim repetition after null move

Null moves can artificially create a repetition
draw where instead there is no one.

So use a second counter to reset history after
a null move.

Idea from Joona.

After 999 games at 1+0

Mod vs Orig +238 =553 -208 51.50%  514.5/999  +10 ELO

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Restore development version

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Stockfish 1.5.1

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Fix the polling frequency when pondering

When pondering InfiniteSearch == false but myTime == 0 so that
NodesBetweenPolls = 1000 instead of the standard.

The patch fixes the bug and is more robust because checks
directly myTime for a non-zero value, without relying on
an indirect test (InfiniteSearch in this case).

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Use slightly lower polling frequency in the last few seconds.

Instead of checking the time every 100 nodes in the last second,
and every 1000 nodes in the last five seconds, Stockfish now checks
every 1000 nodes in the last second and every 5000 nodes in the last
five seconds.  This was tested in 1036 games at a time control of
40 moves/10 seconds, and no losses on time occured.

Also fixed a bug pointed out by Marco:  In infinite mode, myTime
is actually 0, but of course we still don't want to check the time
more frequently than the standard once per 30000 nodes in this
case.

Minor change to time management code, to make sure we don't lose on
time at the last move before the time control when there is very
little time left.

Display fail high/fail low in search log file.

Fix bogus comment in extract_pv()

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Fix use of an initialized SearchStack

In RootMoveList c'tor we allocate a search stack and then
call directly qsearch.

There is called init_node() that clears all the fields of the search
stack array that refers to current ply but not the the killer moves.

The killer moves cleared correspond to ply+2.

In id_loop() this is not a problem because killer moves of
corresponding ply are cleared anyway few instructions later,
but in RootMoveList c'tor we leave them uninitialized.

This patch fixes this very old bug. It comes direclty
from Glaurung age.

Bug spotted by Valgrind.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Remove a redundant assignment in PawnInfo c'tor

We don't need to set key to 0 because clear() already
takes care of that.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Small code reformat in TranspositionTable::extract_pv()

In particular don't use an array of StateInfo, this
avoids a possible overflow and is in any case redundant.

Also pass as argument the pv[] array size to avoid a second
possible overflow on this one.

Fix suggested by Joona.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Fixed an embarassing Chess960 bug found by Alexander Schmidt.

It turned out that we used do_move_bb to update the king and rook
bitboards when making and unmaking castling moves, which obviously
doesn't work in Chess960, where the source and destination squares
for the king or rook could be identical.

No functional change in normal chess.

Restore development version

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Stockfish 1.5

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Small touches to increased mobility patch

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Move a comment where it belongs in SEE

No functional change of course.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Don't increase mobility if attacked piece is defended by a pawn

If an enemy piece is defended by a pawn don't give the
extra mobility bonus in case we attack it.

Joona says that "Paralyzing pawn" is usually worth of nothing.

On Joona QUAD after 964 games:
Orig - Patch_2: 191 - 218 - 555 (+ 10 elo)

On my PC after 999 games at 1+0:
Mod vs Orig +227 =550 -222 50.25%  502.0/999  +2 ELO

In both cases we tested against the original version (without
increased mobility), not against the previous patch that instead
seems to fail on Joona QUAD:
Orig vs. Prev.Patch: 237 - 217 - 627 (-6 elo)

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Count two times number of attacked pieces in mobility

Now in mobility we count enemy attacked pieces as
empty squares.

With this patch we try to give an higher score to positions
where the number of attacked pieces is higher.

After 999 games at 1+0

Mod vs Orig +262 =517 -219 52.15% 520.5/998 +15 ELO

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Optimize futilityValue calculation

Avoid calling evaluate() if we already have the score in TT

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Store pawn attacks in PawnInfo

They are pawn structure invariant so has a sense to
store togheter with pawn info instead of recalculating
them each time evaluate() is called.

Speed up is around 1%

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Fixed a couple of typos in a comment.

No functional change, of course.

Fix a MSVC warning in search.cpp

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Temporarily removed the unfinished UCI_Elo code in preparation for
the release of the public Stockfish 1.5.

Print RootMoveList startup scoring

This satisfies a specific user request of 28/8/2009

"The only issue I have is that during multiPV analysis, the depth 1
best move score is not reported by the engine (reporting for the best
move begins at depth 2).  I need it at depth 1 also. Would it be
possible to make this modification in future versions? This would be
of great help as otherwise I will have to use a lesser engine.

The goal of my project is to calculate the ELO performance in a game
and also the ELO rating of individual moves. For this I need depth 1
scores for lower rated performances. I intend to distribute the program
for free upon completion.

Thanks, Jack Welbourne"

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Retire compute_weight() in evaluation.cpp

Is used only in weight_option() so inline there.
Unroll color loop also for evaluate_space() and
finally also some assorted code style fixes.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Unroll color loops in evaluate

Use templates to manually unroll the loops so that
many values could be calculated at compile time or at
runtime but with a fast direct memory access instead of
an indirect one.

This change gives a speed up of 3.5 % on pgo build !!!  :-)

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Change back file mode of misc.cpp

It was erroneusly changed by 6bf22f35 from
mode 100644 to 100755.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Update piece list iteration also in evaluate_pieces()

Move to what we already do in generate_piece_moves()

This simple patch gives a spped up of 1.4% !!

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Retire faked Windows version of gettimeofday()

Use equivalent Windows function _ftime() instead.

This patch also removes two long standing warnings
under MSVC.

No functional change and no change for non-Windows systems.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Micro optimization of generate_piece_moves()

This patch make the piece list always terminated by SQ_NONE,
so that we can use a simpler and faster loop in move
generation.

Speedup is about 0.6%.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Retire kingSquare[] array

It is redundant. Use pieceList[c][KING][0] instead.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Reorder data layout and optimize access patern

With this very simple patch we get a speed boost
of 0.8% on my PC !

Sometime we find the most complex tricks to increase speed
when instead the best results come from the simplest solutions.

No functional change of course ;-)

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Fix a couple of Intel compiler warnings

And avoid calculating emptySquares for pawns captures
case.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Fix a piece_of_color_and_type() / pieceS_of_color_and_type() typo

Bug introduced in 17c51192

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Rename generate_piece_moves() in generate_piece_evasions()

A better and more specific name. Also a bit of code reshuffle.

Verified No functional change and No performance change
for the whole series.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Retire generate_pawn_captures()

And unify in generate_pawn_noncaptures() renamed
generate_pawn_moves()

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Retire generate_pawn_blocking_evasions()

And unify in generate_pawn_noncaptures()

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Standardize generate_pawn_blocking_evasions()

Rewrite in the form normally used in other similar
functions like generate_pawn_noncaptures()

This allow an easier reading of the pawn moves generators
and simplify a bit the code.

No functional change (tested on more then 100M nodes).

Signed-off-by: Marco Costalba <mcostalba@gmail.com>