Rebel wrote:bob wrote: An example from the Rybka forum. Ed stated categorically that I could not reverse engineer anything, in spite of programming in assembly language for 43+ years now, in spite of having written more than one compiler from scratch. And in spite of helping debug some of the gcc long long code when I started to use that compiler for Crafty in 1994. He picked out a piece of code from Zach's report and asked me to "identify the offset into the rybka binary where this code is found." Not only did I do that, I broke the assembly language code down, after locating it, and matched it up line for line with the C code given in Zach's report. Ed then claimed the test was no good, that I had cheated because the code had 4 if-tests and I just looked for 4 test instructions and "hoped it matched." Even though I had matched the asm line for line with the C to SHOW that it matched, EXACTLY.
Since when is semantics proof for code ?
Er, since FOREVER? When you compile a source, you get the semantic equivalent of that source, in the form of the executable. computer science 101.
You were asked to identify the backward pawn evaluation in the Rybka 1 executable, you found semantics and ASSUMED the code was about the evaluation of backward pawns. That code could mean anything.
As I told you there, I did not ASSUME anything. I cranked the program up under the debugger, let it run, interrupted it, and then dumped the variables in question. As I said CLEARLY, the first one I examined were the ones that hold the bitboards for the pawns, they are pre-loaded at the top of pawn eval. It is pretty easy to recognize that a 64 bit value would have 8 bits on the 2nd rank for white pawns, and 8 bits on the 7th rank for the black pawns, don't you think? In the first if statement (I think) the first argument points to a 64 bit value with 1 bits set on adjacent files that are behind the current pawn's square. I told you that. You could verify it yourself, you DO have a MS debugger, don't you?
That's what hung me up for an hour or so, I saw the right masks and things, but there were only 3 subs. Until I FINALLY noticed that in Zach's code, the second sub after the else was not attached to the else, even though the indenting suggested it was. This is not a hard thing to do.
My standards are a bit higher than yours.
Obviously not. You don't read what I write, nor try to understand it. I didn't guess, I looked. It was easy enough, as I had previously told you. I spent more time formatting my post than I did uncovering the data, since I already knew where pawn eval code was...
Assembler is a language like English, French, Dutch are languages. An average human knows about 10,000 words. Assembler is about a few: mov, add, sub, comp, test, jumps mainly. Semantics with such a limited vocabulary is expected everywhere.
Furthermore Fruit and Rybka are talking a different language Mailbox vs Bitboard which makes the use of semantics laughable. Just look left vs right in Zach's document regarding backward pawns, it's totally different.
If you don't know what you are looking for. But what is the chances that the programs both do the same things, in the same order? You said order counted. Pawn eval for both match in the order. Recanting your opinion now???
What you need to proof is "copied code", not sematics.
Aha. You REALLY do not "get it." Look up and understand semantics first. If a compiler doesn't produce a binary that is the semantic equivalent of the original source, the compiler is no frigging good... Since the binary will not do what is expected... jeez your knowledge is lacking here. REALLY lacking...
