Vladimir M. Klochko wrote:

>  >>   n/3 ~ (n+1)*85/256
>     . . . . .
>  >> In fact, the approximation is exact for all values of n between
>  >> -512 and 1023
>
>     Sorry... :(
>     Let us check.
>     258=86*3
>     ((258+1)*85)/256=85.996. And truncation gives 85. :(

Yeah, I caught that later on too... Fortunately, it's valid
for the 8-bit arithmetic. There's also another error in the
general formula that I posted last week:

a // b = ((a+1) * (N//b)) // N

(where // is a shortcut symbol for intger division). This
formula fails if  b mod N == 0, i.e. if N is evenly divisible
by b. In this case though, division is trivial.

>
> ;   Divide by 10
 <snip>
> ;;      23 words and 1 byte


Here's an 18 cycle Divide by 5:
        ADDLW   1
        SKPNC
         RETLW  0x33

        MOVWF   ql
        CLRF    qh
        RLF     ql,W
        RLF     qh,F

        ADDWF   ql,F
        SKPNC
         INCF   qh,F

        SWAPF   qh,W
        ADDWF   qh,F

        SWAPF   ql,W
        ANDLW   0xF
        ADDWF   ql,F
        SKPNDC
         INCF   qh,F

        ADDWF   qh,W

This can be turned into a Divide by 10 by deleting the last
instruction and adding:

        ADDWF   qh,F
        RRF     qh,W

However a dedicated divide by 10 routine can be made shorter.
One interesting, but otherwise totally useless approximation for
divide by 10 is:

        ADDLW   1
        MOVWF   q
        SWAPF   q,W
        ANDLW   0xf
        SKPNC
         ADDLW  1
        MOVWF   q
        RRF     q,F
        ADDWF   q,W

The result is either exact or 1 or 2 counts low. I only post this
because I know Ray has a lot of time to waste to figure out how this
can be squeezed down to 6 cycles :). (BTW, there is a simple change
that can reduce this to 6 cycles, but it is sometimes 3 counts low...)


Scott