Index
> Main > [split] LEA -> MOV | MOV -> XOR and other aggressive o |
| Author |
|
|
Azu 19 Dec 2009, 06:51
revolution wrote:
Um.. you have it backwards. It would be okay to display XOR reg,reg as CLEAR reg because there is no real "CLEAR" opcode, so it could only possibly refer to XOR, and thus there'd be no ambiguity. If there was a CLEAR instruction it would be completely unacceptable, since there'd be no way to know which was which. JBE and JNA are the exact same thing. Their English meanings (jump if below or equal, jump if not above) are identical, and the code they generate ($76CB) is identical. LEA and MOV have completely different meanings and compile to completely different things, so an assembler should not change one into the other without permission. That is what HLLs are for. If you really want that kind of behavior why not just make a macro for it? EDIT by DOS386 : split from t=9770 |
|||
19 Dec 2009, 06:51 |
|
|
Azu 19 Dec 2009, 07:06
Well if FASM is going to be made to do this automatically please at least include an option to make it not do this. Like something that can be placed at the top of the file telling it not to, or something.
|
|||
|
19 Dec 2009, 07:06 |
|
|
Borsuc 19 Dec 2009, 17:01
Why not add an optimization option in FASM 2.0 that does things like this and more?
 |
|||
|
19 Dec 2009, 17:01 |
|
|
Tyler 20 Dec 2009, 03:00
Borsuc wrote: Why not add an optimization option in FASM 2.0 that does things like this and more? Because then it would just be another masm or nasm, that screws with your code despite the fact it was better before(in some/most cases). |
|||
|
20 Dec 2009, 03:00 |
|
|
kohlrak 20 Dec 2009, 04:58
I can't wait to see the debate then when people start arguing between "xor eax, eax" and "and eax, 0." Honestly... Since when did we start letting the assembler do things for us? I thought most of us left other assemblers and HLLs because it messes with our codes and does "optimizations" that we don't agree with. Especially when some vary per system, and some don't really make any difference when they're really supposed to (branch hints anyone?).
Quote: Well if FASM is going to be made to do this automatically please at least include an option to make it not do this. Like something that can be placed at the top of the file telling it not to, or something. I wouldn't want to have to add an option to make it not optimize (that would break my exist code perhaps), and i'd have to open some sources and mess with it. Make it a command line option, and we'll have to change our makefiles (or other things). Making us who are responsible programmers, who know what we're doing, shouldn't have to yield to optimizations for those who are too lazy (or too stupid) to write better code. Anyone knows pretty darn well that this thing would eventually excel into some form of HLL and fasm becomes just another compiler for another language, trying to optimize away this and that. Then again, perhaps it would actually optimize away bad things that people constantly pretend their compiler actually optimizes away. 
Quote: Why not add an optimization option in FASM 2.0 that does things like this and more? Smile IMO, any adding features like that would be more work for Thomasz, and people would complain when it doesn't do what they want it to do, etc. Such a project would better off being a unofficial side-project like fasmarm. |
|||
|
20 Dec 2009, 04:58 |
|
|
sinsi 20 Dec 2009, 05:13
What you write should be what you get. You go for speed or you go for size then you find out that other instructions are longer but faster.
If you want to optimize, write a macro - 2 seconds to compile instead of 0.5 seconds (oops, I blinked and missed). I use 'sub eax,eax' rather than 'xor eax,eax' simply because when I vocalise it internally it sounds better  one syllable rather than two 
>branch hints anyone? heh, just got bitten with that one. >IMO, any adding features like that would be more work for Thomasz IMO too, for little gain. |
|||
|
20 Dec 2009, 05:13 |
|
|
kohlrak 20 Dec 2009, 05:35
Quote: What you write should be what you get. You go for speed or you go for size then you find out that other instructions are longer but faster. I didn't catch that actually. Just imagine, writing macros slows you down by one and a half seconds, just imagine how slow fasm will ALWAYS be for EVERYONE when you got two FASMs under the same hood. Quote: I use 'sub eax,eax' rather than 'xor eax,eax' simply because when I vocalise it internally it sounds better Razz one syllable rather than two Embarassed Eh, just pronounce it ksor. Like sore, but with a k in front. If that's hard, say White Sox (White Socks). Then go to ox. Go to "oxor." Take off the initial "aw" sound.
Quote: >branch hints anyone? If you think that's bad, load ecx with a sizable number (not too big) and loop $. See how long it takes to get out of the loop. Changing things even a little produces more noticeable clock differences (i know you can't rely on benches in an OS, but honestly, common! Is all the OS overhead really THAT bad?). It's almost as if branch prediction is broken all together (hence claims in other posts). Quote: >IMO, any adding features like that would be more work for Thomasz I'll save someone else the trouble of saying it (even though I don't agree it'd be significant), "Any gain in readability is not a little one." I don't necessarily agree that it'll improve readability by much, but I thought I'd save someone the time of typing it. |
|||
|
20 Dec 2009, 05:35 |
|
|
sinsi 20 Dec 2009, 05:57
>"Any gain in readability is not a little one."
At least if I use "sub eax,eax" I know what happens to the flags and what happens to eax. Using e.g. "clear eax" adds an extra layer that I might not know - how to do "clear dword[esi]" or "clear dword [esp+4]" I trust Tomasz to give me the right opcodes for what I input, be it jae or jnb (which can be a hint as well). FWIW I use masm a lot (since 1983) but use no macros, no invoke, no procs. It's a lot like fasm when you do it that way - bare bones asm. It it's too easy you should go to C and leave us alone  |
|||
|
20 Dec 2009, 05:57 |
|
|
Borsuc 20 Dec 2009, 17:23
sinsi wrote: I use 'sub eax,eax' rather than 'xor eax,eax' simply because when I vocalise it internally it sounds better
something like 'csohr' in english (because I pronounce it from romanian). _________________ Previously known as The_Grey_Beast |
|||
|
20 Dec 2009, 17:23 |
|
|
Azu 20 Dec 2009, 23:23
sinsi wrote: What you write should be what you get. You go for speed or you go for size then you find out that other instructions are longer but faster. More like 0.0 seconds instead of 0.0 seconds ^^ sinsi wrote: I use 'sub eax,eax' rather than 'xor eax,eax' simply because when I vocalise it internally it sounds better
You can say xor as one syllable. Just pronounce the x the same way it is always pronounced at the start of a word; z. sinsi wrote: >IMO, any adding features like that would be more work for Thomasz sinsi wrote: >"Any gain in readability is not a little one." |
|||
|
20 Dec 2009, 23:23 |
|
|
f0dder 25 Dec 2009, 14:35
Disassembler has to "make a choice" on "dual Jcc" because it's one instruction with multiple mnemonics.
LEA vs. MOV are different instructions - there's quite a difference. Assembly is WYWIWYG, (usually) even when using macros. Doesn't matter if you have a multiple-push or invoke or generate-jumptable-from-switch-statement, you know what you'll be getting. But once you throw in optimizations that do instruction substitution, you might as well move to a HLL... since you're losing (starting to lose) the benefits of assembly without getting (much of) the benefits of HLL. |
|||
|
25 Dec 2009, 14:35 |
|
|
Borsuc 25 Dec 2009, 17:36
Well if this was easy to do (which it is not unfortunately), it would be a good option choice. It's not exactly a HLL as it doesn't alter the instructions much, just some small optimizations on constants. It can keep track of constants e.g:
Code: mov ebx, 3 ; some code that doesn't affect ebx push 3 ; <-- replace with push ebx but of course it's too much work. (also new directives could have been added to force it to never optimize a sequence or to 'assume' a given value, i.e "assume ebx=3" )_________________ Previously known as The_Grey_Beast |
|||
|
25 Dec 2009, 17:36 |
|
|
Azu 25 Dec 2009, 20:00
Altering an instruction is the kind of instruction alteration an HLL would do. And it would break the program if the 3 in the mov ebx,3 or push 3 get modified, or if you counted on that chunk of code being a certain length. Definitely should be optional.
And I agree about the assume directive, that would help (e.g. if it can't know what the value is since it is after a function call or something). |
|||
|
25 Dec 2009, 20:00 |
|
< Last Thread | Next Thread > |
Forum Rules:
|