public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Meissner, Michael" <michael.meissner@amd.com>
To: "Mad Props" <madprops@gmx.net>, gcc-help@gcc.gnu.org
Subject: RE: mips calling conventions
Date: Wed, 10 Aug 2005 19:26:00 -0000	[thread overview]
Message-ID: <6096959DEF5C9447A6BF80BDC7EB9EDC682B7D@SBOSEXMB1.amd.com> (raw)

There are many different MIPS calling sequences, and I've lost track of all of the different variations.

Any way in the original MIPS calling sequence, you did have to provide a homing area of the top 4 words on the stack, where the compiler could store the arguments passed in registers.  This was particularly used by variable argument functions, which would store the arguments, and then va_arg would be a simple char *.  You could optimize things by allocating this area once in your own stack allocation, or you could allocate it just before the call, and remove it after the call. 

-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On Behalf Of Mad Props
Sent: Wednesday, August 10, 2005 9:55 AM
To: gcc-help@gcc.gnu.org
Subject: mips calling conventions

Hi,

I have a question regarding the mips32 calling conventions in gcc. I implement in C++ and use assembly when neccessary. As far as I know the first four arguments are passed in a0 to a3 but space on the stack still needs to be "allocated" for those four arguments. Here is what I've got so
far:


Part I wrote in assembly:

[...]
a000b210:       40044000        mfc0    a0,c0_badvaddr
a000b214:       0c002a3a        jal     a000a8e8 <foo>
a000b218:       03a02821        move    a1,sp
[...]

Code in .cpp file ( Function: extern "C" void foo( unsigned p0, unsigned p1
) )

a000a8e8 <foo>:
a000a8e8:       27bdff98        addiu   sp,sp,-104
a000a8ec:       afbf0064        sw      ra,100(sp)
a000a8f0:       afb00060        sw      s0,96(sp)
a000a8f4:       afa40068        sw      a0,104(sp) [ ??? ]
a000a8f8:       afa5006c        sw      a1,108(sp) [ ??? ]
a000a8fc:       3c02a002        lui     v0,0xa002

...So the assembly part calles foo() and passes two arguments. Do I have to manually decrease the stack pointer by 4*4 bytes now and increment it again when I return ?? It's just - the code produced by gcc seems to smash the stack... On the other hand it seems really weird to me if I had to write somthing like

[...]
mfc0    a0,c0_badvaddr
subi    sp, sp, 16
jal     a000a8e8 <foo>
move    a1,sp
addi    sp, sp, 32
[...]

every time a call a C routine in assembly.

Would be smashing if anybody could help me out.

Thomas

--
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse für Mail, Message, More +++


             reply	other threads:[~2005-08-10 19:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-10 19:26 Meissner, Michael [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-08-10 23:21 MIPS " Meissner, Michael
2005-08-10 20:02 Nelson H. F. Beebe
     [not found] <6741.1123680193@www18.gmx.net>
2005-08-10 13:55 ` mips " Mad Props
2005-08-10 16:21   ` Nathan Sidwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6096959DEF5C9447A6BF80BDC7EB9EDC682B7D@SBOSEXMB1.amd.com \
    --to=michael.meissner@amd.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=madprops@gmx.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).