flat assembler
Message board for the users of flat assembler.

Index > Main > Optimizing - is it true?

Goto page Previous  1, 2, 3
Author
Thread Post new topic Reply to topic
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias 13 Mar 2005, 09:23
S.T.A.S. wrote:
That's all. Is AND a boolean operatoir in this context?
That's why I say that XOR is arithmetics too.


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 Smile
Post 13 Mar 2005, 09:23
View user's profile Send private message Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2139
Location: Estonia
Madis731 13 Mar 2005, 20:29
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.
Post 13 Mar 2005, 20:29
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
S.T.A.S.



Joined: 09 Jan 2004
Posts: 173
Location: Ru#27
S.T.A.S. 04 Apr 2005, 23:31
tom tobias, thanks for the link. But what about addition in Galua Fields like GF(2**n) ? ;)
Post 04 Apr 2005, 23:31
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 05 Apr 2005, 00:06
Quote:
[...]EASILY understood by a team of programmers [...]

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 Smile
Post 05 Apr 2005, 00:06
View user's profile Send private message Visit poster's website Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias 05 Apr 2005, 12:29
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. Confused
Post 05 Apr 2005, 12:29
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8353
Location: Kraków, Poland
Tomasz Grysztar 05 Apr 2005, 12:41
tom tobias wrote:
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.

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.
Post 05 Apr 2005, 12:41
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.