Searching \ for '[PIC]: Challenge 18F indirect addressing' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=18F
Search entire site for: 'Challenge 18F indirect addressing'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Challenge 18F indirect addressing'
2002\09\12@014743 by Scott Dattalo

face
flavicon
face
The 18f452 has some really tricky ways to implement indirect addressing.

#define  MAX_LEN 256

unsigned char arr[MAX_LEN];
unsigned int  sum;

void array_sum(unsigned char len)
{
 unsigned char i;

  sum = 0;
  for(i=0; i<len; i++)
    sum += arr[i];

}

This can obviously be implemented in less than 12 instructions. How about
9?


Scott

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


2002\09\12@235642 by Scott Dattalo

face
flavicon
face
On Wed, 11 Sep 2002, Scott Dattalo wrote:

> The 18f452 has some really tricky ways to implement indirect addressing.
>
> #define  MAX_LEN 256
>
> unsigned char arr[MAX_LEN];
> unsigned int  sum;
>
> void array_sum(unsigned char len)
> {
>   unsigned char i;
>
>    sum = 0;
>    for(i=0; i<len; i++)
>      sum += arr[i];
>
> }
>
> This can obviously be implemented in less than 12 instructions. How about
> 9?

~24Hrs and no takers. Hmm.


If len can be destroyed:

   clrf   sum_lo
   clrf   sum_hi
   lfsr   0,arr
loop:
   decf   len,w
   movf   plusw0,w
   addwf  sum_lo,f
   movlw  0
   addwfc sum_hi,f
   decfsz len,f
    bra   loop



How about this one:

   arr[i] = x;

?

Scott

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


2002\09\13@050924 by Tony K|bek

flavicon
face
Hi,
Scott Dattalo wrote:
<snip>
>~24Hrs and no takers. Hmm.

been busy, haven't read the list in a week or so, sorry :)

<snip>
>How about this one:
>
>    arr[i] = x;
>

I assume 'i' is variable else it would be no fun,
then:

       lfsr    0,arr
       movf    i,w
       movff   x,plusw0

might work



###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft
Exchange.
For more information, connect to http://www.F-Secure.com/

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu


2002\09\13@074914 by Scott Dattalo

face
flavicon
face
On Fri, 13 Sep 2002, Tony K|bek wrote:

> Hi,
> Scott Dattalo wrote:
> <snip>
> >~24Hrs and no takers. Hmm.
>
> been busy, haven't read the list in a week or so, sorry :)
>
> <snip>
> >How about this one:
> >
> >    arr[i] = x;
> >
>
> I assume 'i' is variable else it would be no fun,
> then:
>
>         lfsr    0,arr
>         movf    i,w
>         movff   x,plusw0

Exactly! In fact, this is the only "legitimate" use I've found for the
"movff" instruction. I suppose you can argue that "movff" doesn't affect
WREG... But it still takes two cycles (and two program memory words) just
like a 16x style move would.  However in the above snippet, if you didn't
have the movff instruction you'd be stuck with:

     lfsr   0,arr
     movf   i,w
     addwf  FSR0L,f
     skpnc
      incf  FSR0H,f
     movf   x,w
     movwf  INDF0

The movff saves 3 program memory words in this case!

Scott

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


2002\09\13@090124 by Jason Harper

picon face
Scott wrote:
> >         lfsr    0,arr
> >         movf    i,w
> >         movff   x,plusw0
>
> Exactly! In fact, this is the only "legitimate" use I've found for the
> "movff" instruction. I suppose you can argue that "movff" doesn't affect
> WREG... But it still takes two cycles (and two program memory words) just
> like a 16x style move would.

Another advantage of MOVFF is that it can directly access the entire 4K
memory space without concern for banking.  This could be a significant code
savings in a program that uses more RAM than can be directly accessed (384
bytes, I think).
       Jason Harper

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspam_OUTspamTakeThisOuTmitvma.mit.edu


2002\09\13@090821 by Scott Dattalo

face
flavicon
face
On Fri, 13 Sep 2002, Jason Harper wrote:

> Scott wrote:
> > >         lfsr    0,arr
> > >         movf    i,w
> > >         movff   x,plusw0
> >
> > Exactly! In fact, this is the only "legitimate" use I've found for the
> > "movff" instruction. I suppose you can argue that "movff" doesn't affect
> > WREG... But it still takes two cycles (and two program memory words) just
> > like a 16x style move would.
>
> Another advantage of MOVFF is that it can directly access the entire 4K
> memory space without concern for banking.  This could be a significant code
> savings in a program that uses more RAM than can be directly accessed (384
> bytes, I think).

Two good reasons! I hadn't thought of that one either. (hmm, C-compiler
wheels starting to churn...).

BTW, on the early 18Cxxx parts there was an errata with respect to MOVFF
and interrupts. I didn't see this in the latest 18F452 errata. Has this
problem been completely fixed?

Scott

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamspam_OUTmitvma.mit.edu


2002\09\13@103919 by Jason Harper

picon face
Scott wrote:
> BTW, on the early 18Cxxx parts there was an errata with respect to MOVFF
> and interrupts. I didn't see this in the latest 18F452 errata. Has this
> problem been completely fixed?

Are you sure you aren't thinking of LFSR?  That didn't quite work right on
the 18C's (along with an amazing collection of other subtle bugs).

If MOVFF worked exactly as documented in the datasheet, it would be
completely unreliable in the presence of interrupts, as would all the other
2-word instructions.  There would surely be lots of complaints if that was
actually the case, so I assume the datasheet is wrong (and I don't have any
18F's to actually test this).  If MOVFF works the way I think it does, the
operation is entirely completed in a single instruction time, so there
would be no concern with interrupts in the middle.  The second word is just
a NOP, containing 12 bits of additional operand data that is peeked from
the instruction prefetch buffer during the execution of the MOVFF itself.
       Jason Harper

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2002\09\16@045845 by Tony K|bek

flavicon
face
Hi,

Jason Harper wrote:

>> Another advantage of MOVFF is that it can directly access the entire
4K
>> memory space without concern for banking.  This could be a
significant code
>> savings in a program that uses more RAM than can be directly accessed
(384
>> bytes, I think).

Scott Dattalo replied:

>Two good reasons! I hadn't thought of that one either. (hmm, C-compiler
>wheels starting to churn...).
>
>BTW, on the early 18Cxxx parts there was an errata with respect to
MOVFF
>and interrupts. I didn't see this in the latest 18F452 errata. Has this
>problem been completely fixed?

Well the movff is a quite handy instruction actually, as mentioned it
handles the 4 k memory range which in itself is really good and also
,as you conlcuded, is does not use the wreg or affects the status reg.

Regarding possible bug, I belive it actually was an bug in the processor
module
PCM18XA0 ( and B0 ? ) it was discovered it had some timing issues,
manifisted itself
as trashing wreg when an isr fired in the middle of an two cycle
instruction.
For example tablrd, movff etc. But as far as I can recall these issues
were
not related to actual silicon. There probably was an reason for the max
25MHz spec
for the module :).
Actual silicon has(had?) other issues instead (bsr, lfsr, etc etc ).





###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft
Exchange.
For more information, connect to http://www.F-Secure.com/

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



'[PIC]: Challenge 18F indirect addressing'
2002\10\13@174922 by Eric Smith
flavicon
face
Jason Harper <KILLspamJasonRandHarperKILLspamspamCOMPUSERVE.COM> writes:
> If MOVFF worked exactly as documented in the datasheet, it would be
> completely unreliable in the presence of interrupts, as would all the other
> 2-word instructions.  There would surely be lots of complaints if that was
> actually the case, so I assume the datasheet is wrong (and I don't have any
> 18F's to actually test this).  If MOVFF works the way I think it does, the
> operation is entirely completed in a single instruction time, so there
> would be no concern with interrupts in the middle.

I doubt that *very* much.  They can't read both words of the instruction
in a single cycle; the program memory cycle time is about 3/4 of the
instruction cycle time.

More likely, they just disable interrupts for the second cycle.

>  The second word is just
> a NOP, containing 12 bits of additional operand data that is peeked from
> the instruction prefetch buffer during the execution of the MOVFF itself.

There *isn't* an instruction prefetch buffer.  They fetch each word as
they're executing the previous one.  The PIC isn't fully pipelined like
a RISC processor.  When they start executing the first word of a 2-word
instruction, they're still fetching the second word, and it isn't
availiable until the first instruction cycle is completed.

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...