Getting low and high order of dword

Index > Main > Getting low and high order of dword

Author

Thread

nmyo

Joined: 26 Aug 2011
Posts: 4
Location: Las Vegas, NV

nmyo 15 Jun 2014, 04:53

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

15 Jun 2014, 04:53

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20416
Location: In your JS exploiting you and your system

revolution 15 Jun 2014, 04:59

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"?

15 Jun 2014, 04:59

nmyo

Joined: 26 Aug 2011
Posts: 4
Location: Las Vegas, NV

nmyo 15 Jun 2014, 05:17

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.

15 Jun 2014, 05:17

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20416
Location: In your JS exploiting you and your system

revolution 15 Jun 2014, 05:23

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.

15 Jun 2014, 05:23

gens

Joined: 18 Feb 2013
Posts: 161

gens 15 Jun 2014, 13:53

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)

15 Jun 2014, 13:53

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20416
Location: In your JS exploiting you and your system

revolution 15 Jun 2014, 14:06

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.

15 Jun 2014, 14:06

gens

Joined: 18 Feb 2013
Posts: 161

gens 15 Jun 2014, 14:30

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

15 Jun 2014, 14:30

shutdownall

Joined: 02 Apr 2010
Posts: 517
Location: Munich

shutdownall 15 Jun 2014, 21:10

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]

15 Jun 2014, 21:10

< 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