[M3devel] win32/x86 prolog/epilog

[Tony Hosking]

On Nov 29, 2007, at 7:41 AM, Jay wrote:

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

Sounds reasonable.  Having glanced at the native x86 backend I  
believe it really needs a good shake-out to bring it up to speed.

> Nobody cares 'cause everyone else is using gcc and it handles these  
> things well?

I haven't tried the CygWin (gcc-backend) based build of CM3 for  
Windows, but clearly we need a good story for Windows-based CM3.  Jay  
you have done a great job keeping this branch of the system alive.  I  
certainly hope you can keep it up.  Not being a Windows user myself,  
I do lack the incentive (and expertise) to keep things going for  
Windows.  That's why we need people like you to help out.

>
>
>  - Jay
>
> Your smile counts. The more smiles you share, the more we donate.  
> Join in!

:-)