[M3devel] win32/x86 prolog/epilog

[Jay]

At one point Linux/x86 didn't use gcc, right? It used the same as the Win32/x86 backend?
 
Anyway, on Win32/x86, small functions like:
 
PROCEDURE F5(b : INTEGER) : INTEGER =BEGIN RETURN Word.Shift(0, b);END F5;
result in:
 
_T__F5:  004010C2: 55                 push        ebp  004010C3: 8B EC              mov         ebp,esp  004010C5: 81 EC 04 00 00 00  sub         esp,4  004010CB: 53                 push        ebx  004010CC: 56                 push        esi  004010CD: 57                 push        edi  004010CE: 33 C0              xor         eax,eax  004010D0: 5F                 pop         edi  004010D1: 5E                 pop         esi  004010D2: 5B                 pop         ebx  004010D3: C9                 leave  004010D4: C3                 ret
Now, I can grant that having a consistent frame is nice for stack walkability in a debugger in the absence of symbols, so I won't argue about push ebp, mov ebp, esp, sub esp,4, leave. (not sure leave is the state of the art, need to compare to current compiler output).
 
But, this constant push ebx/esi/edi, pop edi/esi/ebx seems dumb. Doesn't it?
 
Looking at the code, and how it avoids having multiple passes, it should be easy to at least track which registers are used, and go back and nop out the pushes, and avoid the pops entirely.
 
Or possibly to move the function ahead up to three bytes, leaving three bytes of padding -- being sure to test recursive code..except anything with a function call, maybe leave alone. I ASSUME nop is faster than push, esp. when combined with saving the pops entirely, ESP. when there are presumably two and three byte nops, so the instruction count can be dropped, even if the byte count cannot easily.
 
Thoughts?
 
Nobody cares 'cause everyone else is using gcc and it handles these things well?
 
 - Jay
_________________________________________________________________
Your smile counts. The more smiles you share, the more we donate.  Join in.
www.windowslive.com/smile?ocid=TXT_TAGLM_Wave2_oprsmilewlhmtagline
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20071129/cf026472/attachment-0001.html>