Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!brl-tgr!tgr!RCONN@SIMTEL20.ARPA
From: RCONN@SIMTEL20.ARPA (Rick Conn)
Newsgroups: net.micro
Subject: Re: Address space \"convenience\"
Message-ID: <8989@brl-tgr.ARPA>
Date: Wed, 6-Mar-85 11:08:53 EST
Article-I.D.: brl-tgr.8989
Posted: Wed Mar  6 11:08:53 1985
Date-Received: Sat, 9-Mar-85 19:55:22 EST
Sender: news@brl-tgr.ARPA
Lines: 27

You bring up lots of good points.  I've been becoming greatly involved
with Ada, and, with the current state of the Ada compilers, I've gotten
into a mode of not considering code efficiency and considering more the
readability, modularity, maintainability, etc of the code and the application
of object-oriented programming design methodology.  However, if you turn
around and look at the size of the object code, on the Data General MV10000,
for example, I commonly see 150K+ and 300K+ executable images
being generated from my little 200 or 1000 line programs.  DEC Ada has
been quite a different story, with 15K EXE files poppng up from
similar code (altho I suspect something large is coming in at execution
since I commonly see 10K+ page faults during a run).  I haven't studied
the question in enough detail to give more than this cursory exam, and I
suspect that as the Ada compiler technology matures, we will find more
efficient code generation.  It will be very interesting to see what the
ALSYS 8086 and 68000 efforts generate.  It will also be interesting to
see what happens when compilers load only those parts of a package that
they need rather than the whole package; right now, it looks like the DG
loads all of TEXT_IO, and this has got to be a lot of code.

Anyway, we will see with time.  Ada is targeted to embedded
applications and processors, and my current idea of such a processor is
NOT a VAX 11/780 with 2G bytes of disk.  Ada is such
a neat language when you don't look at the code sizes that I hope this
problem can be overcome.

	Rick
-------