flat assembler
Message board for the users of flat assembler.
![]() Goto page Previous 1, 2, 3, 4, 5, 6, 7, 8 Next |
Author |
|
tom tobias 18 Jul 2007, 11:18
In all of FASM, how many times does XOR appear, with more than one operand?
|
|||
![]() |
|
FrozenKnight 18 Jul 2007, 12:14
AMD 32 bit Software Optimization Guide you asked for a reference here it is
section 8.4 page 128. Quote: Optimization I also found http://srl.cs.jhu.edu/manuals/24896612.pdf page 73 which makes a similar reference but I'm not sure it;s straight from intell. Do i really need much more proof. these guys design the chips. just cause you don't see their logic doesn't mean they don't design it that way. and you need to take a class on logic design if xor wasn't treated this way logic design would fall apart. |
|||
![]() |
|
vador 18 Jul 2007, 13:00
Someone wrote:
Quote:
IMHO we are talking here about binary executables. the reason we write a program is more for it to be EXECUTED by a binary machine, than for it to be READ by a decimal human again, everyone has his own opinion |
|||
![]() |
|
tom tobias 18 Jul 2007, 13:16
AMD ...optimization guide, from reference above by FrozenKnight wrote: .... This is a strange explanation. I doubt that AMD, or Intel, or any other cpu manufacturer has constructed a device which INCORRECTLY zeroes a register, upon issuance of the command, mov Reg, zero. FrozenKnight wrote: ...Do i really need much more proof. these guys design the chips. just cause you don't see their logic doesn't mean they don't design it that way.... vid wrote: On x86, the XOR instruction is intended to flip bits in numbers, ... Intel 486 Programmer's Reference Manual wrote: XOR-Logical Exclusive OR: Opcode 33/r, 1/2 clocks; [for 32 bit registers as both operands]: What is our goal? My goal is to write PROGRAMS which are READABLE. If you goal is to generate OBSCURE CODE, then you SHOULD USE XOR, not simply because it is ILLOGICAL (hence difficult to comprehend) to employ a boolean operator to act on a single operand, but because of the UNKNOWN, UNSEEN, and more importantly UNDOCUMENTED effect on several flags (undocumented within the source code). What could be better for writing CODE, than to ensure that a single instruction has consequences which will be overlooked by someone reading it? CODE is supposed to be obscure, cryptic, and unfathomable. With regard to my question about the quantity of times that FASM code (and I do mean CODE) employs XOR, NOT as a mathematical tool, but simply to clear a register, with some advantages in terms of affecting certain flags as well!!!, I sought to illustrate the fact that FASM "almost never", i.e. NEVER, uses XOR properly, as the mathematician originator intended it. George Boole sought to EXPLAIN logic, not conceal it. FASM source code ought, in my opinion, exclusively employ logical, readable instructions, in the best tradition of mathematicians throughout the world. |
|||
![]() |
|
tom tobias 18 Jul 2007, 13:46
someone, in this case, named 'vador' wrote:
One does not write assembly language programs simply as a mechanism to generate mere executables. One writes with Assembly language because it is the language of the cpu. OF course, ABSOLUTELY, one writes assembly language programs IN ORDER THAT SOMEONE can read them. But, just for the sake of argument, let us suppose you are correct, and I am in error. Then, what is the logical inference of your statement: In my opinion, the logic of your statement is this: It does not make any difference HOW one writes the program, what matters is ONLY THE EXECUTION time, and/or memory useage required. Bravo. Good sentiment. The year is 1964, and you are the head of computing at Stanford or Princeton or Cambridge or Oxford or wherever. Excellent rationale. Half a century ago, when memory was astronomically expensive, your argument would win, over mine, hands down. You will next argue, "correctly" in terms of mid 1960's era thinking, that SAVING MEMORY is CRUCIAL, and by reducing the SIZE of the program, we are saving lots of memory. So, using an instruction like XOR, WHICH ALSO affects several flags, THEREBY REDUCING the number of "unnecessary" additional instructions, which would have been required upon using MOV, to regulate those same flags, SAVES lots of precious bytes, AND reduces execution time, from 300 nanoseconds to only 260 nanoseconds, oops, forgot, this is 1964, ok, 300 milliseconds to only 260 milliseconds. And, since we only have ONE computer for 300 worker bees in 1964, then, we need not worry too much about writing PROGRAMS that can be understood by many people working independently on different machines, in different countries, because (a) there is no internet in 1964, and (b) there is so much to do, and so little space in which to do all the work, that no one is working TOGETHER, each person is instead, working on his/her OWN project, so there is no one to help, no one to collaborate with, and certainly no one to educate, about one's source code, therefore, the READABILITY of the source code is UTTERLY IRRELEVANT, in 1964. Except, "someone, named 'vador'", aka Rip van Winkel, http://en.wikipedia.org/wiki/Rip_van_Winkle WAKE UP, it is fifty years later. Things have changed. MEMORY is free now. Cpu clocks are 10,000 times faster than 1960. Computers are ubiquitous, the stove and refrigerator have more powerful cpu's than MIT, Princeton, or CAL TECH had in 1958. READABILITY is 1000 times more important, economically, than execution speed. |
|||
![]() |
|
FrozenKnight 18 Jul 2007, 13:50
if your point is to make readable code go write a visual basic program, the whole point of using asm is for speed ans size. and this means using any tricks in your arsenal. if you need a 512 byte boot sector use asm if you need to pus your computer to it's limits and get the best performance out of it use asm. if not use another language. Basic was created for that purpose, as were C and C++. i came into asm to fins out what what my computer was capable of doing and to push it into doing some things it isn't. part of that was to learn to write protection methods that would fool hackers. learning methods of using unperfected code so someone who doesn't want spend 5 min on google looking up code or evaluating a op-code was not my intent. asm is inherently a language for thinkers so i hope that those who use it can figure out something as simple as "xor eax, eax" otherwize i dont believe this is the language for them.
xor is inherently faster than mov and smaller. however on older cpu's if you had written to the register you were using xor to zero the cpu would wait for the memory to refresh and read just before it would preform the zero. thus taking away hte advantage of using xor and costing you 3 times as much time as normal 1.5 times as long as mov. but newer cpu's have eliminated this fals read and this is no longer an isue. making xor preferable over mov in all cases. |
|||
![]() |
|
tom tobias 18 Jul 2007, 14:03
FrozenKnight wrote: ...i hope that those who use it can figure out something as simple as "xor eax, eax"... |
|||
![]() |
|
vador 18 Jul 2007, 14:08
A man of the 21st centure wrote:
Quote:
This is the excuse why microsoft created .NET! so you agree with them? OK, ok, you may be right. But just answer this question: if you wanted readability, wouldn't it be simpler to use the VB statement: a=0 ? |
|||
![]() |
|
FrozenKnight 18 Jul 2007, 14:15
Quote: I sought to illustrate the fact that FASM "almost never", i.e. NEVER, uses XOR properly, as the mathematician originator intended it. George Boole sought to EXPLAIN logic, not conceal it. if the first person who figures our something gets it right on his first pass then the would would be much easier. and the word test would be required to be removed from our vocabulary. as time passes mathematics evolve this includes "George Boole" work and even to this day i expect to see it continue to evolve. but as it stand the term you defined i believe is currently on the books as nand (not and) not xor. math changes given time you need to accept that. and readability in source code is what comments were created for not mov instructions. mov is a memory management instruction get it straight. and sometimes 5us does make a difference especially in an infinite loop. |
|||
![]() |
|
FrozenKnight 18 Jul 2007, 14:22
Quote: ONE SOLITARY genuine XOR with two different register operands, mixed in. EAX, and EDX don't look very similar, here, on this forum, but on a long page of source code, intermingled with dozens of other ECX's and so on, it will be very simple to overlook the fact that a simple typographic error resulted in a very difficult bug. i would assume anyone writing assembly code would have the ability to read and debuggers output. and even single step (if necessary) through that difficult part and see his bug or error. besides it's uncommon to use more chain one or 2 xor's in a row except in encryption and then you usually have several models laid out and can find the error by output. Quote: Neglecting the obviously elitist nature of your commentary (not everyone arrived on the planet earth with the inherent, innate facility to read assembly language--some of us had to work to understand it...) Yes that is the point, because you wanted to be lasy and not learn the language for which you were trying to read. you expect everyone else will be that way. unfortunately i don't care about those reading the code only those using it. those reading it can be astonished by my work if they choose, most of which can be cut and pasted into theirs if needed anyway. i would rather giver courtesy to those poor souls who cant afford the 15ghz machines with 250tb of ram and infinite size hd's with video cards that can render at oc1 in real-time. by gaining the habits of writing tightly compact fast code from the start i have these optimizations fixated in my mind, I no longer think about them when writing them or reading them thus it has become both an optimization for both myself and my program. those why want to decipher my program will have to learn to think as i did which i thought was the goal of reading source code anyway. Last edited by FrozenKnight on 18 Jul 2007, 14:33; edited 1 time in total |
|||
![]() |
|
LocoDelAssembly 18 Jul 2007, 14:26
Even more, why consider it only boolean set operator? It also acts as a polinomial modulo 2 adder as well (see CRC literature about this). By using the same operand it adds every polinomial quoficient with itself (multiplies them by two), so "(0 + 0) mod 2 = 0" or "(0 * 2) mod 2 = 0" and "(1 + 1) mod 2 = 2 mod 2 = 0" or "(1 * 2) mod 2 = 2 mod 2 = 0".
Quote: What nonsense. Please provide a REFERENCE. Already explained. The CPU has special circuity to know that the register will be cleared so that instruction will not create a dependence and aditionally it takes only two bytes and not 5. I know computers nowadays has lots of RAM but the CPUs stills has problem to decode many instructions at the same time when them are long. PS: And I forgot to say, since every quoficient is one bit it can be seen as a substraction of one polynomial with itself (0 - 0 = 0; 1 - 1 = 0). Well, actually the quoficient can be of any length when both operands are the same but if it is not the case the substraction can be implemented with a XOR if it is one bit only. Last edited by LocoDelAssembly on 18 Jul 2007, 14:58; edited 1 time in total |
|||
![]() |
|
tom tobias 18 Jul 2007, 14:54
LocoDelAssembly wrote: Even more, why consider it only boolean set operator? Perhaps I am in error, (again), but, in my opinion, the focus of this thread is on the virtues and pitfalls associated with employing XOR to clear a register, rather than some other method. It is not a thread, so far as I am aware, on the virtues and pitfalls of XOR per se. LocoDelAssembly wrote:
So, friend, do you suppose that my argument would be further WEAKENED if MOV required FIFTY bytes, instead of only FIVE???? Again, perform the test: Replace all of the XOR instructions in FASM, with MOV instructions, and MEASURE the time required to assemble the altered version, rather than the XOR version. There may be some modest difference, some slight difference, even, perhaps some measureable difference, HOWEVER, EVEN IF YOU MULTIPLY BY TEN, the number of MOV instructions, for each XOR that you replace, i.e. INSERT ten unnecessary mov EAX, Zero, MOV EBX, Zero, MOV ECX, Zero, etc, you STILL WILL NOT BE ABLE TO PERCEIVE a difference. Run the same program on two different computers if you like, side by side, same cpu and memory of course, one version with XOR, the other with MOV (x10 extra MOV for each XOR replaced), and you will not DETECT the difference. There will be a difference, one will be slower. It will simply not be perceived as running slower. One will execute in 430 milliseconds, and the other will execute in 660 milliseconds. For the human brain, those times are identical. |
|||
![]() |
|
LocoDelAssembly 18 Jul 2007, 15:12
Quote: Replace all of the XOR instructions in FASM, with MOV instructions, and MEASURE the time required to assemble the altered version, rather than the XOR version For what? Who cares about this? I'm caring about execution time not assembling time. Quote: One will execute in 430 milliseconds, and the other will execute in 660 milliseconds. For the human brain, those times are identical. Then you are supposing that the code it is not in a loop that executes lots of times. Suppose that the code is inside of some loops in programs like Prime95. Do you think that the difference will be of just few milliseconds? |
|||
![]() |
|
tom tobias 18 Jul 2007, 15:21
FrozenKnight wrote: ...unfortunately i don't care about those reading the code only those using it. ... May I refer you in sincerity to the classic textbooks of Donald Knuth. The goal of reading source code, fundamentally is to help those who are collaborating with you on some project. Obviously, if you alone are working on something which no one else will read, then, it is irrelevant how or what you write. One does not, conventionally, attempt to understand how someone is THINKING, by attempting to comprehend the source code. Rather, one's thoughts, generally, not always, but USUALLY, have been clearly elaborated in the DOCUMENTATION, which OUGHT to precede the code generation. It is in the documentation portion of any program that one elaborates both the nature of the program, its purpose, its organization, and its structure, in particular, the ALGORITHM, and the DATA STRUCTURES. Djikstra and Wirth are the two Europeans whose research efforts best describes this process. These features of documentation proceed INDEPENDENTLY of the particular language used to implement the algorithm. Of course, if you seek only to play games, or build viruses, then, it is not necessary to learn how to program. If you seek, on the other hand, to learn how to write commercially viable software, then, you are on the wrong track, and need to study a tiny bit more theory, instead of seeking to ridicule those who may have as much experience as you do in writing garbage. His brain, apparently still frozen, FrozenKnight wrote:
|
|||
![]() |
|
mattst88 18 Jul 2007, 17:24
Good lord, stop replying.
He's just doing it for kicks. Anyone smart enough to be able to quote many various books is also smart enough to understand what we're saying. |
|||
![]() |
|
FrozenKnight 18 Jul 2007, 19:56
At least those who use my garbage on a 350mhz comp can still enjoy it just as much as those with a 2ghz machine. and i don't write viri it's against my religion LOL. (however, i do know how.
![]() and i know he's just arguing for fun so am i, i'm bored and needed to do something. |
|||
![]() |
|
rugxulo 18 Jul 2007, 22:14
tom tobias, of course you have a point, in general, but not for XOR. If you don't like "xor eax,eax", use search / replace to change it. (Some assemblers, like Octasm, support "eax=0" anyways). Or use macros. It is indeed barely but indeed needed (if not usually wanted) in preference to bloatier / bigger alternatives.
If things like "xor eax,edx" might confuse you, again you can use search / replace (text editor, sed, whatever): "s/edx/EDX/g", and it will still assemble correctly. Or use macros. Or HLLs. Or some personal tweak of your favorite editor's syntax highlighting. Or whatever. Certainly, the bigger problem is lack of comments, weird non-standard syntax (AT&T? Intel? other??), interfacing with trillions of HLLs and OSes, plus just really confusing stuff (like what Loco was saying, sheesh). Assembly (and programming in general) is non-obvious and not easy. I think XOR is the least of our problems these days (LIDT, LOCK, CVTSD2SI or whatever, etc). |
|||
![]() |
|
MichaelH 18 Jul 2007, 23:41
mattst88 wrote: Good lord, stop replying. I think you're hit the nail on the head but I don't think tom does it for kicks rather to bore it into our brains that readability, documentation etc are crucial elements of code. I like the non relenting approach he takes as there are few teaches that teach this in the programming world, resulting in never ending non readable code. So as I've posted before, good job tom, keep up the good work. |
|||
![]() |
|
LocoDelAssembly 18 Jul 2007, 23:48
Quote:
Modular arithmetic Sorry, I can find the CRC explanation that clearly shows what I said about polynomails. I agree that is confusing compared to just think of it as a logical operator, but since tom tobias dislikes logical operations to clear a register then I tried to show a mathematical (non logical) approach to see the operation that XOR performs. |
|||
![]() |
|
Goto page Previous 1, 2, 3, 4, 5, 6, 7, 8 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.