It doesn't matter what you think. It doesn't matter what I think. The point
is there are ABI's out there which have a completely different calling sequence
depending on what the arguments are, and GCC has to fit in with that ABI, no
ifs and, or buts. For example, consider the original MIPS calling sequence
(note, it has been a few years since I wrote for that particular ABI, so I may
be wrong on a few details):
1) If the function takes variable arguments, the first 4 arguments are
passed in registers, every thing else is passed on the stack.
2) If the first 1 or 2 arguments are floating point they are passed in
appropriate fp registers. If any floating point argument occurs after
a non floating point argument is found, it is passed in the general
purpose registers.
3) Up to 4 words are passed in gprs (and anything passed in the fprs
counts against the 4 words), the remainder are passed on the stack.
Note, the reason for such complicated calling is to try and optimize the common
case. If you pass everything on the stack, that means at least 2 memory
references per argument that might not be needed. If you pass fp values in gpr
registers, you need either a costly move between the fprs and the gprs (in the
case of the MIPS -- yes, it is only two instructions, but the latency is
something like 3 cycles in the original MIPS), or you have to store and load
(in the case of the PowerPC). In my 23+ years of hacking languages, I haven't
met an ABI that didn't have warts, even in the ABIs I designed myself.
> (I prefer "polymorphic") code working across systems. I've JUST, after
> maybe 6 months of trying, managed to get my compiler compiler working
> under g++ as well as under gcc. The holdup is largely due to the
> incompatibility of c++ with c in the area of polymorphic typing
> (instantiations in C++ must be declared polymorphic too, whereas in C
> they'll be able to have base types) but some of the blame lies with
> obscure register passing implementations across compilers and platforms.
> I use polymorphic core library functions - 'nuff said.
ABIs these days tend to be designed by people trying to optimize the C
language. Its a slight step up from designing ABIs for Fortran IV, which was
common when I was in college.
> Actually, ix86 gcc 2.7.* is regular in the way it works - thank goodness.
> Can't say the same about solaris. If someone would like to explain the
> distribution of stack variables and register variables under solaris
> compilers, feel free. Seems something like "if it's size 2 or 4 bytes
> and it's tuesday, put it on the stack .. otherwise use miraculous
> indirection". Compilers seem to be playing silly games for speed when
> it would be much faster if they would do things regularly and
> predictably so that I could just map whole stack regios across. When
> calling one polymorphic function from another I just want to pass a
> pointer to the region containing its args, not collect the args up one
> by one then make another call. No - I can't use a passable array the
> whole time. Some of these functions come from user space and users don't
> play ball. </frustrated complaint about silly varargs implementations>
And such calling sequences are much slower, so you are penalizing maybe 90% or
99% of the code to get relief in one area. Deal with it (I'm not unsympathetic
to your pleas, I just don't think the world is going to slow down to accomidate
special cases).
-- Michael Meissner, Cygnus Solutions (Massachusetts office) 4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA meissner@cygnus.com, 617-354-5416 (office), 617-354-7161 (fax)- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/