Hi all,
I try to learn to program my own macros/stay away from masm32-macros to learn and understand more. It is easy to replace "fn" when calling, like this:
push arg2
push arg1
call myfuncion
myfunction proc arg1:DWORD,arg2:DWORD
However, how do I write pure assembly to store a return value?
Thank you in advance!
Quote from: Ani_Skywalker on October 27, 2011, 09:46:29 PMHowever, how do I write pure assembly to store a return value?
You want to know, how to return something from a macro? - or at runtime?
Quote from: qWord on October 27, 2011, 09:49:28 PM
You want to know, how to return something from a macro? - or at runtime?
I want to know how to return something from a process. Hmm, let's try this example:
addition proc first:DWORD,second:DWORD
xor eax, eax
mov eax, first
add eax, second
retHere I'd like to return the sum stored in eax, hence I'd like to return eax.
Oh, it seems the eax is stored automatically in my example code, then I can use that approach to solve the real problem. Ty!
You can technically return values from procedures in ANY registers, but the normal way is to return values in eax.
Quotexor eax, eax
mov eax, first
And, whenever you "mov" something into any of the multipurpose CPU registers, it overwrites whatever was in there before. Thus, no need to zero that register before the move.
If you need to move a byte (or word) value into part of a 32-bit register, and you want the remainder of that register to be rezeroed, you can use the "movzx" mnemonic. If you want the sign bit to be copied to the upper bits of the register, you would use the "movsx" mnemonic.
Although the original question been answered, I got another one that came up after Gunner's post.
Is there any "unwritten" standards or something that are good to know when coding asm? For example, I only use eax, ebx, ecx, edx and leave the other registers be. Think I read somewhere that it is standard to do so. I'm wondering if there is more standards like that to think about when writing asm?
Also, even though I'm noob, I really enjoy writing assembly. Much more then writing Java, F# or languages like that. Only C comes close when it comes to joy of writing it. So I'm wondering where I could find a asm-job? So far I though Reverse Engineering binaries at some sec-company should could be an option. But it turns out they have very few projects like that and it is hard to fill a full-time position just by reverse engineering binaries. Suggestions on where to look for jobs where you get to work with asm?
there are rules :P
it's called the windows ABI
however, the register preservation rules only apply to procedures that are in callback
for example, in WinMain, you can use all the registers - in WndProc, you must follow the rules
when we write "re-usable" functions, we generally follow the rules
that way, the function may be used in either case
the rule about the direction flag applies any time you want to use API functions
i.e., if you call any API function, it is best to have the direction flag cleared
EBX, EBP, ESI, EDI should be preserved
EAX, ECX, EDX may be altered
direction flag should be left cleared
windows API functions follow the same rules
that means that you can expect EBX, EBP, ESI, EDI to be preserved across an API call
Quoteit's called the windows ABI
EBX, EBP, ESI, EDI should be preserved
That ABI was originally developed for Win95/98.
I do agree that EBP must be preserved through calls to functions building a stack frame. However, EBX, ESI and EDI may not be as critical from the OS point of view as it used to be.
A few years ago, I wrote a program which was working perfectly with WinXP. However, when I tried it on Win98, it crashed. I eventually traced it back to a stupid error where I had preserved ESI and EDI but retrieved them in the wrong order! :red It would seem that starting with WinXP (and possibly with Win2000) that Windows quit relying on programmers to preserve those registers.
Nevertheless, it's always a good practice to continue preserving those registers in
reusable functions so that you don't have to worry that their content may change on return when you use them in some other application.
it's hard to say
i have had cases under XP where accidently not preserving EDI inside WndProc caused it to crash
and - on a different message, it did not :P