Re: The cost of is separate

Re: The cost of is separate

[Mike Ryer]

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

Re: The cost of is separate

[Kent Mitchell]

Mike Ryer (ryer@inmet.camb.inmet.com) wrote:
<< lots of valid stuff deleted>>
: I believe that all current Ada compilers go all the way through code generati
on
: at compilation time.

This is mostly true.  However, the Rational Environment compiler decouples 
semantic analysis from code generation.  This allows for full code 
optomization even in the case of separates.

<<more valid stuff deleted>>

: 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).

I tend to agree with this but I always feall that there is a fine line here
between a Ada unit that runs on for 10 pages and the use of separates.  In
general size "rules" should be size "guidelines" and we should not let
people get too religious about this.

Kent Mitchell
Rational        "my views are my own

Re: The cost of is separate

[Ron Sercely]

Just another view.....

REALLY large packages might also run into compiler limits that subunits would
avoid.  

Also, if you are in a developement (as opposed to maintenance) environment,
and are running high level of optimizations on huge package bodies,
recompilation times might kill you, were subunits would work wonderfully!
(Isn't this why subunits are in the standard?)

Tucker is certainly correct that _some_ optimizations are more difficult to
make when using subunits.

To summarize:

I have always used sub-units during development, then folded the code back
in shortly before production release.

Ron Sercely