On Fri, 16 Jan 1998 19:37:44 -0500, you wrote:

>How about hiring an "optimizing programmer". Better algorythms always beat
>optimizing compilers/assemblers.
>
>Bill :-)
I thought about  writing a relatively simple utility to automatically
analyze code to find candidates for 'obvious' optimisation, which
didn't need much analysis of code structure. 
It would just point out possible optimisations, leaving it up to the
programmer to decide if they will cause any problems (stack depth,
timing etc.), or save enough to justify reduced code readability etc.

A few eamples of some 'obvious' optimisations :
call followed by movlw, where the movlw can be omitted by retlw'ing
the appropriate value.

Shared subroutine exit code, which can be reduced by one subroutine
ending in a goto (end of other routine)
 
Sections of repeated code which could be put in subroutines. Even a
2-instruction sequence, if used 3 or more times, can usefully be put
in a subroutine to save space. The utility would calculate the the
tradeoff between number of repeats versus code fragment length to see
if any saving is possible, and then list  all repeats in order of
bytes saved.

multiple skip/goto combinations which could be re-arranged 

Subroutines only called once, which could be changed to in-line.
Unused  (un-callable) subroutines/code fragments left-over from debug
code/earlier versions etc.

The first two aren't too hard to do manually, unless you have a lot of
macros. The third would be the most useful, as you could get exact
quantative figures for savings - you tend not to consider moving very
short sequences to subroutines.

     ____                                                           ____
   _/ L_/  Mike Harrison / White Wing Logic / wwl@netcomuk.co.uk  _/ L_/
 _/ W_/  Hardware & Software design / PCB Design / Consultancy  _/ W_/
/_W_/  Industrial / Computer Peripherals / Hazardous Area      /_W_/