|compiling for mips environment firstname.lastname@example.org (simon) (1999-06-27)|
|Re: compiling for mips environment email@example.com (Zalman Stern) (1999-06-29)|
|Re: compiling for mips environment firstname.lastname@example.org (James Jones) (1999-06-29)|
|Re: compiling for mips environment email@example.com (Chris Dodd) (1999-06-29)|
|Re: compiling for mips environment firstname.lastname@example.org (Matt Postiff) (1999-07-01)|
|Re: compiling for mips environment email@example.com (Michael Meissner) (1999-07-11)|
|From:||Chris Dodd <firstname.lastname@example.org>|
|Date:||29 Jun 1999 03:02:22 -0400|
|Organization:||Alternate Access Incorporated|
> It seems stack usage convention for mips in C environment dictate
> caller reserve space in stack for routine to save arguments a0..a3 if
> it needs to.
> I don't understand this convention, is this standard for risc
Most RISC architectures use register based calling conventions, and
most do something much like this for C calling conventions, in order
to more easily support C varargs functions. The idea is that a
varargs function can just spilll a0..a3 to the preallocated stack
slots, and then act as if all the arguments are on the stack.
For java, however, you always have complete argument type information
and don't have to deal with varargs. If possible, you're better off
using your own calling conventions (which can be specialized on a
per-signature basis), and only using the ABI (or C) calling
conventions for external and native functions.
There are 3 significant improvements you can get easily:
1. using more the 4 argument registers for methods with more than 4
arguments. This is particularly important if you need 1 or more
hidden arguments (such as `this')
2. using floating point registers for fp arguments. I'm not sure about
MIPS but on some machines, moving values between int and fp registers
3. avoiding holes in the allocated stack frames that are untouched. This
is only really important when using a conservative garbage collector,
as old, dead pointers can live on for long periods of time if they
happen to be in such a hole.
> [It's pretty standard. Most routines don't have more than four arguments,
> so it'd be counterproductive to reserve argument registers that won't
> be used, -John]
With complete type info, you need only reserve the registers for those
functions/call sites that need them...
Return to the
Search the comp.compilers archives again.