Re: Q: access to subprogram

[bobduff@world.std.com (Robert A Duff)]

In article <dewar.836709438@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>If there is no nesting, then neither static links nor displays have
>any overhead at all.
>
>If there is nesting,...
[lots of good stuff]
>It seems clear to me from these considerations that displays will be
>faster than static links for most typical programs.

But, IMHO, there usually is no nesting.  Therefore, the same facts lead
me to think, "If there's a difference, it's negligible."  Therefore,
compilers ought to do what's simplest (IMHO, static links are simpler to
implement).

Also, you analyzed calls, but you didn't analyze the speed of up-level
references.  For a display, it's some-offset added to some-display-
pointer.  For static links, it's some-offset added to
chaining-up-the-links.  Sure sounds like displays are better.
Especially if the display is in registers.  But it depends a lot on what
optimizations are done.  E.g., can the compiler recognize cases where
the nested procedure does no up-level refs?  Can the compiler recognize
cases where the outer procedure's stack frame can be merged with the
environment task's stack frame (i.e. static allocation)?  Can the
compiler notice multiple loads of the same up-level reference?  Can the
display in fact be stored entirely in registers?  These all make a
difference, but IMHO they are second-order effects, given that most code
isn't nested at all.

I haven't seen any studies showing code is not nested.  It's just my
limited experience.  Why would that be?  I don't think nesting is
necessarily evil.  But, in Ada, you need to be at library level to do
true separate compilation, so there's a strong incentive to avoid
nesting.  Subunits allow separate compilation of bodies (in some
compilers), but to get separate compilation of specs, you have to use
library units.

- Bob