Techniques for reducing code size?

[Martin]

I already know some techniques for writing small footprint software,
but now I need to really squeeze the software I'm writing into a small
space (embedded software).

Is there a good web page that discsuesses techniques for this?
A good book?

/Martin

 

[Dan Pop]

I already know some techniques for writing small footprint software,
but now I need to really squeeze the software I'm writing into a small
space (embedded software).

1. If your compiler has the option to optimise for size (instead of
speed), use it.

2. If #1 hasn't solved your problem, recode in assembly as much as
necessary.

The C language doesn't address the issue of code size, so the only things
you can do at the C source code level are:

o Reduce the amount of data allocated by the program. Reuse your data
as much as possible.

o Prefer simple algorithms to more complex ones. The most efficient
algorithms tend to be (much) more complex than some of the less
efficient ones or to use more data. Compare Eratosthenes' sieve with
a purely computational method of generating prime numbers.

If you have constraints of both space and speed, you may be forced to
resort to assembly.

Dan

 

[Thomas Matthews]

I already know some techniques for writing small footprint software,
but now I need to really squeeze the software I'm writing into a small
space (embedded software).

Is there a good web page that discsuesses techniques for this?
A good book?

/Martin

Have you tried optimizing the design?
Have you tried removing requirements?

Since this is an embedded system, have you tried searching

When I optimize for space, I perform the following
steps, not necessarily in the order listed:

1. Remove or inline simple functions.
A simple function is a function that has code that
is smaller or equal to the calling overhead.
Inlining is to either convert the function to a
macro or just cut and paste wherever it is used.

2. Remove all instances of division and modulo.
Replace with shifts, adds, subtracts and masking.
My experience is that many of the math libraries
are huge and that most division on an embedded
system can be replaced by another process or
eliminated entirely.

3. Replace many "if" statements with boolean arithmetic.
Because the C language provides short-circuiting with
the logical boolean operators, these can be used
like "if" statements without having the second
expression evaluated:
unsigned char result;
result = /* evaluation of condition 1 */
result = result && /* eval. of condition 2 */

In the above line, condition 2 will only be evaluated
if the result is nonzero (i.e. true).

4. If it doesn't change, make it const.
Some embedded systems may have more read-only memory
than read/write memory. Some compilers may allow
constants to be relocated outside of the executable
code.

5. Simplify algebraic expressions.
If some statements evaluate an algebraic expression,
see if the algebraic expression can be simplified
before it is implemented. Same holds true for boolean
algebraic expressions.

6. Factor out duplication.
If the duplication is more than the overhead of a
function call then factor out the duplication into
a new function.

7. Remove deadwood.

8. Apply platform specific code crunching.
Replace functions with assembly language functions,
if and only if they can be coded more efficiently
than the compiler's version. Take advantage of
specialized processor instructions.

For more suggestions, try posting to
--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book