Author: Filip Tvrzsky
Date: 10:51:37 02/20/03
Go up one level in this thread
On February 20, 2003 at 12:49:39, Uri Blass wrote:
>
>I guess that you mean
>#define gen_dat_i_mpromote (gen_dat[i].m & (63 << 16))
>
>I guess that the laternative that I tried
>
>#define to(x) (((x)>>8)&255) was also bad
>and better was
>#define to(x) (((x)&255<<8)
>
>I guess that in that case I need to change some more code
>
>For example
>
>I have today some cases when I have
>switch(m.bits)
>case 1:
>case 17:
>...
>
>in that case I need to say case 1<<24 and in order not to have an ugly code
>I need to have more constants for 2^24,2^24*17,...
>
>I can use
>enum
>{
> bits1=16777216
> bits17=
>...
>}
>
>Uri
#define to(x) (((x)>>8)&255) is definitely worse than #define to(x)
(((x)&255<<8) because in the first case the shifting is done in run-time and in
the second during compilation. Note also that the result of both macros is
different. For the same reason is "move & (some_bit << 24)" better than
"bits(move) & some_bit".
I agree that it is very usefull to define some more macros (or an anonymous
enumeration) like:
#define PROMOTION (0x8 << 24)
#define CASTLING (0x4 << 24)
#define CAPTURE (0x2 << 24)
and so on and avoid those "magical" numbers which make any change of
implementation to be a nightmare.
Better way to use these bitflags than switch statement is IMHO this:
if (move & CAPTURE) do_something;
[else] if (move & PROMOTION) do_something_else;
I think also that (move & PROMOTION) is quite clear expression, it isn't?
I have to repeat that the point is here to read the move value from memory and
then maximally exploit all information which it contains: this means also
somewhat concentrate the making of decisions in your code and minimalize the
branching in it. I vote also for splitting your move generator in more parts
(maybe normal moves, qsearch ... it depends on your search algorithm of course)
for the same reason.
Filip
This page took 0.01 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.