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

Re: Rep:Re: Rep:Re: Rep:Re: [f-cpu] Stack handling



>>Yes but the objectives of this paper was not to restart a discution 
>>about this. And I think the actual call convention was not ok, we have 
>>some language/compiler specific feature, and we have thing like frame 
>>pointer that was not calling convention related but function prefix code 
>>related.
> 
> 
> If we want to link the output of several compilers (or written in several
> languages), we need to fix things. We also have to define a process<->OS
> kernel API.

for all external function you use the standard CC, it's deigned for 
that, but not all function was exported and for the other you could 
(must?) use a CC optimized for your language/compiler.

> A single user stack pointer is important for the OS kernel: it
> indicates how much stack memory the process has allocated. That does
> not mean that the register has to be changed on every push/pop, which
> leaves room for optimization.

I never say the contrary, and I defend a best stack handling in the FCpu 
ISA.

> A frame pointer is not strictly required in any language, but helps with
> debugging: programs like gdb use it to trace function calls. Therefore,
> all compilers/languages that support a frame pointer must use the same
> register.

We can suggest a reg for Frame Pointer and if a compiler use it could be 
used by debugger, but I think this is not directly a part of CC because 
the stack frame was made by the function called, not the caller.

> An explicit "number of arguments" argument, on the other hand, is not
> required by most languages. It's the compiler's job to make sure the
> number of arguments is correct, except in languages like Lisp (but in
> Lisp, you may have to use different calling conventions anyway).
> 

Yes but in inter-language call, one of the most common error was bad 
argument number, (the second was problem about argument type, and after 
you can found, alignment in record).
The compiler never known if the other compiler have make good job...

But for internal function he known he have made good job (I hope :-)) so 
   for internal CC, we don't need it. (It was one of the point discussed 
in the part not finished of the draft)


-- 
Thomas Lavergne                       "Le vrai rêveur est celui qui rêve
                                        de l'impossible."  (Elsa Triolet)
thomas.lavergne@laposte.net
d-12@laposte.net    ICQ:#137121910     http://assoc.wanadoo.fr/thallium/

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