Re: Ada Embedded Systems Efficiencies

[agate!howland.reston.ans.net!zaphod.mps.ohio-state.edu!saimiri.primate.wi]

Some of my favorite ways to reduce ROM size in an embedded application
without hacking up your code, in order of estimated savings. (If your
problem is RAM, it's a different list.)

* Code shared generics
  Some compilers can generate shared code for generic instantiations.
  If you have many generic instantiations, this can be a big win. Some
  compilers can even do this without sacrificing execution speed.

* Enumeration image tables
  Have your compiler/linker throw these away. You probably are not
  using 'Image or 'Value anyway, and why should you pay a code penalty
  for using nice, long, readable  names instead of A1, A2, etc.

* Unused subprogram elimination
  Most modern Ada compilers support the elimination of unreferenced
  subprograms at link time. (Since some compilers also generate
  "hidden" support routines for complex data type comparison and
  assignment, if you have many structures but don't use all the
  operations, you can save a lot.)

  Almost all compilers do unreachable code elimination (but if your
  application is what I think it is, there will be no dead code.)

* Elaboration of constants & variables
  How does your compiler initialize complex constants and variables?
  If the values are known at compile time, can it just lay the data
  out directly in ROM? Or does it generate code to copy the value
  (either element by element or a block copy) thus wasting both ROM
  and RAM (for constants). If your constants are not static, can you
  tweak them so they are?  [Actually, for something initialized with
  (others => value), a block fill can save ROM at the expense of RAM.]

* Exception tables
  If you're not using them (and your compiler is generating them) have
  the linker toss 'em.

* pragma INLINE
  Yes, pragma INLINE can often reduce size as well as time.  If you
  have many small "get/put" routines to private types/objects, the
  inlined code can be smaller than the procedure call overhead. (If
  the code after pragma INLINE is not identical to direct access, it's
  time to have a *serious* talk with your compiler vendor.) For example,
  on one current program, compiling w/o inline actually *increased*
  the code size by 5%.

  Of course, to do this profitably, you must evaluate the size/speed
  effect of every inline.

* Code generation
  Most of the compilers I've worked with tend to optimize for speed
  instead of space. For example, the architecture may provide a "bit
  field extract" instruction but it may be faster to do the
  shifting and masking manually. For speed you'd prefer the latter,
  but it'll cost in space. (I chose this example 'cause a lot of
  embedded systems do a lot of bit-diddling.) Another obvious example
  is loop unrolling.

  You may have to convince your compiler vendor to allow selective
  control over what optimizations are performed if there is a
  size/speed tradeoff.

You're gonna have to get used to pouring over the assembly listings
for your compiler.  Just like with the government, there may be lots
of waste, fraud, and abuse but until you examine everything carefully,
it may be hard to pick out.