flat assembler
Message board for the users of flat assembler.

Index > Main > Getting low and high order of dword

Author
Thread Post new topic Reply to topic
nmyo



Joined: 26 Aug 2011
Posts: 4
Location: Las Vegas, NV
nmyo
Hello, I've been experimenting with simple programs written in assembly.

I would like to get the low and high order of a dword and store them in two different dwords, but I'm not sure if I'm doing this efficiently.

Let's say, location has value of 55370273h. At the end of code, I want to have these:
x = 0273h
y = 5537h


Where location and x and y are dwords.

One way I've seen is I think similar to doing in C (bit shift):
Code:
mov     eax, [location]
and     eax, 0FFFFh ; Make high order to zeros
mov     [x], eax
mov     eax, [location]
shr     eax, 16
mov     [y], eax    


After doing a small research, though, shifting bits with a constant other than one is not good or best to stay out of it whenever possible. So, I've made some changes:
Code:
mov     eax, [location]
and     eax, 0FFFFh
mov     [x], eax
mov     eax, [location + 2] ; High order of location
and     eax, 0FFFFh
mov     [y], eax    


Then
Code:
movzx   eax, word [location]    ; Truncate and change to zeros
mov     [x], eax
movzx   eax, word [location + 2]
mov     [y], eax    


The movzx instruction feels like it does its job, but I'm not sure whether using another register like movzx ebx, ax (to use movzx with register and register instead of register and memory) will result any better.

Is there any better implementations, or am I on the right track with using movzx?

EDIT: Turns out it was bit rotation that I should avoid and not bit shift.


Last edited by nmyo on 15 Jun 2014, 05:12; edited 1 time in total
Post 15 Jun 2014, 04:53
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17339
Location: In your JS exploiting you and your system
revolution
What do you mean by "better"? What are you trying to achieve?

All of those snippets you posted appear to work fine. If they are not working for you then what is it that you want to do "better"?
Post 15 Jun 2014, 04:59
View user's profile Send private message Visit poster's website Reply with quote
nmyo



Joined: 26 Aug 2011
Posts: 4
Location: Las Vegas, NV
nmyo
By better, I mean better performance and better efficiency. I think I'm just thinking too hard on doing something simple as the above.

Also, it turns out it was bit rotation that I should avoid and not bit shift, so I think I just ended up wasting time trying to come up with something better.
Post 15 Jun 2014, 05:17
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17339
Location: In your JS exploiting you and your system
revolution
Why "should you avoid bit rotation"?

If you can't see the difference in your code at runtime that I'd suggest that is makes no difference which one your use. But most probably the one with the fewest instructions will be the "easiest" for the CPU to perform. But this is not always true because there are a myriad of things that are happening inside a CPU that any one instruction usually makes no perceivable difference unless you are doing some very specific task under very specific time/space constraints.
Post 15 Jun 2014, 05:23
View user's profile Send private message Visit poster's website Reply with quote
gens



Joined: 18 Feb 2013
Posts: 161
gens
Code:
mov     eax, [location]
mov     [x], ax
shr     eax, 16
mov     [y], ax    


PS
http://www.agner.org/optimize/
the 4'th one
also note most x86 cpus move 32bits to/from ram (afaik)
Post 15 Jun 2014, 13:53
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17339
Location: In your JS exploiting you and your system
revolution
gens wrote:
also note most x86 cpus move 32bits to/from ram (afaik)
Probably not. More likely 64-bits at a time for most systems made in the last 10 years. But also it is more than that because usually the CPU will fill the entire cache line even of you read only one byte. Anyhow, each system is different so if this sort of thing is important then it pays to check the exact specs of one's mobo and CPU.
Post 15 Jun 2014, 14:06
View user's profile Send private message Visit poster's website Reply with quote
gens



Joined: 18 Feb 2013
Posts: 161
gens
revolution wrote:
gens wrote:
also note most x86 cpus move 32bits to/from ram (afaik)
Probably not. More likely 64-bits at a time for most systems made in the last 10 years. But also it is more than that because usually the CPU will fill the entire cache line even of you read only one byte. Anyhow, each system is different so if this sort of thing is important then it pays to check the exact specs of one's mobo and CPU.


think i read somewhere that it was 2x32 for amd
if i remember amd and intel get diff results
(maybe i read it on the x264 blog, dk)

oh well, can be tested
Post 15 Jun 2014, 14:30
View user's profile Send private message Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 518
Location: Munich
shutdownall
You can also just use labels to save memory.

Code:
location:
.x      dw 8765h
.y      dw 4321h

mov eax,[location]
mov bx, [location.x]
mov cx, [location.y]
    


or an approach like this:

Code:
location dd 87654321h
label x word at location
label y word at location+2

mov eax,[location]
mov bx,[x]
mov cx,[y]
    
Post 15 Jun 2014, 21:10
View user's profile Send private message Send e-mail 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 YouTube, Twitter.

Website powered by rwasa.