Author: Gerd Isenberg
Date: 13:51:49 12/08/03
Go up one level in this thread
On December 08, 2003 at 12:28:55, Georg v. Zimmermann wrote:
>This has been recently discussed, but on a very sophisticated level, while I am
>looking for a simple solution.
>
>Right now I just have 2 makeMove() , 2 genAllMove(), 2 genCaptures() etc etc
>
>In there are statements like
>
>if (to >> 4 == 7) // is it a promotion ?
>{...}
>
>To make the code color independent, my first idea was to have
>
>if (to >> 4 == lastRank[onMove])
>{..}
>
>and have such similar arrays for colorMask[2], fifthRank[2], e1Square[2],
>pawnDirection[2] etc.
>
>First question: how slow is this ? Is it comparable slow as having
>
>if (onMove)
> if (to >> 4 == 7)
> {...}
>else
> if (to >> 4 == 0)
> {...}
>
>which is horrible ?
Hi Georg,
yes, if you mean this and the if-blocks are equal ;-)
if (onMove)
{
if (to >> 4 == 7)
{A}
}
else
{
if (to >> 4 == 0)
{A}
}
Considering the exclusive sets of promote squares per color, you may skip the
"if color" at all for this promote purpose:
if ( ((to >> 4) == 7) || ((to >> 4) == 0) )
{...}
You may save the shift:
if ( (to >= (7<<4)) || (to < (1<<4)) )
{...}
Using the "unsigned range trick", you may write
(or leave the optimization to the compiler):
if ( (unsigned)to - (8<<1) >= (48<<1) }
{...}
Anyway, as Heiner already mentioned, i would hide the implementation in a macro
or inliner and to use e.g.:
if ( isPromoteSquare(to) )
{...} // first or eighth rank
With C++ inlines you may even use a color dependent polymorph overload:
if ( isPromoteSquare(color, to) )
or make it member of a color class:
if ( color->isPromoteSquare(to) )
or even member of a square class ;-)
if ( sq->isPromoteSquare(color) )
>
>
>Then my next idea was to have a structure where I put all the relevant info in.
>struct colorDep
>{
> int lastRank;
> [...]
>};
>
>and then fill 2 such structures with the correct info for white and black. And
>have a pointer which always points to the correct one. Then I could do
>
>if (to >> 4 == cD->lastRank)
>{..}
>
>Is this faster as the array solution, as I think it is ?
>
Pointer on struct (ebx) with small offset (e.g. +16 -> 16-bit sign extension),
versus index (4*ebx) with global 32-bit address.
So probably a bit shorter opcode, on x86-32 two or four bytes shorter opcode...
Sometimes redundancy pays off. OTOH if you have to assign the cD-pointer with
the color index at runtime each node...
Cheers,
Gerd
>
>Thanks a lot for any help - and I do accept RTM as answer, if it comes with a
>good link :-).
>
>Georg
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.