On Tue, 3 Jul 2001, Olin Lathrop wrote:

> > I'm thinking of writing an Optimizer for PIC Hex Files.
> > It would take in a hex file, Disassemble it, and then
> > try various optimizations.
>
> This is impossible in the general sense.  For example, suppose you
> encountered
>
>    MOVLW h'3A'
>
> That could be the low or high byte of an address, or just an arbitrary
> constant.  There are lots of other gotchas too.  You need to know the
> original intent of the code to do any meaningful optimizations.

What's good about hex files is that the comments in them exactly describe what's
going on!

IMO, writing an optimizer beginning with the .hex is not the best way to start.
Olin's example above is not really clear, so let me elaborate slightly.
Optimization can't occur on single instructions. Instead it has to occur on a
block of instructions. In other words, the flow of the program must also be
analyzed. This involves disecting the code, creating call trees, etc. But there
are always cases for which a detail analysis is simply insufficient (without
knowledge of the programmer's original intent).

Here are a couple of examples:

1) Isochronous flow.
I write quite a bit of isochronous code. Often times to balance the flow you
have to stick in a few nops or goto $+1's. If you're optimizing for execution
efficiency, then these will be removed.

2) I/O bit toggling.

  bsf   ioport,iobit  ; actually, don't do this
  bcf   ioport,iobit  ; because of the rmw bug
  bsf   ioport,iobit

If you toggle an I/O pin, then it's state at the beginning of the snippet is the
same at the end. From an optimizer's point of view nothing has changed.

3) Interrupt thread processing.
Sometimes I create flags (semaphores) that are changed in an interrupt routine
and polled by non-interrupt code. I don't do this exactly:

    bcf    wait_for_some_interrupt_processing,0

    do stuff that turns on the interrupt and waits for it to trigger

    btfss  wait_for_some_interrupt_processing,0
     goto  $-1

But if the optimizer saw this it'd likely freak.

4) Lookup tables
There are just too many case to enumerate here.

I could go on and on...

Now, I don't think an assembler optimizer is a hopeless case. Certainly a
c-compiler is at liberty to optimize it's generated assembly code because it
knows the context in which the code is generated. If you wanted the optimizer to
work for hand written assembly, then to be robust a set of special optimization
directives would be needed. For example, there may be a `volatile' modifier for
volatile variables like semaphores and mutexes. Or there may be 'table
begin/end' modifiers. An 'isochronous' modifier might be useful. And finally the
'I_am_dmitry_so_do_not_waste_time_optimizing' modifier would be absolutely
necessary!

Scott

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.