Related articles |
---|
Callee-save caller-save shreyas76@gmail.com (shrey) (2005-09-30) |
Re: Callee-save caller-save cleos@nb.sympatico-dot-ca.remove (Cleo Saulnier) (2005-10-03) |
From: | Cleo Saulnier <cleos@nb.sympatico-dot-ca.remove> |
Newsgroups: | comp.compilers |
Date: | 3 Oct 2005 00:19:08 -0400 |
Organization: | Aliant Internet |
References: | 05-09-146 |
Keywords: | code, design |
Posted-Date: | 03 Oct 2005 00:19:08 EDT |
shrey wrote:
> Hi ,
> Can some one tell me how the concept of callee -save and caller
> save registers ties in with register allocation process in general. I
> understand the process of register allocation, but wonder how this
> restriction ties with the process. My only guess is that it acts as a
> constraint when assigning registers, so some values have to be put in
> either callee save or caller save based on the convention. Is that how
> it is ?
Your question confuses me.
Register allocation... it's all compiler dependant (and CPU dependant
of course). For system routines, you'll have to read the
documentation, but usually you have to assume all registers to be
dirty after a call.
Basically, there's a set of registers that a function is allowed to
use without restoring them. And if the function wants to use the
other remaining registers, it will have to save them and restore them
later. The compiler decides which register are what kind. Of course,
you'll allocate first the registers that you don't need to restore.
I've seen eax, ecx, edx as function usable... ebx, esi, edi as
must-restore registers and esp, ebp as global on i386. I've also seen
where all GP registers are free for use.
If you're talking about calling a function with arguments in the
registers, that's different. That's "fastcall" type function and is
again very compiler dependant. There's also stdcall and cdecl type
functions. These affect the order of arguments and who pops the
arguments off the stack... nothing to do with register allocation.
Cle
Return to the
comp.compilers page.
Search the
comp.compilers archives again.