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

I guess I'm really having a problem being clear today.  The four MOVLW lines
above are *INDIVIDUAL* examples of a source line that could have produced
the *SINGLE* MOVLW instruction I was using as an example.  Of course the
same reasoning applies to ADDLW, IORLW, etc, etc, etc.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olin@embedinc.com, http://www.embedinc.com

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