The Evidence against Rybka

Code, algorithms, languages, construction...
User avatar
Uly
Posts: 838
Joined: Thu Jun 10, 2010 5:33 am

Re: The Evidence against Rybka

Post by Uly » Tue Oct 04, 2011 12:21 pm

So it looks like I'll need to crosspost between the fora :roll:
BB+ wrote:

Code: Select all

0x000000000040702e:     test   %r15b,%r15b
0x0000000000407031:     mov    0x50(%rsp),%r14
0x0000000000407036:     mov    0x60(%rsp),%r12
0x000000000040703b:     mov    0x88(%rsp),%rdi
0x0000000000407043:     mov    0x78(%rsp),%rbp
0x0000000000407048:     mov    0x70(%rsp),%rbx
0x000000000040704d:     jne    0x407054
0x000000000040704f:     test   %r13b,%r13b
0x0000000000407052:     je     0x40705b
0x0000000000407054:     movb   $0x1,0x2652d1(%rip)        # 0x66c32c
0x000000000040705b:     test   %r15b,%r15b
0x000000000040705e:     mov    0x48(%rsp),%r15
0x0000000000407063:     movb   $0x1,0x262677(%rip)        # 0x6696e1
0x000000000040706a:     jne    0x40707a
0x000000000040706c:     test   %r13b,%r13b
0x000000000040706f:     jne    0x40707a
0x0000000000407071:     mov    %r13b,0x26266a(%rip)        # 0x6696e2
0x0000000000407078:     jmp    0x407081
0x000000000040707a:     movb   $0x1,0x262661(%rip)        # 0x6696e2
0x0000000000407081:     movb   $0x0,0x26265b(%rip)        # 0x6696e3
0x0000000000407088:     callq  0x408f90
0x000000000040708d:     movzbl 0x26264e(%rip),%eax        # 0x6696e2
0x0000000000407094:     test   %al,%al
0x0000000000407096:     mov    0x58(%rsp),%r13
0x000000000040709b:     movb   $0x0,0x26263f(%rip)        # 0x6696e1
0x00000000004070a2:     mov    %al,0x26263b(%rip)        # 0x6696e3
0x00000000004070a8:     jne    0x4070af
0x00000000004070aa:     callq  0x406aa0
This code exists in the Rybka 1.0 Beta executable, 64-bit version. It "matches" Fruit 2.1, at least by my understanding of that word. I have removed my comments from it.
Reply by Shaun Brewer
Shaun Brewer wrote:A question and an observation...

What is this code for? - please don't tell me it's from the UCI parser....

This is a very small chunk of code - I would have thought a standard way of handling, say error trapping etc, could produce a similar size chunk of code that would exist in may programs? However this does depend on what the code is doing.

Shaun

orgfert
Posts: 183
Joined: Fri Jun 11, 2010 5:35 pm
Real Name: Mark Tapley

Re: The Evidence against Rybka

Post by orgfert » Tue Oct 04, 2011 4:41 pm

Uly wrote:So it looks like I'll need to crosspost between the fora :roll:
The reports are published. It seems rybka supporters are reduced to a claque of faineant lotus-eaters.

User avatar
lmader
Posts: 70
Joined: Thu Jun 10, 2010 3:22 am

Re: The Evidence against Rybka

Post by lmader » Tue Oct 04, 2011 5:47 pm

orgfert wrote: ... reduced to a claque of faineant lotus-eaters.
That cracked me up. Excellent words, claque and faineant.

hyatt
Posts: 1242
Joined: Thu Jun 10, 2010 2:13 am
Real Name: Bob Hyatt (Robert M. Hyatt)
Location: University of Alabama at Birmingham
Contact:

Re: The Evidence against Rybka

Post by hyatt » Tue Oct 04, 2011 7:43 pm

Uly wrote:So it looks like I'll need to crosspost between the fora :roll:
BB+ wrote:

Code: Select all

0x000000000040702e:     test   %r15b,%r15b
0x0000000000407031:     mov    0x50(%rsp),%r14
0x0000000000407036:     mov    0x60(%rsp),%r12
0x000000000040703b:     mov    0x88(%rsp),%rdi
0x0000000000407043:     mov    0x78(%rsp),%rbp
0x0000000000407048:     mov    0x70(%rsp),%rbx
0x000000000040704d:     jne    0x407054
0x000000000040704f:     test   %r13b,%r13b
0x0000000000407052:     je     0x40705b
0x0000000000407054:     movb   $0x1,0x2652d1(%rip)        # 0x66c32c
0x000000000040705b:     test   %r15b,%r15b
0x000000000040705e:     mov    0x48(%rsp),%r15
0x0000000000407063:     movb   $0x1,0x262677(%rip)        # 0x6696e1
0x000000000040706a:     jne    0x40707a
0x000000000040706c:     test   %r13b,%r13b
0x000000000040706f:     jne    0x40707a
0x0000000000407071:     mov    %r13b,0x26266a(%rip)        # 0x6696e2
0x0000000000407078:     jmp    0x407081
0x000000000040707a:     movb   $0x1,0x262661(%rip)        # 0x6696e2
0x0000000000407081:     movb   $0x0,0x26265b(%rip)        # 0x6696e3
0x0000000000407088:     callq  0x408f90
0x000000000040708d:     movzbl 0x26264e(%rip),%eax        # 0x6696e2
0x0000000000407094:     test   %al,%al
0x0000000000407096:     mov    0x58(%rsp),%r13
0x000000000040709b:     movb   $0x0,0x26263f(%rip)        # 0x6696e1
0x00000000004070a2:     mov    %al,0x26263b(%rip)        # 0x6696e3
0x00000000004070a8:     jne    0x4070af
0x00000000004070aa:     callq  0x406aa0
This code exists in the Rybka 1.0 Beta executable, 64-bit version. It "matches" Fruit 2.1, at least by my understanding of that word. I have removed my comments from it.
Reply by Shaun Brewer
Shaun Brewer wrote:A question and an observation...

What is this code for? - please don't tell me it's from the UCI parser....

This is a very small chunk of code - I would have thought a standard way of handling, say error trapping etc, could produce a similar size chunk of code that would exist in may programs? However this does depend on what the code is doing.

Shaun

Is there a reason you refuse to look at Mark's report? Just to make it simple, it is on page 16. I don't think I have ever seen a group that is lazier, or so far into denial that they pretend this report does not exist... Hint, it is NOT "error trapping." It is handling a particular sort of race condition when using the engine in a certain way. I could spell it out, but someone needs to learn to read at some point in time...

Probably a waste of time to answer, obviously, but one keeps the hope alive somehow...

User avatar
lmader
Posts: 70
Joined: Thu Jun 10, 2010 3:22 am

Re: The Evidence against Rybka

Post by lmader » Tue Oct 04, 2011 9:43 pm

People really do need to download the report. Here's the link for those that need it:

http://ilk.uvt.nl/icga/investigation/Ry ... y_ICGA.rar

The above mentioned code is in RYBKA_FRUIT_Mar11.pdf (inside the rar file), end of page 15, continues on page 16, as Bob mentioned.

Cheers,
Lar

BB+
Posts: 1484
Joined: Thu Jun 10, 2010 4:26 am

Re: The Evidence against Rybka

Post by BB+ » Wed Oct 05, 2011 5:26 am

What is this code for? - please don't tell me it's from the UCI parser....
I removed the comments, as it appears that's been called "fantasy code". Perhaps I should just give up trying. :roll:

This code snippet concerns the search calling and termination criteria. It happens to be located at the end of function that also does UCI parsing (and time management) in Fruit 2.1 and Rybka 1.0 Beta, but can also be placed at other locations in code. I think the corresponding part is in think in Stockfish -- indeed, one author found it quite odd that Fruit 2.1 would put it with UCI parsing in the first place (preferring modularity of parsing, time management and search control), let alone that Rybka would do the same. [Note that Fruit 1.0 differs slightly, but noticeably].

I would say that calling it "UCI parsing" is a bit of a stretch. However, it is indeed the case that the relevance of this particular code is mostly for probative purposes, rather than substantive. The value of probativity (in general) has been discussed elsewhere. As can be seen from the Rybka code snippet, there are various redundancies such as computing a value twice (and setting something false, when it must already be false). The same appear in the Fruit 2.1 code, which is indeed quite idiosyncratic in the first place. I used it as an example here because of its shortness and the inarguable nature that it came from Fruit 2.1, but now I see that something more weighty is desired. [Again I mis-interpreted the request, it seems -- can never please nobody about nothing].

A longer example is in Appendix A of RYBKA_FRUIT, which is also more substantive. I will put it in a separate post, with my explanatory notes (at the risk of this being called "fantasy code"). I should perhaps also stress that other "Fruit remnants" in this genre appear in various places in the Rybka 1.0 Beta executable (e.g, the hashing structure, the root search ordering); OTOH, I would say that by themselves these snippets are not as significant as the "evaluation overlap" finding, though they do serve to bolster the overall picture that the "origins" of Rybka 1.0 Beta were indeed in Fruit 2.1.
People really do need to download the report.
It is a bit annoying that there are still some who seem quite unaware of even the basis for the ICGA decision to disqualify Rajlich's entries [whether or not they agree with it]. This could be due to the information not being immaculately organised, though mis-information/mis-direction must play some part too. Perhaps if I find the time, I will write something briefly on this. The FSF guy was also interested in such a summary, but he then seemed to say that the current information was enough, so I never bothered.

BB+
Posts: 1484
Joined: Thu Jun 10, 2010 4:26 am

Re: The Evidence against Rybka

Post by BB+ » Wed Oct 05, 2011 5:59 am

Here is a commented disassembly from the Rybka 1.0 Beta 64-bit version. The code is the iterative deepening at the end of root search.

Code: Select all

0x4095a5: mov    $0x1,%esi            # %esi will be equal to 1 throughout
0x4095aa: mov    %esi,%ebx
0x4095b0: cmp    $0x5,%ebx            # compare depth to 5
0x4095b3: jb     0x4095c4             # if at least 5
0x4095b5: lea    -0x2(%rbx),%edx           then subtract 2 before...
0x4095b8: lea    0x25af79(%rip),%rcx  # 0x664538 ["info depth" string]
0x4095bf: callq  0x40d0b0             # ...printing the "info depth" string
0x4095c4: mov    %ebx,%ecx            # copy depth to %ecx reg for func call
0x4095c6: movb   $0x0,0x262e81(%rip)  # 0x66c44e set "change" to false
0x4095cd: movb   $0x0,0x262e78(%rip)  # 0x66c44c set "bad_1" to false
0x4095d4: callq  0x40ba70             # call search_full_root(ecx) [ecx=depth]
0x4095d9: callq  0x4070c0             # some sort of update function
0x4095de: mov    0x26706f(%rip),%r11d # 0x670654, get score
0x4095e5: cmp    $0xffff8300,%r11d    # fiddle around
0x4095ec: jle    0x4095fe             # ...
0x4095ee: cmp    $0x7d00,%r11d        # with mate scores
0x4095f5: movzbl 0x262e54(%rip),%edx  # 0x66c450 load "flag"
0x4095fc: jl     0x409601             # if mate score,
0x4095fe: mov    %sil,%dl               # set "flag" to true (esi is always 1)
0x409601: cmp    %esi,%ebx            # compare depth (%ebx) to 1
0x409603: jne    0x409631             # if depth == 1
0x409605: cmpl   $0x0,0x267058(%rip)    # 0x670664 think this is RML[1]
0x40960c: je     0x40962f               # if only one legal move, skip next
0x40960e: movzbl 0x262e3a(%rip),%ecx    # 0x66c44f "easy"
0x409615: mov    0x267449(%rip),%eax    # 0x670a64 (value of move 1)
0x40961b: add    $0x96,%eax             # EasyThreshold of 150 [as in Fruit]
0x409620: cmp    %eax,0x26743a(%rip)    # 0x670a60 (value of move 0)
0x409626: cmovae %esi,%ecx              # if move values differ by enough
0x409629: mov    %cl,0x262e20(%rip)       # 0x66c44f  set "easy" as true
0x40962f: cmp    %esi,%ebx            # if depth > 1
0x409631: jbe    0x40964d* [0x409647]             
0x409633: movzbl 0x262e12(%rip),%eax    # 0x66c44c  load old bad_1
0x40963a: movb   $0x0,0x262e0b(%rip)    # 0x66c44c  bad_1 = false
0x409641: mov    %al,0x262e06(%rip)     # 0x66c44d  bad_2 = (previous) bad_1
0x40964d* movzbl %dl,%eax             # %dl: 1@4095fe (mate), "flag"@4095f5
0x409650* mov    %r11d,0x262df1(%rip) # 0x66c448  last_value = score
0x409647: cmp    0x262cdb(%rip),%ebx  # 0x66c328  see if depth>=depth_limit
0x409657: cmovae %esi,%eax            # if depth >= depth_limit
0x40965a: mov    %al,0x262df0(%rip)     # 0x66c450  then "flag" is true
0x409666: mov    0x262cb3(%rip),%r8d  # 0x66c320 load SearchInput->time_limit_1
0x40966d: movzbl 0x262dd8(%rip),%r9d  # 0x66c44d  load bad_2
0x409660* callq  *0x139ca(%rip)       # 0x41d030  GetTickCount -> %eax
0x409675: mov    %eax,%r11d           
0x40967c* sub    0x262db5(%rip),%r11d # 0x66c438  (subtract StartTime)
0x409678: lea    (%r8,%r8,1),%ecx     # compute 3 * time_limit_1
0x409683: mov    $0xaaaaaaab,%eax     #  then mult by 2/3
0x409688: mul    %ecx                 #   (result goes in edx with mul here)
0x40968a: shr    %edx                 #  and div by 2 ... hmm = time_limit_1 ?
0x40968c: cmp    %edx,%r11d           # compare to time taken
0x40968f: jb     0x4096a6             # if small, ignore next
0x409691: movzbl 0x262db8(%rip),%ecx    # 0x66c450 "flag"
0x409698: test   %r9b,%r9b              # if "bad_2" is false
0x40969b: cmove  %esi,%ecx                # ecx = 1 (esi is always 1)
0x40969e: mov    %cl,0x262dac(%rip)     # 0x66c450 store ecx in "flag"
0x4096a4: jmp    0x4096ac
0x4096a6: mov    0x262da4(%rip),%cl   # 0x66c450 (reload "flag")
0x4096ac: mov    $0xaaaaaaab,%eax     
0x4096b1: mul    %r8d                 # mult time_limit_1 by 2/3
0x4096b4: shr    $0x2,%edx            #  and div by 4
0x4096b7: cmp    %edx,%r11d           # compare to time taken
0x4096ba: jb     0x4096d1             # if small, ignore next
0x4096bc: cmpb   $0x0,0x262d8c(%rip)    # 0x66c44f see if "easy"
0x4096c3: movzbl %cl,%eax               # if not "easy", then eax is "flag"
0x4096c6: cmovne %esi,%eax              # if it is "easy", then eax is true
0x4096c9: mov    %al,%cl
0x4096cb: mov    %al,0x262d7f(%rip)     # 0x66c450 store eax in "flag"
0x4096d1: shr    %r8d                 # time_limit_1 divided by 2
0x4096d4: cmp    %r8d,%r11d           # compare to time taken
0x4096d7: jb     0x4096f3             # if small, ignore next
0x4096d9: test   %r9b,%r9b              # if "bad_2" is true
0x4096dc: jne    0x4096f3               # then ignore next
0x4096de: cmp    %r9b,0x262d69(%rip)      # 0x66c44e "change", see if false
0x4096e5: movzbl %cl,%eax                 # if not, then eax is "flag"
0x4096e8: cmove  %esi,%eax                # if "change" is false, eax is true
0x4096eb: mov    %al,%cl                
0x4096ed: mov    %al,0x262d5d(%rip)       # 0x66c450 store eax in "flag"
0x4096f3: cmpb   $0x0,0x262d36(%rip)  # 0x66c430 see if "stop" is true
0x4096fa: jne    0x409714             # if so, then exit this function
0x4096fc: test   %cl,%cl              # see if "flag" is true
0x4096fe: je     0x409709             # if so 
0x409700: cmpb   $0x0,0x262c25(%rip)    # 0x66c32c and SearchInput->infinite
0x409707: je     0x409714               # is false, then exit this function
0x409709: add    %esi,%ebx            # increment depth (%esi is 1)
0x40970b: cmp    $0x48,%ebx           # if depth < 72
0x40970e: jb     0x4095b0               # then loop
The asterisks here denote instructions that I have re-ordered, typically when the ASM code starts laying the groundwork for the next high-level operation prior to the completion of the previous.

The corresponding code in Fruit 2.1 is at the end of search in search.cpp. Here it is with ASSERTs removed, slightly reformatted, and minor comments added:

Code: Select all

 for (depth = 1; depth < DepthMax; depth++) // DepthMax is 64
 { if (DispDepthStart) send("info depth %d",depth); // DispDepthStart is true
   SearchRoot->bad_1 = false;
   SearchRoot->change = false;
   board_copy(SearchCurrent->board,SearchInput->board);
   if (UseShortSearch && depth <= ShortSearchDepth) // UseShortSearch is true
    search_full_root(SearchRoot->list,SearchCurrent->board,depth,SearchShort);
   else
    search_full_root(SearchRoot->list,SearchCurrent->board,depth,SearchNormal);
   search_update_current();
   if (DispDepthEnd) send("[...]"); // a complicated construct, omitted here
   if (depth >= 1) SearchInfo->can_stop = true;
   if (depth == 1 && LIST_SIZE(SearchRoot->list) >= 2
       && LIST_VALUE(SearchRoot->list,0) >=
          LIST_VALUE(SearchRoot->list,1) + EasyThreshold) // this is 150
    SearchRoot->easy = true;
   if (UseBad && depth > 1) // UseBad is true
   { SearchRoot->bad_2 = SearchRoot->bad_1;
     SearchRoot->bad_1 = false; }
   SearchRoot->last_value = SearchBest->value;
   if (SearchInput->depth_is_limited && depth >= SearchInput->depth_limit)
    SearchRoot->flag = true;
   if (SearchInput->time_is_limited
       && SearchCurrent->time >= SearchInput->time_limit_1
       && !SearchRoot->bad_2)
    SearchRoot->flag = true;
   if (UseEasy && SearchInput->time_is_limited // UseEasy is true
       && SearchCurrent->time >= SearchInput->time_limit_1 * EasyRatio // 0.20
       && SearchRoot->easy)
    SearchRoot->flag = true;
   if (UseEarly && SearchInput->time_is_limited // UseEarly is true
       && SearchCurrent->time >= SearchInput->time_limit_1 * EarlyRatio // 0.60
       && !SearchRoot->bad_2 && !SearchRoot->change)
    SearchRoot->flag = true;
   if (SearchInfo->can_stop
       && (SearchInfo->stop || (SearchRoot->flag && !SearchInput->infinite)))
    break;
 }
Here is a translation of the Rybka 1.0 Beta code into a higher-level language, using the Fruit 2.1 code as a template.

Code: Select all

 for (depth = 1; depth < 72; depth++)
 { if (depth >= 5) printf("info depth %d\n",depth-2);
   change = false;
   bad_1 = false; // order is switched from Fruit -- might be the compiler
   search_full_root(depth); // yields "score" in a global var
   some_sort_of_update_function();
   if (score <= -32000 || score >= 32000) // mate scores
    flag = true;
   if (depth == 1 && RootMoveList[1].move != MOVE_NONE &&
       RootMoveList[0].value >= RootMoveList[1].value + 150) // 409601-40962f
    easy = true;
   if (depth > 1) // 409631-409641
    {bad_2 = bad_1;
     bad_1 = false;}
   last_value = score;
   if (depth >= depth_limit) // 409647
    flag = true;
   TimeUsed = GetTickCount() - StartTime;
   if ((3*time_limit_1)/3 <= TimeUsed && !bad_2) // 409691, has mult/div by 3
    flag = true;
   if ((time_limit_1)/6 <= TimeUsed && easy) // 20% in Fruit
    flag = true;
   if ((time_limit_1)/2 <= TimeUsed && !bad_2 && !change) // 60% in Fruit
    flag = true;
   if (stop || (flag && !SearchInput->infinite))
    break;
 }
There are indeed some differences (e.g. some numbers are modified, mate scores are included), but for comparison, I don't think I can get the Fruit 1.0 code to look quite so much like Fruit 2.1. One noteworthy Fruit/Rybka commonality is the use of bad_1,bad_2, change, easy, and flag, which are not in Fruit 1.0.. Also, as noted in RYBKA_FRUIT, the 6 variables are stored in the same way in Rybka 1.0 Beta as with Fruit 2.1, again a strong sign of the "origins" of the former (a similar variable-ordering congruence can be noted with the previous code snippet).

Code: Select all

struct search_root_t {
   int last_value; // 0x66c448
   bool bad_1;     // 0x66c44c
   bool bad_2;     // 0x66c44d
   bool change;    // 0x66c44e
   bool easy;      // 0x66c44f
   bool flag;      // 0x66c450
}
Here is the Fruit 1.0 code:

Code: Select all

   for (depth = 1; depth < DepthMax; depth++) {
      if (DispDepth) send("info depth %d",depth);
      board_copy(SearchCurrent->board,SearchInput->board);
      if (SearchType == SEARCH_PERFT) {
         SearchCurrent->node_nb = 0;
         SearchCurrent->leaf_nb = 0;
         my_timer_reset(SearchCurrent->timer);
         my_timer_start(SearchCurrent->timer);
         search_perft(SearchCurrent->board,depth);
      } else if (SearchType == SEARCH_MATE) {
         search_mate_root(SearchRoot->list,SearchCurrent->board,depth);
      } else if (SearchType == SEARCH_MAT) {
         if (UseShortSearch && depth <= ShortSearchDepth) {
            search_mat_root(SearchRoot->list,SearchCurrent->board,depth,SearchShort);
         } else {
            search_mat_root(SearchRoot->list,SearchCurrent->board,depth,SearchNormal);
         }
      } else if (SearchType == SEARCH_FULL) {
         if (UseShortSearch && depth <= ShortSearchDepth) {
            search_full_root(SearchRoot->list,SearchCurrent->board,depth,SearchShort);
         } else {
            search_full_root(SearchRoot->list,SearchCurrent->board,depth,SearchNormal);
         }
      }
      search_update_current();
      if (DispDepth) {
         send("info depth %d nodes " S64_FORMAT " time %.0f",depth,SearchCurrent->node_nb,SearchCurrent->time*1000.0);
      }
      SearchInfo->can_stop = true;
      if ((SearchInput->depth_is_limited && depth >= SearchInput->depth_limit)
       || (SearchInfo->can_stop && SearchInput->time_is_limited && SearchCurrent->time >= SearchInput->time_limit * TimeRatio)) {
         break;
      }
   }
Except for this last piece of Fruit 1.0 code, this all appears in Appendix A of RYBKA_FRUIT, and in a more readily readable format therein I would say.

This code is quite significant for probative purposes, and also has some substantial nature, in that it (e.g.) determines on what basis to start another search iteration.

Prima
Posts: 328
Joined: Tue Dec 14, 2010 6:12 am

Re: The Evidence against Rybka

Post by Prima » Wed Oct 05, 2011 6:23 am

orgfert wrote:
Uly wrote:So it looks like I'll need to crosspost between the fora :roll:
The reports are published. It seems rybka supporters are reduced to a claque of faineant lotus-eaters.
Good one, orgfert ;) .

Careful orgfert; if your opinion is contrary to Uly's [or the Rybka zealots], or you DARE exercise better judgment and an impartial objectives, he'll add you to his comical ignore list. Oh wait!.....there are no ignore lists gadgets here in OpenChess to shield him from facts & reality! It's only in Rybka forum :lol:

Yep, the art of using ignore list ought to somehow, erase the proven FACT that Rybka's plagiarized Fruit & Crafty codes, thus making Rybka original. Such intelligence, maturity, and..... self-delusion :lol:

hyatt
Posts: 1242
Joined: Thu Jun 10, 2010 2:13 am
Real Name: Bob Hyatt (Robert M. Hyatt)
Location: University of Alabama at Birmingham
Contact:

Re: The Evidence against Rybka

Post by hyatt » Wed Oct 05, 2011 2:47 pm

Mark, just to be contrary, I always thought your assembly comments were clear. And I had zero trouble figuring out what the * meant. I think there is one that is missing in that in your long eval asm, Ed found ONE instruction out of order. And he thought that proved that no one had carefully looked at the disassembly (apparently thinking that you did it by hand, rather than with a program? Who knows? Who cares?) In any case, you might as well give up trying to make it clearer and clearer. Clear does not work if people look at it with eyes closed, unfortunately...

wgarvin
Posts: 47
Joined: Thu Jul 01, 2010 3:51 pm
Real Name: Wylie Garvin

Re: The Evidence against Rybka

Post by wgarvin » Wed Oct 05, 2011 4:47 pm

hyatt wrote:Mark, just to be contrary, I always thought your assembly comments were clear. And I had zero trouble figuring out what the * meant. I think there is one that is missing in that in your long eval asm, Ed found ONE instruction out of order. And he thought that proved that no one had carefully looked at the disassembly (apparently thinking that you did it by hand, rather than with a program? Who knows? Who cares?) In any case, you might as well give up trying to make it clearer and clearer. Clear does not work if people look at it with eyes closed, unfortunately...
One instruction out of thousands, reordered by hand, does not mean anything.

During the panel discussions, I used the objdump bundled with mingw to make dead listings of Rybka 1.0 Beta and Rybka 2.3.2a. I found the evaluation functions in the listing and compared then to Mark W.'s annotated disassemblies. The instructions were a perfect match except for a couple of insns that he had re-ordered for readability reasons. This is so stupidly obvious that I'm surprised it has to be mentioned at all: nobody disassembles instructions by hand for more than a few bytes of code, there are tools for that. I used the same tool he used, and got the same instructions out. The interesting part of Mark's work was all in interpreting and annotating the disassembly.

If Ed (or anyone else) believes there are errors in the interpretation/annotation that Mark did, maybe they can pinpoint an error or two and then we can discuss them. So far, no one has found ANY errors in that work, that I know of. If anyone is going to cast aspersions on the RE abilities of Zach and Mark, or try to discredit the work they did, I think its fair to demand of that person that they back up their claims with some proof. They can't simply say "I don't believe your expert, but I'm not an expert either so I can't prove their work has flaws, but somehow I know it does."

Post Reply