Post by thread:32 bit add/sub

Hi there, I am trying to implement 32 bit addition and subtraction routines but I have some problems with the carry management. Before reinventing the wheel I have done a search (on the piclist archive, on the Mchip AppNotes and on some Web sites) just to see if there is something ready made. I have found nothing appropriate: just some 16 bit routines (I know is out there but I can't find it. The Web is really frustrating!). Ok. I will take a 16 bit add routine and I will extend it to 32 bit. I found a Microchip AppNote (the AN617: Fixed Point Routines) that has, among others, an "expandable" 16 bit add. Here it is: ADD MOVF AARGB1,W ADDWF BARGB1 MOVF AARGB0,W BTFSC _C INCFSZ AARGB0,W ADDWF BARGB0 And this is the text following the routine: The four instructions after the initial add/subtract, can be easily concatenated for operations involving more than two bytes. Because addition and subtraction are required in standard algorithms for multiplication and division, these issues permeate the implementation of both fixed and floating point algorithms for the PIC16C5X/PIC16CXXX families. So essentially I sum the LSB, if there is a carry (as in 0x90+0x80=0x10+carry) I have to increment the LSB+1 of AARG before summing it BARG. The writer of the cited note says me I can repeat the process on next bytes because at every sum I have the carry set if the operation result overflows. Right? I don't think so!. Try this sum: 0x0001ff90+0x00013080=0x00033010 We have (from LSB to MSB): take 0x90, sum 0x80, store 0x10 + set the carry flag take 0xff, increment to 0x00, sum 0x30, store 0x30 + RESET THE CARRY FLAG because 0x00+0x30 doesn't overflow take 0x01, sum 0x01, store 0x02 + reset carry take 0x00, sum 0x00, store 0x00 + reset carry The final result is: 0x00023010!! Quite different from the correct answer. The problem arises for every AARG with a 0xFF byte (except for LSB). Am I completely wrong or the Microchip AppNotes are buggy? (I heard some rumors about that :) I have tried to solve the puzzle but I can't work out an elegant solution. I am sure someone had solved this problem already. PLEASE, do you have some good advice to spare? Thanks Marco BTW: The subtraction routine had the same structure and comment. I think I actually have two problems. ---- Marco DI LEO email: spam_OUTm.dileoTakeThisOuTsistinf.it Sistemi Informativi S.p.A. tel: +39 6 50292 300 V. Elio Vittorini, 129 fax: +39 6 5015991 I-00144 Roma Italy

i have not tested this routine, but something like this may do. i used TC to store the carry for each byte. if the addtion of two bytes or the rollover (FF -> 00) from adding the previous carry then i set the carry for the next byte. michael ;Given A3,A2,A1,A0 ; B3,B2,B1,B0 ; C3,B2,B1,B0 ; TC ; temp carry byte Add32 clrf TC ; clear carry flags movf A0,w addwf B0,w movwf C0 btfsc STATUS,C bsf TC,1 ; set the carry flag for byte 1 Add32_1 movf A1,w addwf B1,w movwf C1 btfsc STATUS,C bsf TC,2 ; set the carry flag for byte 2 btfss TC,1 goto Add32_2 ; no previous carry incf C1,f btfsc STATUS,Z bsf TC,2 ; rolled over, set carry for byte 3 Add32_2 movf A2,w addwf B2,w movwf C2 btfsc STATUS,C bsf TC,3 btfss TC,2 goto Add32_3 incf C2,f btfsc STATUS,Z bsf TC,3 Add32_3 movf A3,w addwf B3,w movwf C3 btfsc TC,3 incf C3,f return -----Original Message----- From: Marco DI LEO <.....m.dileoKILLspam@spam@SISTINF.IT> To: PICLISTKILLspamMITVMA.MIT.EDU <.....PICLISTKILLspam.....MITVMA.MIT.EDU> Date: Thursday, April 16, 1998 1:06 PM Subject: 32 bit add/sub

ok, let's add these 0x0001ff90+0x00013080=0x00033010 michael -----Original Message----- From: Scott Dattalo <EraseMEsdattalospam_OUTTakeThisOuTUNIX.SRI.COM> To: PICLISTspam_OUTMITVMA.MIT.EDU <@spam@PICLISTKILLspamMITVMA.MIT.EDU> Date: Thursday, April 16, 1998 4:16 PM Subject: Re: 32 bit add/sub >> ADD MOVF AARGB1,W ;low byte w=90 >> ADDWF BARGB1 low byte = 10, set the carry >> MOVF AARGB0,W ;Middle low byte w=FF >> BTFSC _C carry is set >> INCFSZ AARGB0,W W=00, zero is set (note this does NOT change the carry flag) >> ADDWF BARGB0 middle low byte = 30, carry is cleared > MOVF AMH,W ;Middle high byte W=01 > BTFSC _C carry is NOT set > INCFSZ AMH,W skipped > ADDWF BMH middle high byte = 02, carry is cleared > MOVF AH,W ;High byte W=00 > BTFSC _C carry is not set > INCFSZ AH,W skipped > ADDWF BH high byte = 00, carry is cleared this answer is 00 02 30 10 the correct answer is 00 03 30 10 michael > >In this case Marco, the Ap note is correct. >Try it out. > >Scott >

Michael Hagberg wrote: > > ok, let's add these 0x0001ff90+0x00013080=0x00033010 Why not? {Quote hidden}> >> ADD MOVF AARGB1,W ;low byte > > w=90 > > >> ADDWF BARGB1 > low byte = 10, set the carry > > >> MOVF AARGB0,W ;Middle low byte > w=FF > > >> BTFSC _C > carry is set > > >> INCFSZ AARGB0,W > W=00, zero is set (note this does NOT change the carry flag) !!!!!!!!!! W=00 !!!!!!!!!!!!!!! skip the next instruction. Carry will stay set. an INCFSZ is not an INCF > > >> ADDWF BARGB0 > middle low byte = 30, carry is cleared !!!!!!!! ^^^^^^^^^^^^^^^^ no, this instruction is not executed <snip> Again, I say try it. This 'cleaned up' version works on my MPLAB: ADD MOVF AL,W ;low byte ADDWF BL,F MOVF AML,W ;Middle low byte SKPNC INCFSZ AML,W ADDWF BML,F MOVF AMH,W ;Middle high byte SKPNC INCFSZ AMH,W ADDWF BMH,F MOVF AH,W ;High byte SKPNC INCFSZ AH,W ADDWF BH,F

On Thu, 16 Apr 1998 19:00:40 -0500 Michael Hagberg <KILLspammhagbergKILLspamSIGNALHILL.NET> writes: >you are right, i confused the incfsz with an incf. >how does BMH ever get added to AMH if the next instruction is skipped? The add only gets skipped if zero was about to be added. In that case, the result in BMH is already correct without adding. _____________________________________________________________________ You don't need to buy Internet access to use free Internet e-mail. Get completely free e-mail from Juno at http://www.juno.com Or call Juno at (800) 654-JUNO [654-5866]

Mike Keitz wrote: > > On Thu, 16 Apr 1998 19:00:40 -0500 Michael Hagberg > <RemoveMEmhagbergTakeThisOuTSIGNALHILL.NET> writes: > > >you are right, i confused the incfsz with an incf. > >how does BMH ever get added to AMH if the next instruction is skipped? > > The add only gets skipped if zero was about to be added. In that case, > the result in BMH is already correct without adding. (Light bulb suddenly shines over my head) At least I have learned to actually test the code before make assumption based in my PIC coding (in)experience. Thanks to Scott, Mike and Michael (and everybody that spent time thinking on my question) for the help on solving this problem. Ciao Marco P.S. do you think I have to apologize to Microchip to have said their AppNotes are buggy? ---- Marco DI LEO email: spamBeGonem.dileospamBeGonesistinf.it Sistemi Informativi S.p.A. tel: +39 6 50292 300 V. Elio Vittorini, 129 fax: +39 6 5015991 I-00144 Roma Italy