Re: Caller allocates space for callee-save registers

henry@zoo.toronto.edu (Henry Spencer) writes:
>> our moderator writes:
>>[It is my impression that with a reasonably smart compiler stack windows
>>are a big lose because the compiler can usually cut the register save
>>traffic to memory far below what windows do...
>
>John Mashey (of MIPS) commented on this a few years ago, in a talk and in
>response to a question I asked him about it afterward. What he said was
>roughly:
>
>1. For languages like C on a register-rich machine, careful choice of
>calling conventions plus a smart compiler can essentially eliminate the
>performance advantages of windows for real programs.


It depends on what is real for you.


I would like to point out that important special case where C, C++ or
other code calls library routines in FORTRAN, e.g. IMSL. Because there
tend to be lots of nuisance arguments, and most often the code has been
utterly separately compiled, you end up with poor register use. You can
tell if this is the case if a SPARC runs the code faster than it has a
right to compared to a MIPS. When the library function is dynamically
loaded, (e.g. the case where the calling program is Splus) then you have
the problem that neither program was compiled with any real knowledge of
the register use of the other and it will be a very smart compiler indeed
that can sort this one out.


A factor which exacerbates this problem is that usually, there is a layer
of user-supplied interface code which does some kind of argument
translation, and this layer is normally provided by people who are not
thinking about register use as much as they are thinking about row/column
ordering fiascoes and making sure all the referenced types correspond
exactly (since whatever type checking they have on one side of the call is
meaningless on the other.


Now these two examples are drawn from my daily real-world application use;
and there's no use complaining that I don't have source for Splus or IMSL.
If I look at the cost of improving performance by getting source, or
rewriting, then it's far cheaper to buy some more iron. In other words,
this situation is essentially permanent since the best thing to do is
throw hardware at a source level software problem. (You can also view this
as a language design problem.)


I suspect that this problem is an orphan from the point of view of
computer science; despite the fact that it more or less naturally and
continually occurs in practical experience. The hardware designer wants to
think of this as a software problem, the language designer almost never
thinks about tying into code in languages he can't control, the compiler
writer assumes that the application developer will change his evil ways by
updating his source...


What really happens is that the customer (me) looks at how much money and
sweat he will have to expend to get the problem solved and then picks the
hardware solution, since it is essentially zero sweat and capital
competitive. So even though other RISC boxes out there have that great
top end MFLOP figure, I'll still have to give all those registers their
due. Since register window access is a cheap, but essentially equally
useful way to have lots of registers I think I'll probably be seeing this
kind of hardware in my picture for a while to come.


Later,
Andrew Mullhaupt
--

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