jat@ranger.austin.ibm.com (John Tamplin) (11/16/89)
In article <1989Nov14.175806.23483@paris.ics.uci.edu> Ron Guilmette writes:
: I was unhappy to see that these two standards have mandated (for those who
: choose to adhere to them) what I believe is a somewhat sub-optimal function
: calling sequence. While it is true that the abundance of registers on the
: 88k does significantly improve the efficiency of parameter passing in the
: great majority of cases, I have been distressed to see that (a) you
: are limited to passing at most 8 words worth of actual parameters in
: registers (which seems an unnecessary and artificial limit to me) and
: (b) more significantly, there seems to have been a major departure from
: the common practice in the good ol' CICS days when callers could assume
: that almost all registers (except for the one which got the return value)
: were *preserved* across a "standard" call.
:
: It seems to me that (b) effectively ties the hands of many otherwise very
: sophisticated modern optimizers (with nice graph-coloring register allocators
: of course).
:
: Am I right that this is an artificial "man-made" performance barrier? If
: so, what was the motivation?
:
: Inquiring minds want to know! :-)
:
: // rfg
Well, the compiler can't assume all registers are unchanged anyway, since you
have to return a value. It is a slight extension of this to allow any given
set of registers to be "call-used". Gcc allows you to set which registers
are preserved across calls and which are used. The overhead of saving all of
the register values that you use can outweigh the efficiency gained by keeping
values in registers. In fact, I saw a reference where someone claimed that
gcc produces better code on 68k processors by declaring more registers
"call-used". I think they made the tradeoff at a very good point.
John Tamplin