Need for Faster Function Calling

["David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>]

    Date: Thu 16 Jun 88 15:58:19-PDT
    From: STICKEL@Warbucks.AI.SRI.COM (Mark Stickel)
    
    Function calling on the Symbolics 3600 is too slow for some
    applications.  Each call to the function foo, defined by (defun foo ()
    nil), costs in excess of 4 microseconds on a Symbolics 3600 with IFU
    according to my timings.  In contrast, the JSR/RTS call/return
    instruction pair on a 10MHz 68000 (outdated Sun-2 workstation
    technology) costs less than 4 microseconds, and 25MHz 68020s and 68030s
    are much faster.
    ....
    There are compensating benefits for the slowness: the ability to change
    the function definition without recompiling the call, to view the
    function call and its arguments in the debugger, etc....

I don't disagree with anything you said, including the parts I elided for
brevity, however I have some comments.  I don't think these will satisfy
your immediate need, but I thought it was worthwhile in any case to point
out some facts.

First, I'm uncomfortable with a comparison between a function call and an
assembly language instruction sequence.  The function call might be doing
more for you than the instructions, and I don't mean just debuggability.
It would be better to compare against a function call in an actual Lisp
implementation on the 68020.  Whether my remark here is relevant depends on
whether that JSR/RTS sequence is in fact all that needs to be generated for
the corresponding Lisp function call.

A more important point is that no one cares about the speed for calling a
function that doesn't do anything.  It would be more realistic to compare a
function that takes a couple arguments, does some simple computation, and
returns one value.  I think you'd find the 3600 and 68020 have a smaller
performance gap in this more realistic case.

The 3600 architecture as designed in 1982 included a "quick function call"
very much like what you suggested.  However, we learned an interesting
thing when we did a trial implementation of it, which was that it was not
actually significantly faster than the regular function call.  This came as
a surprise and caused us to drop the quick function call from the
architecture.  I don't remember the analysis of the reasons why quick
function call wasn't any faster, but I think it was along the lines that
most of the overhead eliminated had been done in parallel with the
branching delay, so little time was actually saved.

Finally, this isn't the first time the issue of speeding up function call
has been brought up, and our response was to make the Ivory chip use a
redesigned function call architecture which is about three times faster
(even if the processor clock cycle times were equal) than the 3600, without
giving up any of those benefits.  It does require some increased complexity
in the compiler, loader, and debugger, but that's all invisible to the
user.  The new function call architecture was made possible by the
increased amount of special-purpose hardware to assist function call that
you can have on a chip, as opposed to a processor made out of standard
components, and also by better pipelining and generally cleverer design.

At this stage in the 3600's life, I think it's better for both Symbolics
and our customers to concentrate our limited resources on getting the Ivory
out, with high software and hardware quality, rather than further tweaking
the 3600.  As a changing cast of Symbolics spokesmen have been saying for
quite some time, Ivory-based products will be available in the second half
of 1988.  I'm not allowed to comment now on when during that half-year they
will be available.