On Wed, 4 Jul 2001, Jeethu Rao wrote:

> 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.

Unfortunately they're quite inadequate.

I usually don't wait on individual bits in the SFR's. Instead I create flags in
the general purpose registers. That way I can do some of the "micro" processing
in an interrupt and save the "macro" processing for the non-interrupt code. Now
imagine that I'm tight on ram and rom:


interrupt:
   if a2d interrupt call read_and_store

  end of interrupt


main:

  use the variable "FLAG" as a loop counter to initialize
  something.


  call read_and_store N times to fill up a sample's array
loop:
  clear FLAG
  enable interrupts

wait_flag:
  if FLAG is clear then goto wait_flag

  disable interrupts

  use the variable "FLAG" as a loop counter again
  do something with A2D data

  goto loop


read_and_store:
  read a2d converter,
  store result in an array
  set FLAG after N samples
  return


Here, the variable called "FLAG" is not only a semaphore, but because of RAM
constraints it doubles as a loop counter. The fact that the routine that sets
the flag is called from an interrupt and from the non-interrupt code clearly
obfuscates FLAG's use as a semaphore.

This is a contrived example that I whipped out. But I'm quite certain that I and
others can contrive many other examples that prohibit a general purpose hex
optimizer from working.

>
> 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.

This is a simple example and as you suggest, following the flow of the code can
determine whether this instruction can be removed. There are other little
snippets that are easily optimized:

   btfsc  some_bit
    goto  L1
   goto   L2
L1
   incf   some_reg
L2

Can be optimized:

   btfss  some_bit
    incf  some_reg

But as Olin noted, removing those two instructions can have a catastrophic
affect on code elsewhere.

Scott

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