Martin, Yes, the code always uses the same # of cycles. I realize that the goto $+2 in this situation is confusing and no good programming practice. The following piece of coding is clean and easy to understand. The counter can be extended by just adding another 'INCF and SKPNZ' sequence. The advantage is that the Z flag actually reflects the contents of the whole n-byte counter. incf Low,f skpnz incf Medium,f skpnz incf High,f OTOH (On the other hand) If you use the Interrupt Service Routine only for incrementing a counter, then the following coding can be of interest because it does NOT alter W nor the Status register! So there is no need to preserve them. ; ; Count events without altering W and STATUS ; ISR incfsz Events+0,f goto ISR_end ; or goto $+2 if you want isosynchonous execution incfsz Events+1,f goto ISR_end incfsz Events+2,f goto ISR_end ; or nop ISR_end ... retfie Or if you want to do something special when the counter overflows: ISR incfsz Events+0,f goto ISR_end incfsz Events+1,f goto ISR_end incfsnz Events+2,f goto Overflow ; Do overflow processing ISR_end ... retfie (isosynchonous = always the same number of instruction cycles) Any comments and suggestions are appreciated. Mark Langezaal >From: Martin R. Green >Sent: Monday, September 22, 1997 18:36 PM >To: PICLIST@MITVMA.MIT.EDU >Subject: Re: Multi-byte counter trick > >You are, of course, correct, but I have a question. Does your code always >use the same # of cycles, I am confused about how the PIC handles a long >sequence of 2 byte instructions like this. If it is, is this why you chose >goto $+2 for the first goto instead of goto $+4?. > >CIAO - Martin R. Green >elimar@bigfoot.com > > incfsz low,f > goto $+2 > incfsz medium,f > goto $+2 > incf high,f > >then it will work. > >Mark Langezaal