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 +++
next 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).