I got it Scott.

But I'll have to generate a call tree for any serious optimization.

As for the Semaphores, they can be detected by a simple algorithm.

The optimizer won't try to optimize a piece of code waiting for a semaphore
if:

a) If the semaphore you are waiting for is in PIR1 or PIR2 or ADCON0 or
TXSTA etc,


b) If the bit or byte you are waiting for is being written by the ISR
section of the
   code.

I guess these two tests would be quite adequate.

Another culprit is movf x,f .
this instruction may seem unnecessary.
But what if its done to test the Z bit ?

Simple. this can be solved by checking for any
instruction which can modify status register (addlw,andlw,xorlw etc)
before any code which reads status reg.

if status is modified, the movf x,f can be safely removed.

I don't want to complicate the matters for Coders.
Hardcore coders may not need an Optimizer. But I believe
there are a lot of novices and people who use HLLs.
For instance, JAL generates a lot of dead code like
twin gotos,redundant page selection etc.

So, the optimizer won't be needed by everyone.
but anyone who needs it, can use it.

There should also be GUI interface front end programs for
X-windows and Win32.That'll take make it easy for novices.

I'll start a new thread on Assembly Optimization.

Jeethu Rao


-----Original Message-----
From: pic microcontroller discussion list
[mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of Scott Dattalo
Sent: Tuesday, July 03, 2001 8:28 PM
To: PICLIST@MITVMA.MIT.EDU
Subject: Re: [PIC]: Compiler


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.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body