Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!cbmvax!snark!eric
From: eric@snark.uu.net (Eric S. Raymond)
Newsgroups: comp.arch
Subject: Re: Software modularity vs. instruction locality
Message-ID: <1TQpRh#4tzhKO=eric@snark.uu.net>
Date: 12 Nov 89 17:17:26 GMT
References: <17707@watdragon.waterloo.edu> <23604@cup.portal.com> <1989Nov2.190900.29144@world.std.com> <1989Nov4.004529.10049@ico.isc.com> <1TMk2X#Qggn6=eric@snark.uu.net> <1989Nov9.205356.17585@cs.rochester.edu>
Lines: 16

In <1989Nov9.205356.17585@cs.rochester.edu> Lawrence Crowl wrote:
> (There are also macro-efficiency and software engineering reasons to prefer
> modularity.

Hearty agreement on that (I'm a rather vigorous partisan of ADT methods,
myself).

You describe a set of heuristics for choosing inlining or non-inlining that
make intuitive sense (at least they do now that I've reread your posting
about three times :-)). But it sounds to me as though effective use of those
heuristics might require maintenance of an awful lot of `macro' information
about the code object and its call patterns, including a global flow
analysis. Is this actually done? If not, what kind of less elaborate state
has been found to suffice?
-- 
      Eric S. Raymond = eric@snark.uu.net    (mad mastermind of TMN-Netnews)