Preservation of esi, edi, ebx in general code

[jj2007]

6 cycles, 0.2% slower. Show me one WM_nnn that needs less than 3000 cycles...

(actually, there is one: WM_MOUSEMOVE takes only 600 cycles... which means that with the uses esi edi ebx, your WM_MOUSEMOVE processing will take approx. 0.00408 milliseconds instead of only 0.004 milliseconds... ::))

[hutch--]

Its all of the extra clutter that is the problem and the added problem associated with multiple exits, the much cleaner and simpler technique is to preserve required registers on a needs basis for each message processed. A WndProc is a messy enough affair to start with, essentially a single collector procedure with multiple functions based on the number of processed messages being handled, different messages having different needs, this is why a catch all is bad design.

[dedndave]

it's really true
a top-level window with a mouse moving over it gets hundreds, if not thousands of messages
they usually go to DefWindowProc - but only after passing through the epilogue

[jj2007]

a top-level window with a mouse moving over it gets hundreds, if not thousands of messages

Most of them are WM_MOUSEMOVE - a particularly fast one with only 600 cycles. 3 push/pop pairs delay WM_MOUSEMOVE by 0.00008 milliseconds - how significant is that delay?

To put it differently: Launch a simple window, then Task Manager, and try to get CPU usage above 0% by frenetically moving the mouse over the window. Have fun.

[satpro]

Sorry, guys...  didn't mean to shake the tree.


So if I:


-- PUSH (or USES)  ESI or EDI or EBX   (in a procedure IF modified in the procedure)
-- PUSH  EAX or ECX or EDX                 (before entering a procedure IF the value held is needed afterwards)
-- Assume other programmers assume esi, edi, and ebx will be preserved; eax, ecx, and edx will be trashed in procedures.


...it should be okay.  Does that sound about right?

[dedndave]

yes - and let's not forget EBP - it should be preserved also
typically, we do not use EBP because the default epilogue for masm PROC's uses it for parms
the assembler takes care of preserving it for you

[BogdanOntanu]

Do not PUSH EAX because it is normally used for the return value...

[Ryan]

Do not PUSH EAX because it is normally used for the return value...

What do you mean?  If the value in EAX is still needed, it has to be pushed, else it will be lost.

[dedndave]

you are right, Ryan
most functions do return a result in EAX, however
but - you could do something like...

Code Select Expand

        push    eax
        INVOKE  SomeFunction
        or      eax,eax                ;test returned value
        pop     eax                    ;restore saved value
        jz      SomeLabel              ;branch on result of test
another way to go might be to restore it into EDX (or ECX)

Code Select Expand

        push    eax
        INVOKE  SomeFunction
        or      eax,eax                ;test returned value
        pop     edx                    ;restore saved value
        jz      SomeLabel              ;branch on result of test
that way, the returned value is not destroyed