flat assembler
Message board for the users of flat assembler.
Index
> Main > XOR EAX,EAX Goto page Previous 1, 2, 3, 4, 5, 6, 7, 8 Next |
Author |
|
okasvi 13 Dec 2006, 18:18
Raedwulf wrote: For crying out loud!, who doesn't know what xor eax, eax does, who's spent at least a few months programming assembly!!!!!!!! When you find him, tell us about him so we can have the laughs too... edit: no offence meant to anyone, it's perfectly understandable that beginners might not know about it. _________________ When We Ride On Our Enemies support reverse smileys |: |
|||
13 Dec 2006, 18:18 |
|
Goplat 13 Dec 2006, 18:53
Raedwulf wrote: remember to leave your C-compiler on /Od (MSVC - Disable all optimisations) or -O0 (GCC), so it generates less cryptic assembly language I've actually found that assembly code from gcc is easier to read with some optimizations. At -O0 it doesn't even do register allocation, so you end up with tons of redundant movs. |
|||
13 Dec 2006, 18:53 |
|
smiddy 13 Dec 2006, 20:55
tom tobias wrote: Zero has always been the most fascinating of all integers. It was only recently invented, (less than two thousand years ago, a microsecond in human evolutionary terms,) well after the discovery of other numbers. So far as I am aware, it is one of many arithmetic discoveries from the Indian subcontinent, though perhaps this is not correct, and it comes in fact from Persia. I am not sure. The Mayas discovered the number zero, and the uses to which it could be put, centuries before it was discovered in Europe or Asia. Electrical ground and or neutral are not always seen or interpreted as zero, most times in complex systems zero potential is actually refered to as a one, since the likelyhood of a zero is greater than a one. This potential kept at a high dampens the effect of ground bounce and is generally better for multibused circuits. Saying no measureable voltage too is a relative thing. I've created and used instruments that will measure voltage at the pico potential. But, that is not your point, and I'm nit-picking for sure here... tom tobias wrote:
Wow, a pun, ambiguous, but none the less a pun, you joker! I think though if the intention is to squeeze more uses out of your intended goal, the boolean approach might make sense but that has to be given as the the engineering being done and to what application. Though, I mean to be pragmatic. tom tobias wrote: Comments, cher Raedwulf, ought to explain WHAT the code is doing, not HOW to decipher the code into readable text. In other words, the comments ought to explain WHY we are testing the value of the register, (i.e. the value of the flag), not simply informing us of the fact that we are ACTUALLY ONLY testing a Register's value, rather than performing a Boolean operation on the Register, counterintuitively, since both the name and the function of the instruction, suggest the latter. Again, this is a question, first and foremost of whether or not one is writing CODE for one's own interest, one's own project, or one is participating in a GROUP effort. If for oneself, fine, write anything, no problem. But, if one hopes to have a GROUP understand this task, it better be written in the EASIEST POSSIBLE manner. The single most important aspect of attaining success on any GROUP project, is readability. I don't have an arguement here, I agree. Though your prose have a runeth-over when written, which seems to lump all you thoughts together, leading into... tom tobias wrote: For assembly language programming, please do not waste your time, trying to save memory or decrease execution time (especially NOT in a boot loader, Smiddy!!!). I suppose I have no choice but to respond to this...later. tom tobias wrote: Make your PROGRAM as user friendly as possible, by emphasizing the EXTRA instructions, which make it possible for someone other than yourself to understand what you are trying to accomplish. The obsolete 512 byte limit is just that. OBSOLETE. Forget it. Readability is the MOST important feature in today's world, with the international community obliged to use English. Give folks all the help you can, by making your code as simple to understand as possible. Yes, 512 bytes is a legacy issue but it is still relivent and to some a requirement. Not everyone is on the bleeding edge of technology within (as I assume most are here) their hobby (at least for me this is true). If you impose a requirement that you have to have a FAT 12 compatible boot loader that is to remain within 512 bytes, that is a good and practical requirement. That requirement drives how you write the application to load your application. It is valid! Is it part of today's technical front end, no. Learning and emulating historical technologies helps to learn where we've been and how we got to where we are currently. tom tobias wrote:
It really depends on the controller, but you know this already. It also depends on what you're doing too. If you look at the x86's initial archetecture and design the CPU (where BTW all the mov, pop, stc, etcetera happens, regardless of memory), the sensing of address lines and it was one clock cycle per sense, but there are a lot more thing happening today and you can get multiple reads per clock cycle, however it should be transperant to the CPU and essentially you are correct, from a high level. tom tobias wrote: Let's suppose I am WRONG. Then what? I don't care. I certainly will not change my thinking about the critical importance of writing PROGRAMS instead of CODE, just because the MOV instruction requires 489 more nanoseconds to decode than XOR. Well, I won't suppose you are wrong, I will suppose that your opinion is important and requires review. I also think you do care! Otherwise why write? I get the gist of this, but I suspect you have to write more to support what you mean as far as CODE or PROGRAMS (APPLICATIONS). But what you've written seems to be an over simplification. Please start a new thread entitiled Code and/or Programs or something similar. I suspect those reading your writing don't fully grasp the meaning you're trying to portrait. tom tobias wrote:
Pragmatism is something that has energy and will continue to survive/thrive. It is that approach to problem solving that continues to improve and make technology what it is today. Nothing is entirely black or white. There is a fair amount of gray to everything. I don't think your ethememe works, misusing instructions equates to convention therefore is laziness therefore is not proper conduct. Especially since the truth if even further from the analogic arguement you present. But then again, I digress... My point is it depends on the situation in which you are in to use the tools you have in order to solve problems. You don't write code/programs/applications without having a problem to solve. If your problem is to catch fish to survive, you will devise a way to muster it. The way you're doing it now has to change because now the paradigm has changed, the fish have moved or gotten smart to your way of doing things, so you're forced to solve another problem. Then, it gets to the point where you no longer just survive, you're thriving. Now you get ambitious and you want to thrive even more, so now your problem changes and you come up with further different ways to handle what your goal is. The point is, you have to think about the goal in order to satisfy the goal, and you'd use the tools avialable to satisfy that goal, no matter how. If convention got you there, there is no harm in using that convention...conventions are no the root of all evil. |
|||
13 Dec 2006, 20:55 |
|
Plue 13 Dec 2006, 21:07
If you want readable programs you don't chose assembly. If you want fast programs you chose assembly. If your main concern is readability, then you're using the wrong language.
If you want the most efficient program without compromising readability create a macro named CLEAR <register> to expand into XOR <register>, <register>. |
|||
13 Dec 2006, 21:07 |
|
gunblade 13 Dec 2006, 21:37
Hah! And I thought tom wrote long posts.. that's got to have taken you a while to write smiddy
I just felt like saying that I agree with the comment that comments should be used to describe what the code is doing. If you are coding in assembly, then odds are you're coding in assembly for a reason: size, speed, low level hardware access. Therefore it is more important for the actual executable created to be as optimized as possible, rather than "readable" (in the executable). That last line didn't make as much sense as i hoped it would, what I mean is: by using more "readable" opcodes, you are causing the executable to actually contain extra code for nothing, it would be like adding debugging symbols to the binary (which would be fine for debugging, but not for the final output). The binary does not need to be readable, that is why comments, which aren't put into the binary, are better used for readability. That way you get readable code, without the disadvantage of a bigger/slower binary. Apologies for the bad grammar. Edit: Just read that post above me by Plue. He actually make a good point, if you want readable, but still using the more efficient versions of the instructions, why not just use a macro? It'll add clarity with no side-effects to the final binary. Nice one Plue! |
|||
13 Dec 2006, 21:37 |
|
r22 13 Dec 2006, 22:17
CLEAR <register> isn't nearly readable enough!
Someone might assume you are making the register transparent or invisible somehow. SET_ALL_BITS_IN_THIS_REGISTER_TO_ZERO <register> now that's a macro name we can ALL understand. |
|||
13 Dec 2006, 22:17 |
|
vid 13 Dec 2006, 22:22
tom: just one little thing (again). x86 instruction "and" is NOT same as boolean operation "and"
|
|||
13 Dec 2006, 22:22 |
|
Tomasz Grysztar 13 Dec 2006, 23:08
vid wrote: tom: just one little thing (again). x86 instruction "and" is NOT same as boolean operation "and" It IS a boolean operation in a sense of general mathematical definition. The Boolean algebra may be built on a set larger than two elements. In fact the boolean algebra of 32-bit words with AND and OR operations is isomorphic to the algebra of the power set of some 32-element set, with the intersection and union operations. |
|||
13 Dec 2006, 23:08 |
|
vid 13 Dec 2006, 23:23
and how does setting / clearing particular flags fit into your isomorphic boolean algebra with the intersection and union operations blah blah?
|
|||
13 Dec 2006, 23:23 |
|
Tomasz Grysztar 13 Dec 2006, 23:35
It's an intersection or union with a singleton.
And I forgot to add that negation transforms by that isomorphism into operation of taking a complementary set... The idea of this isomorphism is really simple: every subset of a given set of 32 elements can be represented as a function on those 32 elements with values 0 or 1 - 1 if element belongs to this subset, 0 otherwise. Thus 00...00 represents an empty subset, 11...11 represents the whole set, and 10...00 is one of the singletons (only the first element belongs to a subset, thus this subset has just one element). |
|||
13 Dec 2006, 23:35 |
|
MichaelH 13 Dec 2006, 23:54
Vid
Quote:
From Intel Opcodes and Mnemonics - Quote:
I was just getting to understand xor, or, and and, and you go add NOT ..... dam it, now I've added add From Intel Opcodes and Mnemonics - Quote:
man this assembler thing is confusing |
|||
13 Dec 2006, 23:54 |
|
DOS386 14 Dec 2006, 00:50
My "duplicate" post exposed a large need to discuss this issue
Instead of all those complicated instructions, Intel possibly should have implemented something like: Code: ZER reg Zeroizes a register LOK reg Looks at the value in a register, and sets flags, same effect as CMP reg,0 _________________ Bug Nr.: 12345 Title: Hello World program compiles to 100 KB !!! Status: Closed: NOT a Bug |
|||
14 Dec 2006, 00:50 |
|
rugxulo 14 Dec 2006, 03:46
tom tobias, I guess you're impressed with languages like COBOL and not so impressed with Brainf*** or Whitespace.
Tomasz, |
|||
14 Dec 2006, 03:46 |
|
Kain 14 Dec 2006, 06:41
This program may come in handy if someone is having difficulties understanding how bits and flags are affected in boolean algebra, as well as in various other CPU instructions.
[It can also be used by advanced programmers for working out bit masks]
_________________ :sevag.k |
|||||||||||
14 Dec 2006, 06:41 |
|
tom tobias 14 Dec 2006, 12:28
Alas, poor Shoorick (with apologies to Shakespeare's Hamlet from 1603), the algebra preceded the solder, silicon and solid state solutions.
http://www.winasm.net/forum/index.php?showtopic=770 George Boole's 1854 monograph The Laws of Thought appeared nearly a century before invention of the transistor: http://plato.stanford.edu/entries/boolalg-math/ In other words, when Tomasz writes about lattices: Tomasz wrote: ...It's an intersection or union with a singleton. http://www.eelab.usyd.edu.au/digital_tutorial/chapter4/4_1.html Since Shoorick, Smiddy and I, among many, many others on the FASM forum understand the smell of solder much more readily than lattice algebras: http://en.wikipedia.org/wiki/Lindenbaum%E2%80%93Tarski_algebra it is generally simpler for us to think about "lattices" and "intersections" and "sets" in terms of NAND gates or their equivalent. We all end up in the same place: Boolean LOGIC. In my opinion, Boolean LOGIC, PRECEDES Boolean algebra. http://mathworld.wolfram.com/BooleanAlgebra.html This is not obvious, and for some on the forum, will seem irrevlevant to the central question posed by NTOSKRNL_VXE: i.e. why should we employ the "nonsensical" instruction XOR to clear a register? I guess that many skillful mathematicians, including Tomasz surely, could argue against me, that by ALGEBRAIC THINKING, XOR of member 1 with member 1 of a particular set in the lattice corresponds to zero. Consider this illustration from the same excellent Wikipedia reference kindly furnished by Tomasz: wikipedia wrote: ... "Give me all the red and blue berries" usually means ... "Give me all berries that are red as well as all berries that are blue". ... wikipedia wrote: ... In other words, Boolean logical XOR, as opposed to Boolean Algebraic XOR, does NOT convey THE MEANING of nothingness, http://en.wikipedia.org/wiki/Being_and_Nothingness i.e. irrelevance, or zero, on the contrary, it implies that SOMETHING MUST BE CHECKED on the voter registration form, leaving the two choices unmarked represents an invalid condition, i.e. not a legitimate XOR condition, in terms of Boolean logical, as opposed to Boolean algebraic, thinking. So, in my opinion, the facility of programming with the Intel instruction set to (mis)use an ILLOGICAL instruction, XOR, to create NOTHINGNESS, zero, when the semantic concept implies a REQUIREMENT for SOMETHING to be present, leads to difficulty understanding the program, i.e. supports the concept of creating code. Why should ease of comprehension be important? In terms of solder, this situation (using XOR to clear a register, using OR to test a register) is equivalent to a tangle of wires, all the same color, some connected to earth, some to five volts, some to twelve volts, some to negative five volts, and all of them intertwined without labels or diagram. (FASM!) Does it work, YUP. Can it be readily modified by someone else? NO. Is that tangle deliberate-->CODE. |
|||
14 Dec 2006, 12:28 |
|
pelaillo 14 Dec 2006, 13:56
I was right in one thing: this discussion is fruitless
Quote:
tom tobias, it seems that you have difficult at reading fasm sources. Please stop blaming the fasm and bashing it every time you can and start doing a sincere effort to learn the language. Maybe you will be able to use it and benefit from it. |
|||
14 Dec 2006, 13:56 |
|
WytRaven 14 Dec 2006, 14:49
Quote: Does it work, YUP. to accurately represent the situation this should be "Does it work better, YUP." Quote: Can it be readily modified by someone else? NO. ...Does anybody care? NO. Because that's not the point... tom you are quite obviously an intelligent individual which is why I am baffled that you continue to argue the point of writing readable assembly. Assembly is not meant to be readable it is meant to give you the freedom to do exactly what you want/need with the processor and its supporting hardware. The problem of code readability, portability, and any other 'ability' you can think of has already been solved. The solution was the development of higher level languages that hide the unreadable code at the cost of raw performance and complete control. It seems to me that what you are actually arguing is that we should not be using assembly at all; that we should be using the highest level, most readable language available with little to no consideration for performance. If this is what you really mean then please contact Microsoft and give them a demo of your CODE vs PROGRAMS spiel. I'm pretty sure they will offer you a .NET lobbyist job in a flash. Unfortunately I am starting to feel that your opinions on this matter are beginning to amount to pollution in the context of this message board and its subject. _________________ All your opcodes are belong to us |
|||
14 Dec 2006, 14:49 |
|
tom tobias 14 Dec 2006, 19:23
On this, the one year anniversary of the late Professor Dandamudi's untimely death, permit me to quote from his masterpiece, in response to the suggestion that my quest for readable code represents futility: i.e. fruitlessness, or "pollution" (not pollenation, that would be fruitful ):
Introduction to Assembly Language Programming, (second edition) Sivarama Dandamudi, 2005, Springer Verlag, 690 pages. Chapter 14: Protected-Mode Interrupt Processing, pg 417: line 36: mov ECX, 0 ... line 41: cmp EAX, 0 ******************* Why didn't Dandamudi use XOR to clear EAX? Why didn't he use OR, instead of CMP? Not satisfied? Here's Richard Dettmer's newest book (he has written many.) Essentials of 80x86 Assembly Language, R.C.Detmer (2007) Jones and Bartlett, 305 pages. from page 144, chapter 4: ".CODE _start; ; find sum and average mov eax,0 ; sum := 0 mov ecx,0 ; index := 0 ..." Hmm. Why doesn't Dettmer teach his students to use XOR for this purpose? Oh, that's only TWO university faculty members. Two out of how many thousand? You require more convincing? Or, perhaps you believe that those university folks who teach assembly language programming, probably don't know as much about real programming as the FASM forumers, right? How about Richard Blum, he is not an academic guy, just a bloke like many of us.... Professional Assembly Language, Richard Blum, WROX press, (2005) 546 pages: page 145, chapter 6: ... movl $0, %ebx This is the ATT syntax, but, the point is clear, he is assigning the value of zero to EBX, using the MOV instruction, rather than XOR. He is not using a Boolean operation to accomplish his goal of clearing a register.... These quotes are not limited to recent books on the subject, one finds this same devotion to readability among many older publications. Here are quotes from three of my favorite texts: 80x86 Assembly Language Programming, by D.S. Jones, (1991) Oxford University Press, Chapter 5, page 102: cmp CX,0 ; test if CX = 0 .... Advanced Assembly Language, Allen L. Wyatt,Sr. Que publications, (1992) 705 pages; chapter 10, page 402: cmp AX, 0 ; Are we done? page 403: mov DL,0 .... mov AH,0 It isn't just a few texts and references. It is the VAST majority of publications, at least among the couple dozen references in my collection: Developing your own 32 bit operating system, by Richard A. Burgess, (1995) Sam's publishing, 741 pages: page 434, Initialization Code: MOV ECX, 0 page 443, Job Management Code: CMP EAX, 0 For me, this is similar to the situation we encounter at international meetings, and conventions. It is difficult to communicate in any language, and still more difficult to use English, but then, someone comes along with an unorthodox method of presenting results, (the FASM FORUM method!!) and the chore of understanding just became much more difficult than necessary. Can you use Boolean operators to perform mundane, non-Boolean tasks? Yes. Should you do that in order to create good, high quality programs? No. |
|||
14 Dec 2006, 19:23 |
|
Plue 14 Dec 2006, 20:37
GCC, with -O0 uses mov eax, 0
GCC, with -O2 uses xor eax, eax Do you think that's simply for fun? No, it's because it's faster! Now most of us at this forum, do you think we use assembly because we want fast programs or readable programs? Basically, if you want readable programs more than you want fast programs you shouldn't use assembly unless you don't know better ... and in that case, you should know better now, after I told you. Go and use pascal if you want to write readable programs. How authors does it in books isn't very relevant. I've got a book on compiler technique, which, at the end uses only two registers and a lot of pushes and pops instead of using multiple registers. "Writing compilers and interpreters, an applied approach using C++" by Ronald Mak, page 814 wrote: ... for the Pascal assignment statement: |
|||
14 Dec 2006, 20:37 |
|
Goto page Previous 1, 2, 3, 4, 5, 6, 7, 8 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.