# Yet another assembly question =/

This topic is 4578 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I have a bswap function on the critical path in my application and I'm working on a way to improve it. Moving to assembly version improved function execution speed by 50% right now (in clocks), but there are still things to do... There is a 32 bit version and 64 bit version of bswap in my app... Things are realy simple with 32 bit one, as return value is expected in eax and thats about it, but I have some doubts about bswap64. From what I managed to deduce from assembly output, __int64 is returned in edx:eax, and application seems to work fine if I do that, but I'm not sure it wont crash under some weird switches/circumstainces... Is the return edx:eax safe? There seems to be no info on web about 64 bit return values... The second thing I'm currently looking at is to opt out ebp and other registry saving restoring ops. The function right now is - __cdecl __int64 f(__int64); (I guess cdecl, as project is compiled as C project with inline assembly) There is a lot of registry pushing poping generated by VS03 and I think that's not needed at all. I found that __declspec(naked) might do the job, but what about calling function from C app and C++ app later, wont it break anything later on? Currently full function code is:
unsigned __int64 bswap64(unsigned __int64 num)
{
__asm
{
mov edx, dword ptr[num]
mov eax, dword ptr[num+0x4]
bswap eax
bswap edx
}
}

What should I take into account if I migrate to __declspec(naked)? do I return from function with - ret 0 and where should I expect input variable - registers, stack? If stack, can I just address it with esp rather than ebp? From what I've heard eax, ecx and edx doesn't need to be preserved in function, all other variables should be, am I right? And are there any dangers if I decide to recompile the code as C++ code later on? I know i'm asking a lot of questions, but I really tried googling and I couldn't find answers to most of them...

##### Share on other sites
Quote:
 Original post by _Madman_From what I managed to deduce from assembly output, __int64 is returned in edx:eax, and application seems to work fine if I do that, but I'm not sure it wont crash under some weird switches/circumstainces... Is the return edx:eax safe? There seems to be no info on web about 64 bit return values...

Yes. You'll find the info if you dig hard enough. "An 8-byte integer is typically returned in the EDX:EAX register pair, with EDX containing the high 32 bits." [1]

Quote:
 Original post by _Madman_I found that __declspec(naked) might do the job, but what about calling function from C app and C++ app later, wont it break anything later on?

Not necessarily.

Quote:
 Original post by _Madman_What should I take into account if I migrate to __declspec(naked)?

In general with naked functions you'll have to deal with stack management and preserving the non-clobberable registers.

Quote:
 Original post by _Madman_do I return from function with - ret 0

For your function as _cdecl, a simple 'ret' should do.

Quote:
 Original post by _Madman_and where should I expect input variable - registers, stack? If stack, can I just address it with esp rather than ebp?

For cdecl and stdcall, the stack. For fastcall and thiscall registers and stack. For cdecl and stdcall you can address the arguments using esp, just remember that stacks grow downwards so you expand them by subtracting and contract them by adding.

Quote:
 Original post by _Madman_From what I've heard eax, ecx and edx doesn't need to be preserved in function, all other variables should be, am I right?

Other registers, yes. This varies from compiler to compiler, but generally yes.

Quote:
 Original post by _Madman_And are there any dangers if I decide to recompile the code as C++ code later on?

Yes. Ecx is often used in C++ code to pass the "this" variable to method calls.

Quote:
 Original post by _Madman_I know i'm asking a lot of questions, but I really tried googling and I couldn't find answers to most of them...

Just Enough Assembly Language to Get By Part 1
Just Enough Assembly Language to Get By Part 2
X86 Assembly Wikibook
The history of calling conventions, part 3
How can a program survive a corrupted stack?
IA-32 Intel® Architecture Software Developer's Manual, Volumes 1, 2A, 2B, 3A and 3B

1. 1
2. 2
Rutin
19
3. 3
khawk
18
4. 4
5. 5
A4L
11

• 12
• 16
• 26
• 10
• 44
• ### Forum Statistics

• Total Topics
633767
• Total Posts
3013739
×