Yet another assembly question =/

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...