gcc -Wall -O3 -c bit.c -o OBJ/bit.o
bit.c: In function ‘fill_up_right’:
bit.c:83: warning: suggest parentheses around arithmetic in operand of |
bit.c: In function ‘fill_up’:
bit.c:92: warning: suggest parentheses around arithmetic in operand of |
bit.c: In function ‘fill_up_left’:
bit.c:102: warning: suggest parentheses around arithmetic in operand of |
bit.c: In function ‘fill_right’:
bit.c:112: warning: suggest parentheses around arithmetic in operand of |
bit.c: In function ‘fill_down_right’:
bit.c:122: warning: suggest parentheses around arithmetic in operand of |
bit.c: In function ‘fill_down’:
bit.c:131: warning: suggest parentheses around arithmetic in operand of |
bit.c: In function ‘fill_down_left’:
bit.c:141: warning: suggest parentheses around arithmetic in operand of |
bit.c: In function ‘fill_left’:
bit.c:151: warning: suggest parentheses around arithmetic in operand of |
bit.c: In function ‘pop_count’:
bit.c:274: error: can't find a register in class ‘GENERAL_REGS’ while reloading ‘asm’
bit.c:274: error: ‘asm’ operand has impossible constraints
just tried checking it out today, but it seems broken
Hehe, I moved this to the programming forum, I assume that is where you meant to post it...
The reason is that I hastily put in some inline assembly for testing the speedup. This should work only on 64-bit systems using GCC. The easiest way to fix it is change line 241 from
...then it will use the old-style C algorithms. Anyways, I've been working on ZCT recently "in the dark", without updating the CVS for a while. Mostly just for a bit of secrecy before the Pan-Ams. I've cleaned up a lot of this with defines, so by for the next release it should be easier to deal with.
krazyken wrote:This is where I thought I was putting it.
OK so it compiles in 64 bit. gets quite a few warnings!
I guess I'll get an SMP build going to test.
I wouldn't recommend doing that either... SMP is rather messed up on the current CVS sources. IIRC 2 cpus should work fine, but they'll hog 100% cpu time even when idle. Next release will be stable on any number of processors and won't hog cpu time when idle. I've also cleaned the code up some, reducing the warnings.
Zach Wegner wrote: Mostly just for a bit of secrecy before the Pan-Ams.
Do you publish the book you use for tourneys? If not, I don't see why secrecy is an issue...I would think someone would need your program + your book to have meaningful preparation against your program.
krazyken wrote:so how much longer until the next release?
Got some endgame bugs to smash it seems:
ZCT counts this as +9 for Black
[d]8/7r/8/6k1/2R3b1/4K3/8/8 b - - 0 1
I'm not sure when the next release will be. I've been working on some other projects a lot lately (which you'll hear about at some point in the future...), so ZCT has taken sort of a back seat. I'll make sure the next release is a good one, and it should be more thoroughly bug tested.
The "bug" you mention is actually on purpose. It was a weird case, where I noticed that the strength improved when I doubled the endgame material value. IIRC I was testing with tripling it I've been messing with the phase scoring, and I'll probably put some more endgame knowledge in there as well before releasing.
BubbaTough wrote:Do you publish the book you use for tourneys? If not, I don't see why secrecy is an issue...I would think someone would need your program + your book to have meaningful preparation against your program.
-Sam
I will, mainly because it's just a PGN book, no manual intervention or anything. I don't have half the chess knowledge to make a good book. The secrecy really isn't a competitive issue anyways, as I highly doubt anyone would take the time to prepare against me. I was mainly just having a bit of fun.