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,MSGID_SHORT
	autolearn=no autolearn_force=no version=3.4.5-pre1
Date: 25 Feb 93 19:58:29 GMT
From: visicom!rlk@nosc.mil  (Bob Kitzberger)
Subject: Re: Ada Embedded Systems Efficiencies
Message-ID: <295@VisiCom.COM>
List-Id: <comp.lang.ada>

wisniews@saifr00.cfsat.honeywell.com (Joe Wisniewski) writes:

>I am concerned that "good design" macro-efficiencies are going to be "un-done"
>due to perceived net overall gain of over-implementing micro-efficiencies.

Personally, I'd avoid altering the structure of the application in order
to take advantage of small micro-efficiencies.  There are certain
micro-efficiencies that can reduce memory usage, while not altering the
structure of the application at all.  

For example, an understanding of how the compiler lays out memory helps in
identifying and avoiding hot spots, and its surprising how often these
things are ignored, especially by developers new to the world of
embedded systems (no flames intended; this is merely an observation that
memory usage and determinism are rarely as critical in host-based systems
as they are on embedded systems).

For example, if a developer declares a large array of records, they may
not be aware that there may be a lot of 'white space' in their record
layout (inserted by the compiler for efficiency reasons), and a pragma pack
is often in order.  This is a micro-efficiency, but requires no structural
changes to the application.  

Also, a developer may not be aware of the impact of tasks on memory usage.
Specifically, each task usually has some fairly large default stack size.
In order to specify an alternate stack size, the task must be declared
using a task type (since the storage size clause can only be specified
on a task type, not on a task object).  Using the default stack size on
every task can add up quickly.  Again, this is a micro-efficiency, but
it requires no structural changes in order to fix it.  (Add another
thing to the Ada Rules of Thumb: always use task types, even if declaring
a single task of that type).

We are currently undergoing a size reduction effort on a large tightly-
coupled multiprocessor system.  The first step we are taking is to develop
tools to effectively report the actual memory usage of the application.
This includes:

	1. Compiler listings that show CODE, DATA, CONST, BSS usage

	2. Runtime hooks into memory allocation routines to get a handle
           on dynamic memory usage

        3. Task stack usage analysis (allows tuning of stack sizes).

  	4. Reporting of memory usage for each build

Each developer gets the memory usage report, along with a list of deltas
in memory usage from the previous build.  It is felt that individual developers
can effectively take the first pass at reducing memory usage in the areas they
are most familiar with.  A second pass would look at things from a systems
point of view.  

	.Bob.
----------------
Bob Kitzberger          VisiCom Laboratories, Inc.
rlk@visicom.com         10052 Mesa Ridge Court, San Diego CA 92121 USA
                        +1 619 457 2111    FAX +1 619 457 0888