Re: compiling for mips environment

"simon" <simon@gatecrashers.com> writes:
> 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
> architecture?


As many people have said, this is to support stdarg/varargs by
providing a place to store the the arguments. Then the va_list type
is just char *, and the va_* macros are fairly simple.


There are 5 different ABI's for the mips that GCC currently supports
(32, N32, 64, eabi, O64). In the eabi for instance you don't have the
save area, and stdarg/varargs becomes more complicated and va_list is
a structure that points to two separate save areas (the gprs followed
by the arguments passed on the stack, and the fprs).


> I have decided to follow register usage convention which gives me
> "temp" registers and "saved" registers, saved ones are preserved
> across function calls.
>
> This seems an OK convention but I can't get a grip on why parameters>4
> are pushed on the stack with so many registers spare.


Probably because when the Mips people established their abi the code
they looked at didn't have so many registers.


In terms of ABI'S, I haven't met an ABI that didn't have flaws in it,
even when I designed the ABI in the first place. I've worked on at
least 10 GCC targets where I've needed to know the ABI and some of
these targets have multiple ABI's (mips and powerpc), and fixed bugs
in a few more where I didn't really need to bone up on the ABI, plus
the ABI's I encounted in school and previous employment. All ABI's
are essentially a comprimise between different needs. ABI's are the
ultimate in backwards compatibilty -- you are often times hampered by
choices made by the original ABI designer. For example, the MIPS is
somewhere around 15 years old, and the 360 has passed its 25 or 30
year milestone.


So if you are going to design your own abi, here are some things you need to
think about (from a C centric point of view):


      1) Pass arguments in registers or on the stack?


[i386 on stack, most RISC in registers]


      2) Do you pass floating point in integer registers, floating point
registers, or both under some circumstances.


[Mips passing FP in integer registers after the first non-FP
argument, AiX/mac passing values in both integer and fp
registers if stdarg or no prototype]


      3) Do you have a separate calling sequence for stdarg functions? If so,
what do you do about people who call printf without including stdio.h?
Presuming you have a separate calling sequence, then you can't support
the old pre-ISO C varargs.h.


[i386, ns32k with -mregparm do this -- typically the answer is
tough luck on printf, since the standard requires you to
include stdio.h]


      4) How complex do you want the va_start/va_arg/va_end macros to be? If
you make these complex, you will slow down printf and friends, but
might speed up functions that don't use variable arguments and/or use
less stack space.


[Powerpc eabi/linux use 2 separate save areas + the stack]


      5) Can you have holes in the registers passed (ie, if you pass a 32-bit
argument followed by a 64-bit argument is a register skipped so the
64-bit item is passed in an aligned register)?


[Powerpc eabi/linux]


      6) What is your stack alignment?


      7) Are all structures passed in registers/stack or is a copy made and the
address passed? Are there exceptions for small structures. Are
structures always passed in the stack and never in registers?


      8) How do you return structures? Is there an exception for small
structures. Can you return variable-sized structures?


[typically you pass a pointer in as the first argument or in a
reserved register that gives the location to copy the structure
back into, and there is no provision for variable sized
structures].


      9) Is there a fixed frame layout that must be used by the compiler.


    10) Is 'char' sign extended or zero extended?


    11) Does right shift of a signed integer replicate copies of the sign bit,
or 0?


    12) What is the rule for structure layout?


--
Michael Meissner, Cygnus Solutions
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886
email: meissner@cygnus.com phone: 978-486-9304 fax: 978-692-4482

Return to the comp.compilers page.
Search the comp.compilers archives again.