flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Main > will it cause slower if

Author
Thread Post new topic Reply to topic
l4m2



Joined: 15 Jan 2015
Posts: 597
will it cause slower if

Code:
mov eaxedx
xor edxedx

was written into

Code:
xchg eaxedx
xor edxedx

Post 30 Jul 2016, 04:27
View user's profile Send private message Reply with quote
comrade



Joined: 16 Jun 2003
Posts: 1113
Location: Russian Federation
First seems better: it does not create a write dependency on edx that conflicts with xor edx,edx.
Post 30 Jul 2016, 04:46
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 518
Location: Munich
Well in that case I personally would prefer:


Code:

xor eax,eax
xchg eax,edx




Wink
Post 30 Jul 2016, 09:19
View user's profile Send private message Send e-mail Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15303
Location: Bigweld Industries

comrade wrote:
First seems better: it does not create a write dependency on edx that conflicts with xor edx,edx.

For modern Intel CPUs it won't matter because "xor reg,same_reg" is internally optimised to know that there is no dependency on any previous register value.

So once again we have, as usual, a case where the question "is X better than Y?" has no answer. It depends upon what system is in use and what it is actually doing.
Post 31 Jul 2016, 02:37
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3459
Location: Bulgaria
For me the first is also, more clear as code and this way is still "better".
Post 31 Jul 2016, 06:40
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 680
Location: Adelaide
Small optimisation: XCHG is a one byte opcode, MOV is two.
Post 31 Jul 2016, 07:09
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15303
Location: Bigweld Industries

sinsi wrote:
Small optimisation: XCHG is a one byte opcode, MOV is two.

But might cause a following jump destination to be unaligned, so maybe not an optimisation in all cases.

Code:
  xchg eaxedx
  xor edxedx
some_label:   ;<--- this might be at 0x1f mod 0x20 and/or cross a page boundary
  ;code
  jnz some_label

Compared to:

Code:
  mov eaxedx
  xor edxedx
some_label:   ;<--- now aligned at 0x00 mod 0x20 bcause "mov" is one byte longer
  ;code
  jnz some_label



Last edited by revolution on 31 Jul 2016, 12:00; edited 1 time in total
Post 31 Jul 2016, 08:38
View user's profile Send private message Visit poster's website Reply with quote
l4m2



Joined: 15 Jan 2015
Posts: 597
When I say "which is better", I usually mean "In what case is the first better, the second better, etc.
XCHG saves a byte. If the code rarely executed, it won't make too much bad on speed but a little save on memory Smile
Post 31 Jul 2016, 09:44
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15303
Location: Bigweld Industries

l4m2 wrote:
If the code rarely executed, it won't make too much bad on speed ...

If the code rarely executed then don't worry about it. Find the hot-spots first and "optimise" those. 10% effort will get you 99.9% of the way there if you "optimise" the most used parts.

Note: "optimise" is of course ambiguous. It will mean different things to different people, and also different things to the same person in different places.
Post 31 Jul 2016, 10:14
View user's profile Send private message Visit poster's website Reply with quote
l4m2



Joined: 15 Jan 2015
Posts: 597

revolution wrote:
If the code rarely executed then don't worry about it.

If you only care about speed, no worry for rarely-executed code. If size cared about, you should shorten it.
Post 31 Jul 2016, 12:12
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15303
Location: Bigweld Industries

l4m2 wrote:
If size cared about, you should shorten it.

Using fewer bytes in code is perhaps the only unambiguous measurement of "optimised" code. If this is always what you mean when you ask for "optimised" or "better" code then perhaps you would get answers that help you if you were to state that you actually want code with fewer bytes. Smile

But your title in this thread asks clearly "will it cause slower if", which is a reference to speed. So now we are not sure what you really want. Question


Last edited by revolution on 31 Jul 2016, 12:56; edited 1 time in total
Post 31 Jul 2016, 12:18
View user's profile Send private message Visit poster's website Reply with quote
l4m2



Joined: 15 Jan 2015
Posts: 597
Obviously XCHG is 1 byte shorter. If we only care about size that's an optimize. However, if it makes slower, shouldn't use it as optimize when more attention to speed.
Post 31 Jul 2016, 12:45
View user's profile Send private message Reply with quote
El Tangas



Joined: 11 Oct 2003
Posts: 120
Location: Sunset Empire
Obviously, the best way is:


Code:
mov eax,1
mul edx

Post 31 Jul 2016, 16:14
View user's profile Send private message Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 518
Location: Munich

revolution wrote:

sinsi wrote:
Small optimisation: XCHG is a one byte opcode, MOV is two.

But might cause a following jump destination to be unaligned, so maybe not an optimisation in all cases.



And how are you sure that the code has been aligned before reaching this instruction part ? Maybe the single byte opcode creates that desired alignment. Razz
Post 01 Aug 2016, 15:23
View user's profile Send private message Send e-mail Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15303
Location: Bigweld Industries

shutdownall wrote:

revolution wrote:

sinsi wrote:
Small optimisation: XCHG is a one byte opcode, MOV is two.

But might cause a following jump destination to be unaligned, so maybe not an optimisation in all cases.



And how are you sure that the code has been aligned before reaching this instruction part ? Maybe the single byte opcode creates that desired alignment. Razz

I'm not sure at all. Which is why I said "might". Of course any alignment can be either good or bad depending upon the circumstances. And this is why these questions have no definitive answer, there are too many unstated and unknowable variables.
Post 01 Aug 2016, 15:25
View user's profile Send private message Visit poster's website 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


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.