What are the pros and cons of these methods of register preservation?
I've seen more code examples that push the registers onto the stack and not very many that use the USES keyword.
Thanks.
The final code is exactly the same. I prefer the "uses" command, as it protects me from doing something stupid (popping in the wrong order, forgetting to pop, etc), and is simple.
Greg
Quote from: 00100b on January 11, 2005, 12:09:44 PM
What are the pros and cons of these methods of register preservation?
I've seen more code examples that push the registers onto the stack and not very many that use the USES keyword.
Thanks.
There is absolutely no advantage to using push instead of uses, USES will just generate the push and pop code automatically. That can be a great advantage when you have multiple returns in the same procedure as the RET macro will always pop the registers before returning. I always use USES when I have a stack frame, however, there are times when you want a procedure without a stack frame, in those cases you cannot have the USES directive so you push and pop the registers manually. Since USES is completely unambiguous, that is you have a 1 to 1 relationship between the directive and the generated code, it is OK by me.
USES pushes the registers at the start, and pops then for each return. So if you have muliple RETs then there will be a set of POPs for each, which is of course necessary. But there may be times when you only need temporary use of a register, so that it could be popped before either return, in which case it seems unnecessary to have it on USES.
On the plus side, it does avoid stupid mistakes with popping things in the wrong order (or at all.)
Donkey: what difference does the stack frame make to it? A stack frame is allocated for local variables (and set up for accessing parameters through ebp) but uses doesn't require one. (In MASM at least.)
Thanks for the responses.
I'll need to do some more reading on the topic of "Stack Frames".
Thanks again.
Forby,
I am a dinosaur and prefer to manually code the stack myself, even in stack frames as it means you must code the procedure the right way. Like normal, do your pushes and pops in reverse order and limit yourself to a singe exit point and you have no problems at all. This makes your code reliable and you ALWAYS know what is happening.
push ebx
push esi
push edi
; code here
quit: ; the single exit point
pop edi
pop esi
pop ebx
ret
I'm not a push and pop guy yet since I'm not yet a MASM programmer like the rest of you but I agree with hutch. I have always been taught to have one and only one exit point in any procedure. It's just good programming practice to do so.
Thanks for the responses.
I've always used a single exit point.
With multiple ways of accomplishing something, I'm just looking to see what methods/conventions I should adopt and why. I'm learning and like to look at both sides of the coin. Also, when I get to the point of using MASM is my work, I know that my boss will want to see "proper documentation", which would includes a document titled "Standards and Conventions".
Thanks again for the input (now I'm sounding like Johnny 5 :lol)
Quote from: Tedd on January 11, 2005, 01:30:38 PM
Donkey: what difference does the stack frame make to it? A stack frame is allocated for local variables (and set up for accessing parameters through ebp) but uses doesn't require one. (In MASM at least.)
In GoAsm the USES directive may be used outside of a stack frame but I believe in MASM, which is the assembler he uses you cannot have a USES directive outside of a stack frame. In reality it makes no difference,and in GoAsm USES is independant and I use it for procs without stack frames, but in MASM I think you must build a frame. Could be wrong though, I never looked to closely at the issue as the only place it is particularly valuable is in procs interfacing with the OS (for EDI,ESI and EBX) and they always need a stack frame as they have parameters.
For MASM, USES does not cause a stack frame to be generated. You get a frame only if the procedure has parameters or locals.