flat assembler
Message board for the users of flat assembler.

 Index > Main > Getting low and high order of dword
Author
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: 20210
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: 20210
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: 20210
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
 Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First

 Jump to: Select a forum Official----------------AssemblyPeripheria General----------------MainTutorials and ExamplesDOSWindowsLinuxUnixMenuetOS Specific----------------MacroinstructionsOS ConstructionIDE DevelopmentProjects and IdeasNon-x86 architecturesHigh Level LanguagesProgramming Language DesignCompiler Internals Other----------------FeedbackHeapTest Area

Forum Rules:
 You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum