On Tue, 3 Jul 2001, Olin Lathrop wrote:

> > >    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.
> >
> > Olin's example above is not really clear, so let me elaborate slightly.
>
> Sorry, I'll explain why this is a show-stopping gotcha.  A HEX file contains
> raw instructions after address symbols have been resolved and linked.  To do
> any meaningful optimizing, you will have to move instructions around.  Since
> some instructions will now be at different addresses, you have to adjust the
> references to those addresses.  That can be done with GOTO and CALL
> instructions, but what about the example above?  Here are a few examples of
> the code that could have produced that MOVLW instruction:
>
>    MOVLW   h'3A'     ;get the official number of glorks per snorp
>    MOVLW   low table ;get low byte of table start address
>    MOVLW   high table ;get high byte of table start address
>    MOVLW   low blog+3 ;get address of the count field in the BLOG structure
>
> You're screwed because there is no way to distinguish these cases, so you
> have no idea how, if at all, to adjust the 3Ah value.

Actually, Olin, I think you mean ADDLW, IORLW or XORLW instead of MOVLW.
Consecutive RETLW's make sense for tables. It makes no sense to have two MOVLW's
in a row unless there is a jump that some how chooses which is executed:

    skpc
     movlw   42
    movlw    69

Scott

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