[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Rep:[f-cpu] Another proposition for a call convention
----- Original Message -----
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
To: <f-cpu@seul.org>
Sent: Friday, June 07, 2002 5:45 PM
Subject: Re: Rep:[f-cpu] Another proposition for a call convention
> Christophe wrote:
>
> > R60 : return adress
> > R61 : global pointer
> > R62 : Frame pointer
> > R63 : stack pointer
> (snip)
> > Are you speaking about frame pointer ? the only real purpose of frame
pointer
> > is to help for debug but in a release we don't really need a frame pointer.
> > Unless it is the case for IA32 for example, and I'm quite sure for most
other
> > CPUs too. There is no real reason to get rid of it nor to be forced to use
it.
> > So I think it shouldn't be a problem.
>
> I think pascal needs a base pointer for stack frames as well as a frame
> pointer.
Ok I was just in fact speaking about C, not for other languages.
> With languages that use objects like C++ you could have a lot of hidden
> pointers
> used for message passing and indirect function calls.
Does C++ have message passing !?
If you are spoken about 'this', it is usually considered as the hidden first
argument, that is r1 (or r2 if r1 cannot be an argument register).
In fact you can call a C++ method like :
int C::f (int arg);
in C that way :
int f__1Ci (void *this,int arg);
VMT is accessing via 'this', so it is usually a temporary register.
Because there are numberous objects, I could be wrong but it doesn't make a
sense to put anything from an object in global registers.
However, if we want some PIC (Program Independent Code ?) and need GOT (Global
Offset Table), yes okay we can use global registers for that. PIC is a way for
each process to use shared library mapped at different virtual addresses. Of
course, it is not a C++ issue.
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/