From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!dik
From: dik@mcvax.uucp (Dik T. Winter)
Newsgroups: net.lang.ada
Subject: Problems with memory usage of Ada compilers
Message-ID: <306@zuring.mcvax.UUCP>
Date: Wed, 13-Aug-86 16:12:36 EDT
Article-I.D.: zuring.306
Posted: Wed Aug 13 16:12:36 1986
Date-Received: Thu, 14-Aug-86 05:59:35 EDT
Organization: CWI, Amsterdam
Apparently-To: rnews@mcvax
List-Id: <comp.lang.ada>


We are experiencing problems with (virtual) memory requirements of
the Ada compilers.  We experienced them with both DG/ROLM and
DEC compilers (the last one with the default setting of 5 Mbyte
virtual memory).
The program structure is as follows:
	generic
	    type REAL is digits <>;
	package GENERIC_A is
	    -- a number of specifications
	end GENERIC_A;
	package body GENERIC_A is
	    -- the bodies of the routines from the specification
	    -- all indicated by body stubs.
	end GENERIC_A;
	-- followed by the subunits required.
A second source file contains the two lines:
	with GENERIC_A;
	package A_FLOAT is new GENERIC_A(FLOAT);

I admit the size of the subunits is a bit long, but: the first
file will not compile due to an internal STORAGE_ERROR on both
compilers.  It compiles if we split it in a number of source
files (i.e. the compiler is not releasing unused memory, or
not all unused memory).  But even if the generic templates
compile, the instantiation will not compile!  (Although it will
compile with the DEC compiler with more than 6 Mbyte virtual
memory.)

When we change the generic package to non-generic it compiles
and works.

Now we are faced with the following problem: software maintenance
dictates that we use a generic version and use standard instantiations
for all floating point types provided by the machines where it will
run.  But the compiler dictates that we use non-generic versions.
Another reason to use the non-generic version is that the (20 or so)
routines depend heavily on branches on the attribute REAL'DIGITS.
In a non-generic version this is static, while in a generic version
it is non-static making elimination of dead branches more difficult.

You might argue that we should split the package in a number of packages,
but this won't help as there are a lot of dependencies amongst the
routines involved.  As these dependencies are of no interest for the
user (and in fact might change in the future) the routines then have
to make local instantiations of generic packages (or routines); which
will not help a lot, and is impossible if the references are mutually
recursive (i.e. if routine A calls B while B calls A, now there is no
way to split the package).

Another reason to use the non-generic version, is that it might
simplify selective loading (i.e. if package A contains body stubs
for routines B and C, and the user uses B only, not C, the actual
code image should contain B only, not C).  I know that selective
loading is not done with the DG/ROLM system, but the process is in
fact quite simple.  (I know of an ALGOL68 compiler that also defined
precompilation in terms of packages and body stubs, that did
selective loading at no cost, not compile-time, not link-time and
not run-time, so it can be done.)  Also there is no real reason why it
should be more difficult with generics.  But the problems indicate
that the compilers generate code on an instantiation for the
generic template and all its subunits in one binary load module.
This zVis at least an fact with the DG/ROLM compiler.

So, what is the future of generics?  I await your comments on this.
-- 
dik t. winter, cwi, amsterdam, nederland
UUCP: {seismo,decvax,philabs,okstate,garfield}!mcvax!dik
  or: dik@mcvax.uucp
ARPA: dik%mcvax.uucp@seismo.css.gov