[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Tue, Apr 16, 2002 at 04:37:18AM +0200, cedric wrote:
> 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 picked these values because they divide the register space in four
almost equally-sized parts, which gives code and compiler developers
a maximum of freedom. If the partitioning turns out to be suboptimal,
we can still move the borders around a little.

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.

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).

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

> > You overlooked the fact that `var' parameters in Pascal are actually
> > pointers, although they don't look that way. The same is true for
> > reference types in C++.
> That depend on your compiler, no ?

It depends on nothing but our F-CPU API definition :)

 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/