Re: [f-cpu] Call convention resume

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

> > On Sun, Jun 23, 2002 at 02:10:57PM +0000, cedric wrote:
> > > Hi every body,
> > >
> > > I will try to do a resume of what has been say about call convention
> > > during the last week, before updating the manual.

> > > R0: zero
> > > R1 : number of parameter (for debug and security) and return value

> > I still do not agree with that point. It's a waste.

> Not only it is a waste but it is unefficient. Why ? how many arguments
> for such function : int f (struct a _a) ? 1 or the number of words necessary
> for struct a ? it doesn't make a sense to have one. If you really want a debug
> info, pass a parameter signature instead, something like C++ functions
> signature but just for parameters. So if you call a function with three
> integer arguments then passing the string "iii" (for example) would be more
> precise and usable for debug than just passing number of arguments.
> Personnally i would drop it.

I understand your point of view but I am thinking that with this we can remove
all the "format string" like bug, and have a better security in the system.
I am not sure and I need to read more documentation before.

But it's sure that when we say a parameter, we need to clarify if it's a
number of register, or word, or something else (perhaps, we have some binary
compatibility problem, when we change the size of a register)

> > > R2-R15 : functions arguments (call-clobbered)
> > >
> > > R15-R31 : temporary registers (call-clobbered)
> > > R32-R58 : local registers (callee-saver)
> > >
> > > R59 : return adress
> > >
> > > R60 : pointer to the Procedure Linkage Table
> > > R61 : pointer to the Global Offset Table
> > >
> > > R62 : Frame pointer (Function Entry Frame)
> > > R63 : stack pointer after which the parameters after the 14th are
> > > push in reverse order (Function Entry Frame - number of bytes allocated)
> >
> > Better make r61 (or r63) the return address. Statically linked programs
> > don't use the PLT and GOT pointers, and we don't want to have a hole in
> > the middle.

> > The stack pointer is always the end of the allocated area on the stack.
> > If a program uses memory from the stack, it MUST move the stack pointer.
> > That way, the operating system can tell how big the user mode stack is.

> I totally aggree with Michael; something like :

> R63/62 : return pointer (RP) , mandatory
> R62/63 : stack pointer (SP) , mandatory
> R61       : frame pointer (FP) , optional
> R60       : GOT                        , optional
> R59       : PLT                         , optional

I agree with your point of view for the last register, but I think that
we didn't need anymore an argument pointer and that we use the SP instead,
with a reverse ordered list of argument.
 
> R14 should point on the first argument pushed in stack, so we can access
> it as an argument pointer (AP)
> R14,R61 and R62 all point on the same stack indeed.
 
> Personnally I would have used R60 for AP instead of R14, unless there is
> a real reason to choose r14.
 
A+
  Cedric
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/