> > > movf ,W > > > skpnc > > > incfsz ,W > > > addwf ,F > > > > > > As a slick way to do handle carries in an N-byte multiple precision add. > > If > > > this trick is well-known, it has somehow escaped me. [James: how about a > > > section on N-byte arithmetic in the code snippets archive?] > > > > Note that this only works if RESULTBYTE is the last (highest) byte of the > > multi-byte number. The carry generated by this code snippet won't be > > correct for use by the next byte. This is because a carry could occur > from > > the INCFSZ instruction, which is then lost when the ADDWF instruction > > executes. > > This is _not_ true. > > 1: was 255. The INCFSZ will skip the ADDWF with carry still _set_ > to bring the carry up to the next byte. > > 2: was some other values. The INCFSZ will give us a result that > fits in 8 bits, then the ADDWF will set carry properly for the next byte. Sorry, you're right. Somehow my mind blocked out the fact that is was an INCFSZ, not INCF. However, that brings up another problem. If SOMEBYTE was 255 and there was an incoming carry, the ADDWF will get skipped, which will prevent RESULTBYTE from being set. I am presuming here that the point of the code snippet is to perform an add with carry in/out of SOMEBYTE + RESULTBYTE --> RESULTBYTE? ***************************************************************** Olin Lathrop, embedded systems consultant in Devens Massachusetts (978) 772-3129, olin@cognivis.com, http://www.cognivis.com -- http://www.piclist.com hint: PICList Posts must start with ONE topic: "[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads