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

Re: [f-cpu] calling conventions

On Thu, Jun 06, 2002 at 06:02:17PM +0200, Christophe wrote:
> > > > personally, I'm wondering if it is really necessary to limit function
> > > > argument to r15 instead of r31 or r29 (to be sure to have at least a pair
> of
> > > > temporary registers), in so far as we can consider that all function
> > > > arguments not used by a function may be used as temporary registers by
> this
> > > > function...
> > I am currently asking the same question with a little variation, why
> > not putting in r31 the pointer to parameter allocated stack.
> >
> Yes but still we should not start from r1 but r2 (that is with an even number)
> for function arguments or return values. So what would be the use of r1, number
> of registers allocated as arguments ? don't forget about the fact if you use
> your OPCODE where you need to use or compute a pair (Rn,Rn^1), you couln't use
> r1, instead of r0 which is hardwired to 0.

Imagine the opposite case:

	blah1(int r2, complex r3r4) { ... }

Or let's return a structure:

	struct { int r2, complex r3r4 } blah2(...) { ... }

Now the calling convention is `improved' - but the problem is still
there (i.e. the values are stored in the wrong place).

But it's a dummy argument anyway: There is *no* F-CPU instruction
that expects two of its operands in a (Rn, Rn^1) register pair. As a
consequence, there is no overhead when the function is entered. When the
function is left, there is an overhead of at most *one* move instruction
(e.g. put result in r2:r3, then move r3 to r1). I guess we can afford
that; the function call itself is much more expensive (and when the
function is inlined, the move vanishes automagically).

Let's keep things simple and not `uglify' them, please.

 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/