Re: [f-cpu] Register allocation when calling a function

[Michael Riepe <michael@stud.uni-hannover.de>]

On Tue, Apr 17, 2001 at 03:24:50AM +0200, cedric wrote:
> Hi,
> 
> > > I never see a function with more than 10 arguments, and the one who have
> > > more must be put in memory (like print). I think that r1 to r10 will be
> > > enough. But it's really important, because this register are in the same
> > > case as the r16..r31 unsaved register.
> 
> > I think there were some functions in the X Toolkit Intrinsics...
> > Plus any function which takes a variable number of arguments.
> I think that variable size register can not be use directly mapped into the 
> register, because in C, we use them like a vector and we can pass them
> from a function to an other without any problem. So it's why I think that
> in case of variable number of argument only r14/r15 will be used.

No, the calling conventions must be compatible with regular functions.
Otherwise, the ISO C standard will be violated now and then.

> For example, in print, you will have the first register that point to the 
> char* and in r15 a pointer to the parameter list. The problem is that, in C, 
> we never use, and never specify a number of parameter.

We could - but it would make the function entry code more complex.

[...]
> > On the other hand, compilers can support several different calling
> > conventions (see the `regparm', `cdecl' and `stdcall' attributes in gcc),
> > so we could define additional `special-purpose' models for applications
> > that suffer from register pressure in one area or another.
> If they suffer from register pressure, that mean that they are doing a big 
> complex calcul (like RC5), and in that case the best way is to save all the 
> register and to say that the function can do all what she want.

If the computation takes long enough to justify the save/restore overhead,
this is a reasonable option.

> The cost of saving the register will not be so important because the code of 
> the function will be really big (it's hard to use 63 registers).
> 
> > BTW: argument registers are unsaved, too -- or should I say
> > `caller-saved'? In either case, the callee is free to modify them as
> > it sees fit (that includes using them as temporary registers).
> I think that saying caller-saved is a good way to mean that temporary register 
> that would be destroy after the call. And I think that coding a register 
> allocation algorithm that can detect this type of dependency will not be very 
> hard and we can have some good result.

I think the gcc terminus was `call-clobbered'.

> > > > Note that these rules do not apply if a function is only called from
> > > > inside the same translation unit (in C: if the function is declared
> > > > `static' and its address is not passed to other functions), or is an
> > > > inline function. Local functions in Pascal-style languages may also
> > > > fall into this category.
> > >
> > > Of course if a function is in the same translation unit (like static), it
> > > will be included into the calling function.
> >
> > Not in any case. If there is a big static function which is called
> > from several places, inline substitution is probably not a good thing.
> 
> It depend on the memory cost you want to pay. Always a choice :
> reduce the necessary memory or have better performance.

Don't forget the cache size. Inline code isn't always the fastest.

BTW: ISO C99 says that `Making a function an inline function suggests
that calls to the function be as fast as possible.'  That means that you
don't have to substitute every call, but that you're free to choose a
different calling convention, or something similar (you can also ignore
the `inline' specifier if you want).

-- 
 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
 "All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/