IIRC you have mentioned something about multiple eval functions in R3. Since I looked at R4 before I choose top-down approach with R3 - following the call graph. So far I found only one and I am 99% sure that this is the real thing... but just to be sure - is it the one at 0x453C70 ?
There is one eval for black on-move, and one for white [one way to find them is searching for
prefetch, and then going up about 40 instructions]. They compute exactly the same things, except at the end when the score reduction from pawn drawishness comes into play, where there is some confusion about min/max with a negative argument and shifting/dividing. Previous versions (R232a) had multiple eval functions [again in duplicate], and my guess is that they were used as the game progressed (for instance, a given eval function might not have rook evaluation, when no rooks were on the board at the root node).
Here are the start of the R3 evals, loaded (1cpu version) with
wine in Linux (which loads the offset
0x5f400 in the binary to
0x460000, for instance):
Code: Select all
0x00000000004637f0: mov %r9d,0x20(%rsp)
0x00000000004637f5: mov %rcx,0x8(%rsp)
0x00000000004637fa: mov %rsp,%rax
0x00000000004637fd: sub $0x148,%rsp
0x0000000000463804: mov 0x2674d5(%rip),%r10 # 0x6cace0 // material token
[...]
0x0000000000463826: mov %r10,%rax
0x0000000000463829: sar $0x8,%rax
[...]
0x0000000000463838: and $0x7ffff,%eax
Code: Select all
0x0000000000479610: mov %r9d,0x20(%rsp)
0x0000000000479615: mov %rcx,0x8(%rsp)
0x000000000047961a: mov %rsp,%rax
0x000000000047961d: sub $0x148,%rsp
0x0000000000479624: mov 0x2516b5(%rip),%r10 # 0x6cace0 // material token
[...]
0x0000000000479642: mov %r10,%rax
[...]
0x000000000047964c: sar $0x8,%rax
[...]
0x000000000047965e: and $0x7ffff,%eax
EDIT: Now that I look, there are also R3 eval functions at
0x494250/
0x4aa290 in my accounting [again I found these from
prefetch], but I don't think those get called in "normal" usage (maybe they have to do with contempt? -- I never got into looking at that, mainly because IPPOLIT didn't have it).
What is this thing about rotated bitboard initialization code (supposedly copied from Crafty) that Dr. Hyatt talks about? AFAIK, R3 has no BB initialization code. Every lookup table is pre-initialized and contained in the executable...
I've never been sure what Bob is talking about with this, It seems to me that (at one point) he was claiming IPPOLIT's bitboard initialisation had some Crafty idiosyncracies, but I agree with you that Rybka prefers just to have huge pre-computed tables in the object file.
As for the copyright issue, I think we will just have to agree to disagree at this point. The question of "creative expression" in computer code is certainly not one for which there are many legal precedents. If VR still had the Rybka 1 source code, or if he had no "prior history" as with Rybka/Crafty, or if there was no "probative similarity" (copying structures in time management) for Fruit/Rybka, or ..., then any legal action might well be unlikely to succeed. As it is [and w/o knowing what defence Rajlich might make], I think there is a decent chance that a Polish judge could find that there was a "preponderance of evidence" that Fruit's copyright was infringed, though exactly what this means on a percentage-wise basis would be yet another can of worms.
Mark Twain wrote:Only one thing is impossible for God: To find any sense in any copyright law on the planet.