flat assembler
Message board for the users of flat assembler.
![]() Goto page Previous 1, 2, 3, 4 Next |
Author |
|
MazeGen 12 Dec 2005, 09:57
You're wrong, guys. Just step through SHR EAX,32dec in your favorite debugger and see what will happend: nothing.
|
|||
![]() |
|
vid 12 Dec 2005, 10:52
MazeGen: what if he is using 8086?
|
|||
![]() |
|
MazeGen 12 Dec 2005, 11:57
![]() There is no explicit immediate in shift and rotate instructions on 8086 ![]() |
|||
![]() |
|
vid 12 Dec 2005, 12:14
well, on 286 then...
|
|||
![]() |
|
MazeGen 12 Dec 2005, 13:36
According to his suggestion, shr reg,32, I assume he is trying to clear 32-bit register, which is not present on 286...
[lang id="cz"] Nevím, jestli chápu, na co se vlastně ptáš... šlo mi jenom o to, aby si taky někdo někdy ověřil to, co píše. [/lang] |
|||
![]() |
|
vid 12 Dec 2005, 14:40
[lang id="sk"]Jasne, chapem, len som rypal...[/lang]
|
|||
![]() |
|
Madis731 12 Dec 2005, 17:08
Is something clear - did someone write something and is not responsible for it.... hmm.. my Czech and Slovakian is "a bit" rusty
![]() |
|||
![]() |
|
vid 12 Dec 2005, 17:14
you used some translator or what? We were just clearing what i said to mazegen, because his english isn't the greatest one, so he can happen to misunderstand me somtimes. But he understood well.
|
|||
![]() |
|
MazeGen 12 Dec 2005, 17:37
Hehe, I wondered about vid's lunar politics in his lastest posts and he confessed he just narked me
![]() |
|||
![]() |
|
RedGhost 12 Dec 2005, 19:40
when i first started assembler i was always told to use xor r, r because it was fast(er)(est) and from the results and tests i'll just stick with xor
_________________ redghost.ca |
|||
![]() |
|
decard 12 Dec 2005, 20:47
Me too
![]() |
|||
![]() |
|
tom tobias 13 Dec 2005, 09:52
Hi Decard: Speed difference?
Let's consider the REAL speed difference. You mentioned FRESH, and John's former code. So, let's stick to that problem. MULTIPLE people working on ONE project. In that setting, does it make ANY difference whether OR is slower, or faster than TEST? No, absolutely none. (No one on this forum will reject FRESH because it executes too slowly.) BUT, if a group of people are trying to work jointly on a project, the single most important factor SLOWING down the project, is the SPEED of comprehension of what the other programmers are trying to accomplish. The speed of execution is the LEAST of our concerns about FRESH. It is not TOO SLOW. It is nonexistant. Good programming practice requires RESTRICTING use of Boolean operators to Boolean logical situations. You wrote, well, now I am accustomed to using xor to clear a register. Sure, we all are able to learn some CODE. Even I, dumb as I am, can COMPREHEND that xor eax, eax, MEANS set eax to zero. BUT, why should it be necessary to reflect, to pause, to think, to imagine, when reading John's, or anyone else's code? Shouldn't our ability to REVISE other's efforts, such as you are now doing with FRESH, be as trouble free as possible? Shouldn't it be just as EASY to read what John had written, as possible, so that you can use your time to its best advantage, use your creativity to improve and ADD FUNCTIONALITY, rather than replace TEST with OR, because OR is 1 nanosecond faster than TEST (assuming that is the case?) In my opinion, NO ONE ON THIS FORUM will REJECT FRESH, because of its slowness in execution. Yes, you have now learned that one can use OR (the wrong instruction), instead of TEST (the correct instruction). Sure, we can all learn to do things the WRONG way. What I hope you will come to appreciate is this simple fact: A great many mistakes from past scholars, and authors, have been introduced into the current practice of contemporary assembly language programmers, as DOGMA. AS STANDARD PRACTICE. Nonsense. John was correct. Stick to TEST, don't misuse the Boolean operators, NO MATTER HOW "FAST" they may execute. Just because everyone else does it the WRONG way, doesn't make that behaviour correct. I believe I have thus properly elaborated precisely what Mazegen wrote: Nevím, jestli chápu, na co se vlastně ptáš... šlo mi jenom o to, aby si taky někdo někdy ověřil to, co píše. ![]() |
|||
![]() |
|
decard 13 Dec 2005, 11:02
I wasn't asking about Fresh, of course I know it won't make any difference even if I replaced all TESTs with "CMP REG,0", I just asked which is better in general.
![]() |
|||
![]() |
|
Tomasz Grysztar 13 Dec 2005, 11:28
As for me, when I was learning assembly, the "XOR REG,REG" and "OR REG,REG" were so widely used, and I never saw any "MOV REG,0" nor "CMP REG,0" - and thus I have learned the XOR and OR used this way to be a kind of common language constructs. Though "MOV REG,0" is really more readable for someone who knows just basics of the assembly language, for those who learned like me, the "XOR REG,REG" is a kind of language construction like "INC REG" instead of "ADD REG,1". When I look at this instruction I don't see the XOR logical operation, I see the "zero this register, please" command.
|
|||
![]() |
|
IronFelix 13 Dec 2005, 12:13
Absolutely agree with you, Tomasz!
|
|||
![]() |
|
pelaillo 13 Dec 2005, 13:14
Tom, maybe this became Standard Practice because is agreed by a majority of programmers. Don't pretend that it's stubborness, simply we don't share your point.
i.e. when I want eax to be cleared, in my mind I didn't think on storing a zero to it. In my mind I have "clear eax". So why to store and create an immediate value simply to clear it? Readability depends on how well documented are your data structures and functions (well crafted names help a lot) but a single opcode couldn't affect it, moreover if it's the Standard Practice. XOR is a mnemonic of an opcode instructing the processor to do a certain task. A task that an assembly programmer must know and use as it fits. You will always have more tasks than opcodes, so there will be more than one situation when the mnemonic does not correspond exactly with the task you want to accomplish. |
|||
![]() |
|
MazeGen 13 Dec 2005, 14:46
MazeGen wrote:
Madis731 wrote: Is something clear - did someone write something and is not responsible for it.... hmm.. my Czech and Slovakian is "a bit" rusty tom tobias wrote:
![]() It seems I can easily use my native language in this forum, because one has almost no problems with it! As for XORing vs. MOVing, I agree that we saw it so many times in the old days, when code size was more important, that we don't need to think about what XOR EAX,EAX does. That's also why we don't use something like IMUL EAX,EAX,0. Even though I don't much depend on code size, I still use shorter XOR EAX,EAX or SUB EAX,EAX instead of MOV EAX,0. Habit only. |
|||
![]() |
|
tom tobias 13 Dec 2005, 16:29
Tomasz Grysztar wrote: ... When I look at this instruction I don't see the XOR logical operation, I see the "zero this register, please" command. PRECISELY! In other words, you will NOT recognize the logical boolean operation when encountering: XOR EAX, EDX. You visual system, working as quickly as it can to keep up with your brain and your hands typing away, will FAIL TO RECOGNIZE that the second operand is NOT EAX, and a lot of time will be wasted trying to find a mistake that is probably not a typographical error. Well, ok, you and Iron Felix are too clever, I agree, to fall for that error, but less clever people, (like me!) WILL WASTE INORDINATE amounts of time trying to understand what in the world is going on.....Unlike the situation with MazeGen's elegant poetry, which we all understood at a glance! ![]() |
|||
![]() |
|
tom tobias 13 Dec 2005, 16:40
pelaillo wrote: ... in my mind I didn't think on storing a zero to it. In my mind I have "clear eax". So why to store and create an immediate value simply to clear it? I guess this is a brilliant argument, and I honestly have no good rejoinder. I confess defeat. I will attempt from now on, to avoid insisting that one must use MOV EAX, Zero, to ensure the most understandable, most obvious, most evident, most readable method of clearing a register. ![]() |
|||
![]() |
|
Goto page Previous 1, 2, 3, 4 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2023, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.