From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 3 Dec 92 17:47:14 GMT
From: noc.near.net!inmet!ryer@uunet.uu.net  (Mike Ryer)
Subject: Re: The cost of is separate
Message-ID: <1992Dec3.174714.13150@inmet.camb.inmet.com>
List-Id: <comp.lang.ada>

This is not statistical data, but it might still be interesting:

When the compiler sees an "is separate", it knows that some code that has
not yet been compiled will have access to all of the local data and
subprograms -- things that would normally only be accessible within the
unit currently being compiled.  Therefore, it can't tell:

  -whether an apparently unused variable is not going to be used
  -whether a local subprogram will be called only once
  -how often a given local variable is accessed
  -etc.

I believe that all current Ada compilers go all the way through code generation
at compilation time.  Therefore, the compiler has to make decisions about
packing of data into registers, dead store elimination, procedure calling
sequences, etc. before having seen the separate subunit.  It has to assume
that the tbd subunit will access every variable and call every procedure that
it can (by scoping rules).  This pessimizes the code for the unit being
compiled (containing the "is separate").  For instance, things that should
have been made register variables may have to be kept in memory in case the
subunit references them.  The call site of the subunit is a potential access
to every visible variable, so live/dead analysis for variables becomes less
accurate, resulting in sub-optimal register allocation.  Etc.  Thus, the 
use of subunits may not hurt the code for the subunit itself, but will hurt 
the parent unit.

It occurs to me that if the compiler has to view the subunit as "unknown
mucking around with everything in sight", that the human who is reviewing
the parent unit must make the same assumption.  Even if the human reviewer
happens to have already seen the subunit, he has no assurance that it won't
change after the design of the parent unit has been blessed (never to be
analyzed again).

So, my take is that splitting off a subunit whenever a given unit exceeds a
size threshold is harmful from a software engineering (reliability and
maintainablity) view, as well as a performance hit.  Was the rule made
by a technical person?

Mike Ryer
Intermetrics