Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: definition of clones: Danchess an Crafty (another note)

Author: Robert Hyatt

Date: 11:59:05 02/17/04

Go up one level in this thread


On February 17, 2004 at 14:41:36, Dan Honeycutt wrote:

>On February 17, 2004 at 13:27:33, Robert Hyatt wrote:
>
>>On February 17, 2004 at 12:19:06, Sune Fischer wrote:
>>
>>>On February 17, 2004 at 11:49:33, Robert Hyatt wrote:
>>>
>>>>On February 17, 2004 at 10:48:35, Sune Fischer wrote:
>>>>
>>>>>On February 16, 2004 at 22:41:00, Robert Hyatt wrote:
>>>>>
>>>>>>This will make bitmaps insanely difficult to visualize.  Remember that bit 0 is
>>>>>>the LSB (or rightmost bit).  That means your chess board is going to look like
>>>>>>this when you display a bitboard as a hex number:
>>>>>>
>>>>>>
>>>>>>
>>>>>>             h1 g1 f1 e1 d1 c1 b1 a1
>>>>>>
>>>>>>Because the rightmost 8 bits would be displayed in that order.
>>>>>
>>>>>Correct.
>>>>>
>>>>>> That could drive
>>>>>>someone to drink drain cleaner.  I might be more tempted to make bit 0 either
>>>>>>square h8, or h1 instead, so that things are not impossible to debug...
>>>>>
>>>>>Why on earth would you want to do something horrible like that?
>>>>>
>>>>
>>>>
>>>>When I display a 64 bit word, it pops out in hex.  I want some simple way to
>>>>translate that 64 bit image into what it represents about each square, so that I
>>>>can do it mentally.  Currently take the 64 bit word in groups of 8 bits.
>>>>leftmost 8 bits is rank 1, next 8 bits is rank 2, all easy to visualize.
>>>
>>>Of course I want the same, that is why I don't get your 'backwards' way of doing
>>>it.
>>>
>>>bitboard b=..;
>>>
>>>rank 1: b&0xff
>>>rank 2: (b>>8)&0xff
>>>etc.
>>>
>>>I think this orientation is a lot easier mentally due to it corresponding well
>>>with a coordinate system, everything begins at the lower left corner!
>>> You never begin a coordinate system out at h1 for instance, that would make the
>>>x-axis negative :-)
>>>
>>>Ok, perhaps I am too math-impaired to accept anything else, it simply _must_ be
>>>this way for me, going against 15 years of school is too much to handle for me
>>>:)
>>>
>>>>I want
>>>>to renumber the bits, but also make the 64 bit value something I can look at and
>>>>then visualize without having to "flip" the board as might happen if I just
>>>>change the square numbers and leave the bit/square correspondence alone.
>>>
>>>You have to flip the board by your method AFAICT.
>>>At least I don't see how it maps easily starting at some obscure location like
>>>h1, do you go up or down from there or just wizz around randomly?
>>>How can normality be reconstituted?
>>>;-)
>>
>>I only want 8 consecutive bits to represent 8 consecutive squares, both going
>>left-to-right.
>>
>>Right now I do that.  the left-most 8 bits of a word are rank 1, next 8 are rank
>>2, etc.  in an 8 bit chunk, left bit = a file, right bit = h file.  I can deal
>>with that.
>>
>>Uri's suggestion inverted that so that left bit = right file, etc, and that was
>>what I was saying I could not mentally deal with.  It makes a lot of sense for
>>a1 (first square) to either be bit 0 (most logical) or bit 63.  At present, the
>>way I number things, it is (to me) a1=0, but the way BSF/BSR numbers bits, I
>>have a1=63 and I have to re-map it to my numbering scheme with the 63-x idea.
>>
>>I plan on getting rid of that at some point, but there will be some pain
>>involved, obviously.
>>
>>>
>>>>I have to compute square = 63 - bsf(board)
>>>>
>>>>_that_ subtraction.  And that needs a register.
>>>>
>>>>IE optimal (on opteron):
>>>>
>>>>bsfq   %rax, %rbx   ;   result in %rbx
>>>>
>>>>done.  result = %rbx
>>>>
>>>>Currently (on opteron):
>>>>
>>>>movq   $63, %rbx
>>>>bsfq   %rax, %rcx
>>>>subq   %rcx, %rbx   ;  result 63-bsf in %rbx
>>>>
>>>>That transformation is done everywhere I currently use FirstOne()/LastOne().
>>>>
>>>>Because I numbered the bits to avoid that on the Cray.
>>>
>>>Yes I understood this was some old reminiscence from the Cray, what I didn't
>>>know was that you actually liked the transformation :)
>>>
>>>-S.
>>
>>
>>I don't like it.  I only do it because bsf/bsr are much faster than any other
>>approach to extract a bit.  Since this seems to be the standard now for
>>numbering bits, I'm going to change what I do to dump the transformation.
>
>I assume this would be for 64 bit hardware.  In my fledgling attempt at a
>bitboard program (using x86 32 bit which is all I know) I have bit 0 = square 0
>= a1.  in FirstOne() if bsf delivers a bit on the low dword I'm out in one
>instruction.  but if I have to go to the high dword, or in both cases with
>LastOne() I have to add 32.  so it seems like 25% of the time I save an an
>instruction versus Crafty, but 75% of the time they are the same.  Or am I
>missing something?
>
>Dan H.


we do the same thing, except at the end, I have to compute

mysquare = 63 - yoursquare.

Because I number bits from the left, while bsf/bsr number 'em from the right.



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.