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

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



-----Message d'origine-----
De: cedric <cedric.bail@free.fr>
A: f-cpu@seul.org
Date: 16/04/02
Objet: [f-cpu] Register allocation when calling a function

Nobody reply to your post, but I think it's very important to include
this 
recommandation into the manual for those who want to implement a
compiler
or code in F-CPU ASM. 
> > I propose to use the first 8 registers to put the return address
(R1),
> > and the first params (R2 to R8). For the returned value we put the
result
> > in R1. If we have variable number of parameter (like print) we
detect it
> > and put them on stack (R63).

> As a first guess, I'd reserve r1...r15 for arguments (r1 also holds
> the return value), r16...r31 for temporary use (unsaved), r32...r47
> for local use (saved by the callee), and r48...r63 for special
purposes
> (stack pointer, frame pointer, global pointers). If a function has
more
> than 13 parameters, r14/r15 hold the number and address of additional
> arguments, respectively.
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.


>>>> !! Be carefull, if you use struct in c it could be very usefull to
use large register set. The old sparc use 8 register for this !


> The return address should either be stored in the `local' or in the
> `special purpose' register area (that is, r32...r63), in order to
avoid
> copying in `leaf' functions (i.e. functions that don't call other
> functions). If it is stored in r1, you'll have to move it away in
> order to make room for the return value.
Oups, you are right.

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

> > If the used language is C, we know that the parameter will be lost,
but
> > for language like Pascal (or one who use byRef call), that is great,
you
> > can code a function like swap for example in very few instruction :

> > move R2, R4
> > move R3, R2
> > move R4, R3

> > That as quick as a macro without is border effect.

> > (I thing that I have perhaps forgot something about this problem,
because
> > why didn't people use this type of call ?)

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

So who disagree with adding this recommandation into the manual ?

>>> Nop ! but you must say how we came to this conclusion. It must be
change if somebody have a better idea.
nicO

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

 
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif


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