Hello John.

> > > ; D<-D+S
> > >         movf    S0,w
> > >         addwf   D0,f
> > Ok.
> >
> > >         movf    S1,w
> > >         btfsc   C
> > >          incfsz S1,w
> > >          addwf  D1,f
> >
> > Stop. For example S1=0xFF , D1=0x00 , Carry=1 . After executing your
> > code result will
> > be equal 0x00 with Carry=0 not =1 .
>
> Let's see....
>
> Instr.  Carry   W       D1  [values given after instruction]
> movf    set     FF      00
> btfsc   set     FF      00
> incfsz  set     00      00
> [skip]  set     00      00
>
> D1 equals zero, as it should, and carry is set, as it should be.  I didn't
> come up with that piece of tricky code, but it really does work!

It's code that really have a bug ! Why ? So you listing above looks
right .
But after next operation addwf D1,F - Carry will set =0 not remain =1 .
It's error sitiuation , because when you will add S2 to D2
you will do it with wrong prev Carry value .

> > It's error . In my code to correct this situation I save previous Carry's in
 S1 .
> >         movfw   S1
> >         skpnc
> >         addlw   1
> >         rlf     S1,F
> >         addwf   D1,F
> >         btfsc   S1,0
> >         setc
> >
> > ... etc
>
> That's seven instructions longer.  What's the payout from the extra
> instructions?

It's wrong magic ;( It's example that explain why code suddenly start
to do strange things in some situation . Payout ? Fully correct code
at any situation for any n-th byte arithmetic (becouse true Carry
adding)

> > >         movf    S2,w
> > >         btfsc   C
> > >          incfsz S2,w
> > >          addwf  D2,w
> > >         rlf     KZ,w    ; KZ == known-zero address
> > >         addwf   S3,w
> > >         addwf   D3,f
> > >
> > > Total of 13 instructions, 13 cycles.  Note that if the destination is not
> > > one of the sources, you should copy the middle bytes from source to
> > > destination and then do the add.

The russian proverb say:
Sometimes the more slow speed you go than greater way you will pass . ;)

WBR Dmitry.