----- Original Message ----- From: Daniel Serpell To: Sent: Thursday, June 26, 2003 8:27 PM Subject: Re: [PIC]: 8-byte vertical adder? > On Thu, Jun 26, 2003 at 07:17:36PM +0100, Sergio Masci wrote: > > From: Daniel Serpell > > Unfortunatly I don't have time to go working through your code right now (which > > is why I wrote the alogrithm in C in the first place). Perhaps you can show us > > the corrected version? > > Well, I tought that finding it could be fun, don't be so serious... No, not seriuos. Look BIG smiley :-) :-) :-) > The problem is the state of the carry flag before each rrl accl,F > The cbits fragment don't always clear carry at end, so en explicit > inst. to clear carry have to be added before each rrl accl,F . As there > are seven, it's seven extra instructions. I tried searching a cbits > equivalent that didn't set's carry flag, but didn't succed. > > > Why do you not want to use a lookup table? This would speed things up. I will > > certainly be having a closer look at what Scott has produced when I get a few > > minutes. > > Because a lookup table takes an extra 256 bytes of program memory, and > in the 14bit PIC's don't have much program memory to spare. But if > you have, you can do: > > cbits MACRO data > movlw HIGH(lookup_table) > movwf PCLATH > movf data,W > movwf PCL > ENDM > > "lookup_table" should be aligned to a 256 byte boundary, again to avoid > 16bit arithmetic. The code is 7cicles each "cbits" macro instead of > 12 cicles in my last example, so the total is 81 cycles. That's 47 > cycles less than the other example, and 256+81=337 words of program > memory. your 7 cycles do not include the CALL instruction Also you can cut the table down by 128 instructions if you post process the bottom bit (push it into carry leaving top bit as 0 and cope with it latter), or you can cut down the table to 16 bytes and place it in the data eeprom if you look at 4 bits at a time. actually with the 128 element table solution you could collect all the discarded bit 0's and add them at the end e.g. braodly speaking bcf STATUC,C rrf data1 rlf capture do stuff bcf STATUC,C rrf data2 rlf capture do stuff ... do stuff bcf STATUC,C rrf data8 rlf capture movf capture,w addwf result btfsc STATUS,C incf result+1 A lot of the above code could no doubt be moved to the table lookup function since you would need to use a CALL anyway (for the corresponding RETLW) In any case I thought you would be using direct code space lookup (as Scott suggested) since you originally mentioned the 18 series as your big moma :-) :-) :-) > > Daniel. > > PS: I reply to this type of questions because I think it's fun to play > with little algorithms, but don't always have the time to write full > explanations... I agree, sometimes looking at one of these brain teasers is a great distraction and sometimes the temptation to reply (even when I should be doing something else, like right now) is just to great. Regards Sergio Masci -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads