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

[cedric <cedric.bail@free.fr>]

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.

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.

> 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 agree with you, we can only do now a first specification for the border 
because we didn't have any asm code or compiler to see a result. The most 
logical is to equally divide the register bank.

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

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.

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

> > > 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 :)
A right to.

A+
  Cedric
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/