Author: Robert Hyatt
Date: 17:04:46 07/18/02
Go up one level in this thread
On July 18, 2002 at 19:00:02, Russell Reagan wrote:
>On July 18, 2002 at 13:23:23, Robert Hyatt wrote:
>
>>I already do this. I have "Rank()" and "File()" macros that I use most
>>everywhere already. Ditto for "From()", "To()", "Piece()", "Captured()" to
>>extract that field from the 21 bit compressed move format I use internally.
>
>I was actually wondering about something related to this just today. Perhaps you
>could provide a little guidance on anything you see awkward or flat out wrong.
>Would it be faster to do your approach and extract info from a packed 32-bit
>unsigned int (or whatever size you'd like), or to do something like this...
>
>union Piece {
> struct {
> unsigned char color;
> unsigned char type;
> unsigned char index;
> unsigned char alive;
> };
> unsigned int piece;
>};
I think chars are fine. I do what I do because I originally used bit
fields and they were _terribly_ slow. The compiler can't know about
what is in the high-order (or low order depending on which side the
bitfields start from) end so it has to continually mask things that are
really already zero...
>
>Currently I do something like you do, and I have COLOR() and TYPE() macros that
>extract the data from a 32-bit int. I have gone back and forth here. I have
>thought about doing things in a manner similar to Gerbil, where your "board" is
>an array of pointers into to piece array, but then in generating moves if you
>have to test if there is a piece there, and if there is you have to do another
>test for what kind of piece it is, and possibly it's color. Using my current
>method, I can just say:
>
>if(TYPE(squares[i]) == KNIGHT)
> // then generate knight moves
>
>The other approach would take more instructions:
>
>if(squares[i] != NULL) // testing our array of piece pointers here
> if(squares[i]->type == KNIGHT)
> // generate knight moves
>
>So one looks like you have the extra ANDing to do, and one you have the extra
>testing and pointer dereferencing to do. These are things that bother me and I
>don't know enough about ASM to answer them myself.
>
>Using the union approach you could do access the fields that are on the 8-bit
>boundaries, and if we needed to copy a piece (move it) we could just copy the
>'piece' field of the Piece structure.
>
>Would accessing those things be faster than using an ANDing approach? I'm not
>very good with ASM, so I figure you can answer better than I can. Granted, if
>you have more than 4 things you need to keep track of, you either have to use
>the AND method that you use and pack more in, or you have to use another 32-bit
>value to your structure. But for a structure with 4 or fewer things to keep
>track of, would the union and anonymous struct method work faster than the
>ANDing approach? In my mind I'm thinking that the ANDing approach needs that
>extra AND, but maybe I'm missing something, since like I said, I'm not very keen
>on the efficiency of various things when done in ASM.
>
As I said, I think that accessing chars is fine, compared to the AND
approach I use. However, I don't have things on char boundaries and the
bit fields were simply excessively slow (which surprised me until I looked
at the asm to see why).
>These things make my head hurt. I can't decide whether it's better to get rid of
>the ANDing and add a pointer dereference and extra testing or whether I should
>use something like the union approach. I probably shouldn't be worrying about
>things as trivial as this yet, but it still bothers me.
>
>Russell
You really have to test. And then test again in a few months after your
code is more complex and "register jams" or "register spills" become a
problem..
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.