On Thu, Mar 11, 2004 at 10:25:25AM +0100, dr. Imre Bartfai wrote: > Hi, > > I have similar approach but the correction may be different. See: > > The needed correction is: 1/7-1/8 = 0.017857 > > To produce this, see: 1/512+1/64 = 0.017578 which differs only in 4th > decimal. As u have 1 byte only, the 512 factor is meaningless, so > calculate the following expression: > > x >> 3 + x >> 6 > > The error should be less, than 1:448 > > I think this approach even faster. Remember, x >> 6 = x >> 4 >> 2, where > > x >> 4 may be replaced by SWAPF and ANDWF then. Seems interesting. I already saw Wouter's objection to x=7. I decided to test with a random value x=177 177 >> 3 + 177 >> 6 = 22 + 2 = 24 177/7 = 25 So how do you resolve this error. I think the problem is that the 1/512 error actually accumulates. So you reach a point where it does become significant enough to affect the outcome. i.e. 177/512 is enough to cause damage. So some thoughts: 1) You'll need to compute this to 16 significant bits in the intermediate computation. For example 177/64 = 2.76572. You can't truncate the 2.76572 until after you've added it to the sum. 2) You need to account for the x/512 term. So let's take these two into account for 177 -> 10110001 x/8 = 00010110 00100000 x/64 = 00000010 11000100 x/512 = 00000000 01011000 Note you don't have to worry about the upper byte ----------------------------- 00011001 00111100 So as you can see the 177/512 term is required in order to get the x/8+x/64 over the hump from 24 to 25. It must be accounted for. You'll have to left shift to get the lower byte terms for x/8 and x/64 and right shift to get the others. It does work, but no clue as to how much it'll cost. BTW it should satisfy the problem with x=7 too. x/8 = 00000000 11100000 x/64 = 00000000 00011100 x/512 = 00000000 00000011 Note you don't have to worry about the upper byte ----------------------------- 00000000 11111111 Nope. The error still kills you here. BAJ > > Regards, > > Imre > > > On Thu, 11 Mar 2004, Djula Djarmati wrote: > > > >Someone asked me for a fast yet not extremely large code snipped to > > >divide a one-byte value in memory by 7 (on a 14-bit core). I think I > > >have a straight-line (no loop) code that uses 33 instructions (2 less if > > >the source can be destroyed). Looping version would be 12 instructions, > > >but of course somewhat longer execution. Can anyone do it faster, > > >preferrably with fewer instructions? I know a table lookup will be > > >faster, but I think the 256+ size would be classified as 'extremely > > >large'. > > > > The "divide by 8 and fix" method with the remainder. If you don't need > > the remainder then it's 22 instructions (and it's fully tested!). > > > > Enjoy! > > > > Djula > > > > ;DIVIDE ONE BYTE BY 7 > > ;Input dividend: W > > ;Output result: RESULT > > ;Output remainder: REMAIND > > ;Trashes: TEMP > > DivideBy7 movwf TEMP > > andlw 0x07 > > movwf REMAIND > > rrcf TEMP,f > > rrcf TEMP,f > > rrcf TEMP,w > > andlw 0x1f > > movwf RESULT > > addwf REMAIND,w > > movwf TEMP > > > > andlw 0x07 > > movwf REMAIND > > rrcf TEMP,f > > rrcf TEMP,f > > rrcf TEMP,w > > andlw 0x1f > > addwf RESULT,f > > addwf REMAIND,f > > > > movlw -D'7' > > addwf REMAIND,w > > btfss STATUS,C > > return > > movwf REMAIND > > incf RESULT,f > > return > > > > -- > > http://www.piclist.com#nomail Going offline? Don't AutoReply us! > > email listserv@mitvma.mit.edu with SET PICList DIGEST in the body > > > > -- > http://www.piclist.com hint: To leave the PICList > mailto:piclist-unsubscribe-request@mitvma.mit.edu -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu