flat assembler
Message board for the users of flat assembler.

Index > Main > [split] LEA -> MOV | MOV -> XOR and other aggressive o

Author
Thread Post new topic Reply to topic
Azu



Joined: 16 Dec 2008
Posts: 1159
Azu
revolution wrote:
MazeGen wrote:
The MOV -> LEA conversion is different thing because it changes whole instruction. (I remember someone complaining about this in GoAsm forum because GoAsm converts it.)
I have always seen this as simply a mnemonic substitution problem. The CPU knows only binary and will execute the LEA/MOV thing in such a way that the net effect is the same. Just because we need to satisfy the human desire to convert binary values into more human friendly words does not affect the CPU. If the disassemblers were to display those LEAs as MOVs would the people still complain? How do people feel when the dual Jcc opcodes are "changed" by the disassembler? The disassembler has to choose one of the mnemonics, how can it know what the source code programmer was thinking? The same with XOR reg,reg. If the disassembler were to display "CLEAR reg" would people then complain? Okay, I know that CLEAR has not been defined in any official documentation, but if it was defined and assemblers modified etc. then suddenly XOR reg,reg (displayed as CLEAR reg) becomes acceptable?

The CPU does what it does without caring about human mnemonics. If we can use a shorter opcode to achieve the same effect then I don't see why not to use it. Perhaps instead of us forcing the assembler to make less efficient code we should instead be asking the disassembler writers to make their code more flexible/smarter?


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
Post 19 Dec 2009, 06:51
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17716
Location: In your JS exploiting you and your system
revolution
Azu wrote:
If you really want that kind of behavior why not just make a macro for it?
I do, and the macros are posted on this board somewhere. Search for them if you are interested.

But macros make things assemble slower Sad
Post 19 Dec 2009, 07:02
View user's profile Send private message Visit poster's website Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1159
Azu
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.

_________________
Post 19 Dec 2009, 07:06
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
Why not add an optimization option in FASM 2.0 that does things like this and more? Smile
Post 19 Dec 2009, 17:01
View user's profile Send private message Reply with quote
Tyler



Joined: 19 Nov 2009
Posts: 1216
Location: NC, USA
Tyler
Borsuc wrote:
Why not add an optimization option in FASM 2.0 that does things like this and more? Smile

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).
Post 20 Dec 2009, 03:00
View user's profile Send private message Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
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. Laughing

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.
Post 20 Dec 2009, 04:58
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 713
Location: Adelaide
sinsi
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 Razz one syllable rather than two Embarassed

>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.
Post 20 Dec 2009, 05:13
View user's profile Send private message Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
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.
If you want to optimize, write a macro - 2 seconds to compile instead of 0.5 seconds (oops, I blinked and missed).


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. Laughing 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?
heh, just got bitten with that one.


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
IMO too, for little gain.


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.
Post 20 Dec 2009, 05:35
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 713
Location: Adelaide
sinsi
>"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 Very Happy
Post 20 Dec 2009, 05:57
View user's profile Send private message Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
sinsi wrote:
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
I pronounce xor in 1 syllable Razz

something like 'csohr' in english (because I pronounce it from romanian).

_________________
Previously known as The_Grey_Beast
Post 20 Dec 2009, 17:23
View user's profile Send private message Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1159
Azu
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.
If you want to optimize, write a macro - 2 seconds to compile instead of 0.5 seconds (oops, I blinked and missed).


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 Razz one syllable rather than two Embarassed

Razz
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
IMO too, for little gain.
Agreed!

sinsi wrote:
>"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]"
But you can't do that with sub, either.

_________________
Post 20 Dec 2009, 23:23
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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.
Post 25 Dec 2009, 14:35
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
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    
more advanced would be to even see if the flags are not used (and substitute stuff with 'xor ebx, ebx' and such).

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" Razz)

_________________
Previously known as The_Grey_Beast
Post 25 Dec 2009, 17:36
View user's profile Send private message Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1159
Azu
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).

_________________
Post 25 Dec 2009, 20:00
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< 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-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.