Scott,

As you had suggested earlier, you can always use the
"-im_a_dimitry_dont_waste_time_optimizing" command line option if
you write real tight and terse code.

But, the prime targets for optimizations are the code generated
by compilers (JAL code can be quite heavily optimized).
Many JAL coders are new to PICs have little or no experience in
assembly coding and optimizations. If something could optimize
compiler generated code for them, it would be a great boon to them.
Why JAL, I think even commercial C compiler generated code might be
optimized.

And, I've actually worked out an algorithm to compensate addition/removal
of code. Even the most rudimentary optimizers must be able to compensate
for Addition/Removal of code. The key to this is Addition/Removal of code
one word at a time and then running an analysis pass on the whole code to
fix
the errors caused by Addition/Removal of the word. It will be a bit slow,
But it
certainly is possible.

Jeethu Rao

> -----Original Message-----
> From: pic microcontroller discussion list
> [mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of Scott Dattalo
> Sent: Wednesday, July 04, 2001 9:09 PM
> To: PICLIST@MITVMA.MIT.EDU
> Subject: Re: [PIC]: Compiler
>
>
> 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
>
>

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu