ham@Neon.Stanford.EDU (Peter R. Ham) (11/13/89)
I don't understand why the mips port of gcc seems to
reserve r30 as a frame pointer. Why is this necessary?
The mips cc seems to try to avoid this. In addition,
why isn't the value of the stack pointer (r29) assumed
to be preserved across function calls?
For example:
The following c code:
extern void bar();
void
foo()
{
bar();
}
Produces the following assebly:
# .verstamp 2 0
gcc_compiled.:
.text
.align 2
.globl foo
.ent foo
foo:
subu $29,8 # saveregs= 8
.frame $30,0,$31
.mask 0xc0000000,-4
sw $31,4($29)
sw $30,0($29)
addiu $30,$29,8 # define fp
addiu $29,$29,0xfff0 #subsi3 $29,16 -> $29
jal bar # call with 16 arguments
addiu $29,$29,0x10 #addsi3 $29,16 -> $29
addu $8,$0,$30 # don't trust sp?
lw $31,-4($8)
lw $30,-8($8)
addu $29,$0,$8 # sp not trusted here
j $31
.end foo
--
Peter Ham PO Box 3430 (h)(415) 322-4390
MS Computer Science Student Stanford, CA ham@cs.stanford.edu
Stanford University 94309 (o)(415) 723-2067grunwald@foobar.colorado.edu (Dirk Grunwald) (11/13/89)
The MIPS CC simply records this as a constant offset in the assembled output. However, if you want to use alloca, this doesn't always work, because you don't know what value SP has at the end of the fcn, unless you use: + use a malloc-based alloca + stack-copy alloca + maintain an FP. However, it would appear that the MIPS backend could be changed to assume that you're either using one of these things. It *does* give you an temp. register.