On Thu, 19 Oct 2000, Olin Lathrop wrote: > > > > 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? Yep. Challenge: If you don't care about the carry out, it's possible to perform a 16-bit add in 5 cycles. Since Nikolai is away from his computer, Dmitry is quiet, John is (where is John?) and Andy is on a plane, this oughta be an interesting challenge. Scott -- http://www.piclist.com hint: PICList Posts must start with ONE topic: "[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads