BTW if this is a 64 bit compile, you have a ton of registers the compiler can use. cl/cx/ecx/rcx should not be an issue.
I use Ubuntu 14.04 64 bit, gcc and g++ version 4.8.4

BTW, if using 1<<shift and not table, the code to clear a bit may be:
inline U64 ClrBit(int sqr) { return rol(-2ull,sqr ...

That is still only an extra load from memory, same as the table lookup.

Are you sure you are measuring what you think you are? IE your test program was totally wiped out by the optimizer.
Yes, I tried both with my C-engine Sillycon, and with my new C++ perft program.
For Sillycon the speed in NPS ...

I don't see how it can be faster. A shift is a one cycle instruction. An array lookup requires the address computation and a cache probe.
Well, its faster for me (tested it once again). It might be that when using variable shift the RC register is clobbered, due to the use of CL, and the RC ...

My experience is that a table lookup for SetBit() is always faster than shift, both with my perft and my engine.
I use ClearBit(sqr) = ~SetBit(sqr) together with this, instead of a separate table for clearing a bit.
It is easy to change to using shift later though.
This is on an i7-2600K.

Regards ...

I dont know about state diagram but this link tells pretty much about the winboard protocol 2.

http://www.gnu.org/software/xboard/engine-intf.html

The point with the beta cutoff using eval score is that a capture sequence may (normally) be abrupted, so if the side to move chooses a non-capture the (eval) score of the position will probably be above beta. I believe this is called stand-pat.

Regards, Lasse