http://www.bbc.co.uk/dna/h2g2/A412642

Madis has a different problem: he references the quantity of clock cycles needed to execute particular instructions, notwithstanding INTEL'S explicit rejecton of the ability to predict execution times since the 486. BUT, to avoid arguments about clock times, (and I think the number of clock cycles for a 32 bit mov instruction is the same or fewer than for ANY boolean operator, but, let's suppose for sake of argument that Madis is correct, and I am wrong), I WILL GRANT MADIS a TEN fold DECREASE in execution time, by misusing XOR for a non Boolean operation, instead of properly employing MOV, and still argue that Madis' supposed savings in execution time, EVEN for a LARGE program of thousands of such instances of supposed savings by using the WRONG instruction to save time, DOES NOT SOLVE the main problem: GETTING the product to market in order to make money. THAT problem is not one of HOW FAST does the program execute, but rather, how long does it take for a team of programmers to create ANY solution, whether it is VERY FAST, EXTREMELY FAST, or only moderately FAST. GETTING A SOLUTION to the marketplace QUICKLY is quite different from tweaking a particular routine to execute 89 picoseconds quicker than a longer executing solution that however, is EASILY understood by a team of programmers. USE xor for BOOLEAN operations ONLY. Then, readability is markedly improved, and the product reaches the marketplace quicker. For those who disagree with me: TWO phrases: (1) FRESH, (2) FASM manual. End of sermon. Regards, tom

Yes, I understand you and agree on 100%, but the aim of making this topic was not the market but more of "The Interesting Idea" of optimizing little amount of code if in ideal world writing optimized and non-optimized code would take the same amount of time and code.

I just wanted the theory (and maybe some practice) behind it.

tom tobias, thanks for the link. But what about addition in Galua Fields like GF(2**n) ? ;)

Any programmer who has worked with x86 assembly for just a tiny amount of time shouldn't have any confusion from "xor reg, reg", really. It's true that premature optimization is the root of all evil, and it's stupid to micro-optimize all of your code (stick to the "10% that runs 90% of the time" or whatever). But really, "xor reg, reg"? That never hurt anyone

HI STAS, sorry, haven't a clue about Galua Fields, so I cannot comment on their suitability for inclusion with this thread. The reference I provided, originating in Britain, seeks to elaborate the definition of Boolean operators. Since Boole was British, I thought it appropriate.
The topic of this thread is OPTIMIZATION.
In general, when one speaks or writes about IMPROVEMENT of an Assembly language program, one implies DECREASING execution time. Historically, the XOR instruction acting upon a single register
executed faster in the original x86 architecture, than the mov instruction, hence, the tradition developed, a quarter century ago, of MISUSING the BOOLEAN operator XOR, to clear a register,(i.e. misusing because XOR of a single register has the mathematical consequence of leaving the contents of the register cleared--zero,) thereby reducing execution time, hence, "OPTIMIZING". XOR is NOT an arithmetic operator. I introduced, QUITE PROBABLY OFF TOPIC, a notion somewhat at variance with the original thread on optimization: i.e. the concept of OPTIMIZATION by virtue NOT of a decrease in exection time, but rather an INCREASE in readability, hence a decrease in IMPLEMENTATION time. Fudder, among (many) others, I am sure, suggests that "Any programmer who has worked with x86 assembly for just a tiny amount of time shouldn't have any confusion from "xor reg, reg", really."
Ok, Fudder, I agree with you. YOU ARE ABSOLUTELY CORRECT, and I am wrong. Yes, ANYONE who has ever spent 20 minutes looking at ASM code, will figure out, even with improperly undocumented code, that XOR EAX, EAX means, MOV EAX,ZERO. However, I was not writing from the perspective of one who is working alone, WRITING code, but rather from the perspective of one who is working with a TEAM of several programmers, attempting to READ and understand what each of the various team members seeks to accomplish. In that context, BELIEVE ME, it is much easier to read someone else's code if the following TWO rules are applied rigorously by all members of the team:
(1) SIMPLIFY
(2) Obey rule number 1.
It is not simpler to read XOR EAX, EAX, understanding that this instruction means reset a register to zero, IF THE CODE ALSO CONTAINS bonafide situations requiring BOOLEAN OPERATIONS, for example,
XOR EAX, EBX.
In that setting, one must now visually discriminate two VERY different situations, which differ by ONLY one letter of the Roman Alphabet. If one is scrutinizing page after page of code, much of it POORLY documented, and ALL of it completely obscure, then, it is not uncommon in a state of fatigue, to MISS this single letter substitution, and spend DAYS trying to locate the error. Sorry for the off topic ranting.

Though my point of view was always more like the f0dder's one in this case, I see now what you mean and it's hard not to agree that this is also a good point. It's also appears to be related somehow to my reason why I prefer order of arguments in Intel syntax (destination first) over the others - when reading the code it makes easier to read (with the usual assembly language indentation, of course) at first look which registers are modified by some piece of code.