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

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

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

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