Author: Miguel A. Ballicora
Date: 10:40:48 06/26/02
Go up one level in this thread
On June 26, 2002 at 06:18:49, Filip Tvrzsky wrote:
>On June 25, 2002 at 22:20:32, Miguel A. Ballicora wrote:
>
>>On June 24, 2002 at 22:19:53, Filip Tvrzsky wrote:
>>
>>>On June 24, 2002 at 20:33:32, Russell Reagan wrote:
>>>
>>>>I am not an experienced bitboard user. I've been thinking about trying them out
>>>>just to see how they work in comparison with my current 0x88 implementation. Is
>>>>there any potential problem in mixing the two approaches? One problem that I can
>>>>see would be that if you have an index for a bitboard, it's not going to index
>>>>into the same square in your 0x88 array. I suppose the only real reason to keep
>>>>0x88 would be for efficient edge detection. Do bitboards offer a solution to
>>>>edge detection? Or do they even need edge detection when using bitboards (ex.
>>>>using the BSF asm instuction would seem to avoid edge detection altogheter)?
>>>>
>>>>Thanks,
>>>>Russell
>>>
>>>I am not an experienced bitboard user too ... :-), but I have tried to mix both
>>>approaches in my program, so I think it is possible very well. I assume x86 CPU
>>>architecture farther, because I have no another expierence. My goal was to take
>>>advantage of bitboards anywhere if it could be more efficient then pure 0x88
>>>representation, so I choose the way of improvement of my originally 0x88 program
>>>step by step. It is simple with knights and pawns, somewhat more complicated
>>>with rooks and most of all with bishops (I do not use bitboards here yet, but I
>>>work on it now). Something is possible to do with MMX instructions, but this
>>>instruction set has unfortunately many limitations. Generally I use bitboards by
>>>move generator, check detector and in evaluation function too. The cost of
>>>simultaneous keeping both 0x88 and bitboard representations is, in my opinion,
>>>more then outweighted by gains. The pure bitboard representation seems to me to
>>>be rather unefficient on x86 architecture, but I am not sure, I do not know it
>>>in detail.
>>>And regarding indexes for bitboards and 0x88 board, the mapping of one on other
>>>is not complicated, just 3 or 4 CPU instructions, no memory acces is needed:
>>>
>>>A - bitboard index (range 0-63),
>>>B - 0x88 index (range 0-7, 16-24, ... 112-119).
>>>
>>>Now, A == (B + (B & 7)) >> 1, and B == A + (A & ~7)
>>
>>These calculations do not look right...
>>
>>Aren't they suppose to be like this?
>>
>>unsigned int sq_to_x88 (unsigned int s)
>>{
>> return ((s & 070) << 1) | (s & 07);
>>}
>>
>>unsigned int x88_to_sq (unsigned int x)
>>{
>> return ((x & 0x70) >> 1) | (x & 07);
>>}
>>
>>
>>Miguel
>>
>>
>>
>>>
>>>Greeting you, Filip.
>
>Your calculations are O.K., but my also, I believe, and they are slitghtly
>shorter (you need 5 CPU instructions in both cases, I need only 3 or 4, as I
>wrote above). It is only little bit trick, nothing else ...
Ok, thanks, I got the trick now: The first case you mentioned it works because
the fourth bit it is empty, which is true in all the real cases. I missed that.
That allows to add up the number in the lowest 3 bits (which is the same as 2x,
which is the same as shifting this part one bit selectively) carrying the result
to this bit without interfering with the upper 5th, 6th and 7th bit.
Miguel
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.