RE: MIPS calling conventions

RE: MIPS calling conventions

[Meissner, Michael]

Looking at the source, there are at least 5 different ABIs in mips.c.  I
believe Sony has designed another ABI for use in the PSP system, but
those sources are not integrated at the FSF.  I don't recall which ABIs
P&H describes in their book.  Note, GCC can use a frame pointer if it
has allocates variable size auto variables, or if the user directs it
with -fno-omit-frame-pointer. 

-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
Behalf Of Nelson H. F. Beebe
Sent: Wednesday, August 10, 2005 4:02 PM
To: Mad Props; gcc-help@gcc.gnu.org
Cc: beebe@math.utah.edu
Subject: Re: MIPS calling conventions

"Mad Props" <madprops@gmx.net> asks on Wed, 10 Aug 2005 15:55:12 +0200
(MEST) about the calling conventions used by gcc on the MIPS
architecture.

An excellent resource that I strongly recommend that you get is this
recent book:

@String{pub-MORGAN-KAUFMANN     = "Morgan Kaufmann Publishers"}
@String{pub-MORGAN-KAUFMANN:adr = "2929 Campus Drive, Suite 260, San
                                  Mateo, CA 94403, USA"}

@Book{Patterson:2004:COH,
  author =       "David A. Patterson and John L. Hennessy",
  title =        "Computer Organization: The Hardware\slash Software
                 Interface",
  publisher =    pub-MORGAN-KAUFMANN,
  address =      pub-MORGAN-KAUFMANN:adr,
  edition =      "Third",
  pages =        "xvii + 621",
  year =         "2004",
  ISBN =         "1-55860-604-1",
  ISBN-13 =      "978-1-55860-604-3",
  LCCN =         "QA76.9.C643 H46 2004",
  bibdate =      "Mon Nov 15 16:01:50 2004",
  price =        "US\$64.95",
  acknowledgement = ack-nhfb,
}

There are two conventions used by compilers on the MIPS architecture for
argument passing: one keeps a constant frame pointer within each
procedure, addressing local variables at constant offset from the frame
pointer (native SGI IRIX compilers do this), and the other dispenses
with the frame pointer, and uses only the stack pointer, which changes
during execution of the procedure, and thus variable offsets change as
well (gcc does this).

This is described on pp. 86ff of the above book, and in Appendix A,
which is not printed, but is on the book's CD-ROM inside the back cover.
The CD also contains the SPIM simulator for the MIPS architecture, but a
newer version is now available here:

	http://www.cs.wisc.edu/~larus/spim.html
	http://www.cs.wisc.edu/~larus/SPIM/spim.tar.gz

With the book and the simulator, you should then have the tools you need
for your work with gcc on MIPS.

Other resources include these books:

@String{pub-PH                  = "Pren{\-}tice-Hall"}
@String{pub-PH:adr              = "Upper Saddle River, NJ 07458, USA"}

@Book{Kane:MRA92,
  author =       "Gerry Kane and Joe Heinrich",
  title =        "{MIPS RISC} Architecture",
  publisher =    pub-PH,
  address =      pub-PH:adr,
  year =         "1992",
  ISBN =         "0-13-590472-2",
  ISBN-13 =      "978-0-13-590472-5",
  LCCN =         "QA76.8.M52 K37 1992",
  bibdate =      "Wed Dec 15 10:35:45 1993",
}

@Book{Sweetman:1999:SMR,
  author =       "Dominic Sweetman",
  title =        "See {MIPS} run",
  publisher =    pub-MORGAN-KAUFMANN,
  address =      pub-MORGAN-KAUFMANN:adr,
  pages =        "xviii + 488",
  year =         "1999",
  ISBN =         "1-55860-410-3",
  ISBN-13 =      "978-1-55860-410-0",
  LCCN =         "QA76.9.A73 S88 1999",
  bibdate =      "Thu Jun 20 10:21:55 2002",
  price =        "US\$52.95, UK\pounds 35.95",
  acknowledgement = ack-nhfb,
  keywords =     "MIPS (Computer architecture); RISC microprocessors;
                 Embedded computer systems --- Programming",
  libnote =      "Not yet in my library.",
}

and these manuals:

	http://www.mips.com/Documentation/R4400_Uman_book_Ed2.pdf
	
http://www.ece.mtu.edu/faculty/rmkieckh/cla/3175/MIPS-R10K-uman1.pdf
	http://www.mips.com/Documentation/MIPSPro_Ass._Lang_Vol1.pdf
	http://www.mips.com/Documentation/MIPSPro_Ass._Lang_Vol2.pdf

------------------------------------------------------------------------
-------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254
-
- University of Utah                    FAX: +1 801 581 4148
-
- Department of Mathematics, 110 LCB    Internet e-mail:
beebe@math.utah.edu  -
- 155 S 1400 E RM 233                       beebe@acm.org
beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA    URL:
http://www.math.utah.edu/~beebe  -
------------------------------------------------------------------------
-------

Re: MIPS calling conventions

[Nelson H. F. Beebe]

"Mad Props" <madprops@gmx.net> asks on Wed, 10 Aug 2005 15:55:12 +0200
(MEST) about the calling conventions used by gcc on the MIPS
architecture.

An excellent resource that I strongly recommend that you get is this
recent book:

@String{pub-MORGAN-KAUFMANN     = "Morgan Kaufmann Publishers"}
@String{pub-MORGAN-KAUFMANN:adr = "2929 Campus Drive, Suite 260, San
                                  Mateo, CA 94403, USA"}

@Book{Patterson:2004:COH,
  author =       "David A. Patterson and John L. Hennessy",
  title =        "Computer Organization: The Hardware\slash Software
                 Interface",
  publisher =    pub-MORGAN-KAUFMANN,
  address =      pub-MORGAN-KAUFMANN:adr,
  edition =      "Third",
  pages =        "xvii + 621",
  year =         "2004",
  ISBN =         "1-55860-604-1",
  ISBN-13 =      "978-1-55860-604-3",
  LCCN =         "QA76.9.C643 H46 2004",
  bibdate =      "Mon Nov 15 16:01:50 2004",
  price =        "US\$64.95",
  acknowledgement = ack-nhfb,
}

There are two conventions used by compilers on the MIPS architecture
for argument passing: one keeps a constant frame pointer within each
procedure, addressing local variables at constant offset from the
frame pointer (native SGI IRIX compilers do this), and the other
dispenses with the frame pointer, and uses only the stack pointer,
which changes during execution of the procedure, and thus variable
offsets change as well (gcc does this).

This is described on pp. 86ff of the above book, and in Appendix A,
which is not printed, but is on the book's CD-ROM inside the back
cover.  The CD also contains the SPIM simulator for the MIPS
architecture, but a newer version is now available here:

	http://www.cs.wisc.edu/~larus/spim.html
	http://www.cs.wisc.edu/~larus/SPIM/spim.tar.gz

With the book and the simulator, you should then have the tools you
need for your work with gcc on MIPS.

Other resources include these books:

@String{pub-PH                  = "Pren{\-}tice-Hall"}
@String{pub-PH:adr              = "Upper Saddle River, NJ 07458, USA"}

@Book{Kane:MRA92,
  author =       "Gerry Kane and Joe Heinrich",
  title =        "{MIPS RISC} Architecture",
  publisher =    pub-PH,
  address =      pub-PH:adr,
  year =         "1992",
  ISBN =         "0-13-590472-2",
  ISBN-13 =      "978-0-13-590472-5",
  LCCN =         "QA76.8.M52 K37 1992",
  bibdate =      "Wed Dec 15 10:35:45 1993",
}

@Book{Sweetman:1999:SMR,
  author =       "Dominic Sweetman",
  title =        "See {MIPS} run",
  publisher =    pub-MORGAN-KAUFMANN,
  address =      pub-MORGAN-KAUFMANN:adr,
  pages =        "xviii + 488",
  year =         "1999",
  ISBN =         "1-55860-410-3",
  ISBN-13 =      "978-1-55860-410-0",
  LCCN =         "QA76.9.A73 S88 1999",
  bibdate =      "Thu Jun 20 10:21:55 2002",
  price =        "US\$52.95, UK\pounds 35.95",
  acknowledgement = ack-nhfb,
  keywords =     "MIPS (Computer architecture); RISC microprocessors;
                 Embedded computer systems --- Programming",
  libnote =      "Not yet in my library.",
}

and these manuals:

	http://www.mips.com/Documentation/R4400_Uman_book_Ed2.pdf
	http://www.ece.mtu.edu/faculty/rmkieckh/cla/3175/MIPS-R10K-uman1.pdf
	http://www.mips.com/Documentation/MIPSPro_Ass._Lang_Vol1.pdf
	http://www.mips.com/Documentation/MIPSPro_Ass._Lang_Vol2.pdf

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe@math.utah.edu  -
- 155 S 1400 E RM 233                       beebe@acm.org  beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe  -
-------------------------------------------------------------------------------

RE: mips calling conventions

[Meissner, Michael]

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 +++

Re: mips calling conventions

[Nathan Sidwell]

Mad Props wrote:
> 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:

this is true for integer args, I think (but I'm not sure) floating point args 
are passed differently.  The definitive answer would be in the mips psABI 
document (google is you friend).

> [...]
> mfc0    a0,c0_badvaddr
> subi    sp, sp, 16
> jal     a000a8e8 <foo>
> move    a1,sp  <-- not sure why you have this
> addi    sp, sp, 32
> [...]
> 
> every time a call a C routine in assembly.
Yes, you need to do this.  Though most of the time, you can just have the stack 
permanently depressed through out your function.  GCC does this for instance.

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

mips calling conventions

[Mad Props]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 1560 bytes --]

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 +++