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

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


Michael Riepe wrote:
> 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...

argh... but i'll try to used DirectFB now so i hope i'm safe ;-)

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

i like this way of thinking ;-)

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

good idea.

> 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 have no idea about it.

> [...]
> > > 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.
This is a compile-time tradeoff. If you compile with -O3 and have enough cache,
it shouldn't be a problel.

> [...]
> > > 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 :)
one has 63 usable registers, 8 can point to instructions and 8 to data (at least,
and for FC0). It's everyone's job to find his own optimal register allocation, 
depending on the application.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/