comp.lang.ada
 help / color / mirror / Atom feed
From: berman@umbc.edu (Mike Berman)
Subject: Re: Ada Embedded Systems Efficiencies
Date: 3 Mar 1993 18:24:33 -0500
Date: 1993-03-03T18:24:33-05:00	[thread overview]
Message-ID: <1n3enhINNsec@umbc4.umbc.edu> (raw)
In-Reply-To: 1993Mar3.143900.10592@saifr00.cfsat.honeywell.com

In article <1993Mar3.143900.10592@saifr00.cfsat.honeywell.com> walls@saifr00.cfsat.honeywell.com (Gerald Walls) writes:

>The problem here is not speed efficiency where you can selectively
>optimize.  The problem is size optimization where it has to be
>done everywhere.  We don't have the luxury of buying more memory
>but instead must make the code fit.

There aren't a whole lot of ways of controlling space optimizations via
"micro-efficiencies". In this arena, compilers can do amazing things
that most of us mere mortals could ever accomplish by hand. If you start
hitting brick walls, bring in your compiler vendor.

Some things you can do within he language:

	- Avoid using tasking. The overhead can be large, since the run
time support libraries get linked in no matter how much or how little
tasking your application actually does. Use implementation-provided
methods for interrupt handling.
	As an alternative, many implementations provide small run time
environments if you use a self-enforced subset of tasking capabilities.

	- Learn to love your linker toolset. You will probably have to
play with how your linker allocates code and data. Most of the real time
compiler vendors provide decent tools for doing this.

	- Keep things off of the heap and in registers, whenever
possible. Likewise with the program stack.

	- Know how your compiler allocates storage. All of the major
vendors that I am aware of provide all of the gory details about how
each possible data object is actually stored. They are generally godd
about documenting known inefficiencies in their release notes.

	- pragma Optimize specifies two kinds of optimization sets: time
and space. Obviously, there are tradeoffs (larger, faster code vs.
smaller, slower code). Most vendors go at least one step further, adding
controls over many of the individual optimizations or groups of
optimizations that are performed.

In short, you have to know a lot about how your compilation system does
what it does. Again, a lot of analysis is needed at all stages of
development. Expect that some compromises will be necessary, but
certainly approach the design from the outset using all the good
programming and design practices that you would normally use.

BTW, these problems are by no means unique to Ada
development projects.

>gerald walls (walls@saifr00.cfsat.honeywell.com) or
>             (int_walls@am.eccx.umc@esu36.cfsat.honeywell.com)

-- 
Mike Berman
University of Maryland, Baltimore County	Fastrak Training, Inc.
berman@umbc.edu					(301)924-0050



  reply	other threads:[~1993-03-03 23:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1993Feb24.212146.13157@saifr00.cfsat.honeywell.com>
1993-02-26 15:10 ` Ada Embedded Systems Efficiencies MILLS,JOHN M.
1993-03-02 20:10   ` Greg Franks
1993-03-02 22:36 ` Tom Wicklund
1993-03-03 14:39   ` Gerald Walls
1993-03-03 23:24     ` Mike Berman [this message]
1993-03-04  1:50       ` Dave Bashford
1993-03-05 21:21 agate!howland.reston.ans.net!zaphod.mps.ohio-state.edu!saimiri.primate.wi
  -- strict thread matches above, loose matches on Subject: below --
1993-02-26  5:59 Alex Blakemore
1993-02-25 20:36 enterpoop.mit.edu!spool.mu.edu!howland.reston.ans.net!paladin.american.ed
1993-02-25 19:58 Bob Kitzberger
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox