Searching \ for 'Substraction of two 16 bit integers' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=substraction+two
Search entire site for: 'Substraction of two 16 bit integers'.

Truncated match.
PICList Thread
'Substraction of two 16 bit integers'
1998\04\06@181902 by marcel

picon face
Hello  i am recieving 12 bit data in to two registers
the next time i recieve data i want to now how mutch the difference is
with the previous data .

Anny body  with Sugestions  thanks in advance


Marcel   Electronic Wokrshop Scope
Amstedam
spam_OUTmarbelTakeThisOuTspamxs4all.nl

1998\04\06@210022 by Ron Kreymborg

flavicon
face
Marcel

If the numbers are unsigned, and stored msb at the lower address, you
could try

       movf    new+1,w         ; subtract lsbs
       subwf   old+1,w
       movf    new,w           ; subtract msbs
       btfss   status,c        ; including any carry
       addlw   1
       subwf   old,w
       btfsc   status,c        ; new smaller?
       goto    smaller         ; yes
       goto    larger          ; no

Ron

On Mon, 6 Apr 1998, marcel wrote:

{Quote hidden}

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ron Kreymborg                   Computer Systems Manager
Monash University               CRC for Southern Hemisphere Meteorology
Wellington Road
Clayton, VIC 3168               Phone     : 061-3-9905-9671
Australia                       Fax       : 061-3-9905-9689
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1998\04\06@212930 by Andrew Warren

face
flavicon
face
Ron Kreymborg <PICLISTspamKILLspamMITVMA.MIT.EDU> wrote:

> If the numbers are unsigned, and stored msb at the lower address,
> you could try
>
>         movf    new+1,w         ; subtract lsbs
>         subwf   old+1,w
>         movf    new,w           ; subtract msbs
>         btfss   status,c        ; including any carry
>         addlw   1
>         subwf   old,w
>         btfsc   status,c        ; new smaller?
>         goto    smaller         ; yes
>         goto    larger          ; no

Ron:

I think you meant for that "BTFSC STATUS,C" to be a "BTFSS".

Also, your code works for Marcel's application (12-bit subtraction),
but it fails on 16-bit numbers when "new" is greater than 0xFF00.

A routine that works for all 16-bit numbers is:

       MOVF    NEWLO,W
       SUBWF   OLDLO,W
       MOVF    NEWHI,W
       SKPC
       INCFSZ  NEWHI,W
       SUBWF   OLDHI,W
       BC      NEW_IS_LARGER_OR_EQUAL
       GOTO    NEW_IS_SMALLER

-Andy

=== Andrew Warren - .....fastfwdKILLspamspam.....ix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

1998\04\06@223158 by Ron Kreymborg

flavicon
face
Nope, btfsc is correct. And it works fine when new > 0xff00. However, a
quick check of your code would indicate that, for example, 65329 < 1104. I
guess the argument here is whether we are dealing with signed numbers or
not. Marcel didn't mention it, and I assumed they weren't.

Ron

On Mon, 6 Apr 1998, Andrew Warren wrote:

{Quote hidden}

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ron Kreymborg                   Computer Systems Manager
Monash University               CRC for Southern Hemisphere Meteorology
Wellington Road
Clayton, VIC 3168               Phone     : 061-3-9905-9671
Australia                       Fax       : 061-3-9905-9689
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1998\04\07@013955 by Regulus Berdin

flavicon
face
I think the problem is to find how much the difference between
two 12 bit numbers not the comparison.

Considering OLD and NEW as MSB, difference will be on OLD
(OLD = OLD - NEW):

       MOVF    NEW+1,W
       SUBWF   OLD+1,F
       BTFSS   STATUS,0
        DECF   OLD,F
       MOVF    NEW,W
       SUBWF   OLD,F

A non-destructive solution can be (DIFF holds the difference):
(DIFF = OLD - NEW)

       MOVF    OLD,W
       MOVWF   DIFF

       MOVF    NEW+1,W
       SUBWF   OLD+1,W
       MOVWF   DIFF+1
       BTFSS   STATUS,0
        DECF   DIFF,F
       MOVF    NEW,W
       SUBWF   DIFF,F

Carry and Zero flag can then be tested for comparison.

Reggie

1998\04\07@034548 by Andrew Warren

face
flavicon
face
Regulus Berdin <@spam@PICLISTKILLspamspamMITVMA.MIT.EDU> wrote:

> Considering OLD and NEW as MSB, difference will be on OLD
> (OLD = OLD - NEW):
>
>         MOVF    NEW+1,W
>         SUBWF   OLD+1,F
>         BTFSS   STATUS,0
>          DECF   OLD,F
>         MOVF    NEW,W
>         SUBWF   OLD,F
> ....
> Carry and Zero flag can then be tested for comparison.

Reggie:

The carry can be incorrect if old < 0x100... Note that the carry is
set in BOTH of these cases:

   ; NEWHI = 00, NEWLO = 20.
   ; OLDHI = 00, OLDLO = 10.

       MOVF    NEW+1,W    ; oldhi=00, oldlo=10, W=20, carry=x.
       SUBWF   OLD+1,F    ; oldhi=00, OLDLO=F0, w=20, CARRY=0.
       BTFSS   STATUS,0   ; -- skip not taken --
       DECF    OLD,F      ; OLDHI=FF, oldlo=f0, w=20, carry=0.
       MOVF    NEW,W      ; oldhi=ff, oldlo=f0, W=00, carry=0.
       SUBWF   OLD,F      ; OLDHI=FF, oldlo=f0, w=00, CARRY=1.

   ; NEWHI = 00, NEWLO = 10.
   ; OLDHI = 00, OLDLO = 20.

       MOVF    NEW+1,W    ; oldhi=00, oldlo=20, W=10, carry=x.
       SUBWF   OLD+1,F    ; oldhi=00, OLDLO=10, w=10, CARRY=1.
       BTFSS   STATUS,0   ; -- skip is taken --
       DECF    OLD,F      ; -- this instruction is skipped --
       MOVF    NEW,W      ; oldhi=00, oldlo=10, W=00, carry=1.
       SUBWF   OLD,F      ; OLDHI=00, oldlo=10, w=00, CARRY=1.

This routine (first discovered by Frank Testa, then independently
rediscovered by a bunch of us) performs the subtraction just as
quickly, but leaves the carry flag in a valid state:

       MOVF    NEWLO,W
       SUBWF   OLDLO
       MOVF    NEWHI,W
       SKPC
       INCFSZ  NEWHI,W
       SUBWF   OLDHI      ; OLD = OLD - NEW, carry valid.

 -Andy

=== Andrew Warren - KILLspamfastfwdKILLspamspamix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

1998\04\07@034553 by Andrew Warren

face
flavicon
face
Ron Kreymborg <RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU> wrote:

> >         movf    new+1,w         ; subtract lsbs
> >         subwf   old+1,w
> >         movf    new,w           ; subtract msbs
> >         btfss   status,c        ; including any carry
> >         addlw   1
> >         subwf   old,w
> >         btfsc   status,c        ; new smaller?
> >         goto    smaller         ; yes
> >         goto    larger          ; no

I replied:

{Quote hidden}

and Ron responded:

> it works fine when new > 0xff00.

   No it doesn't, Ron.

   Your code works when new is less than 0xFF00:

       ; NEWHI = 00, NEWLO = 20.
       ; OLDHI = 00, OLDLO = 10.

       movf    new+1,w         ; W = 20, CARRY = unknown.
       subwf   old+1,w         ; W = F0, CARRY = 0.
       movf    new,w           ; W = 00, CARRY = 0.
       btfss   status,c        ; -- skip not taken --
       addlw   1               ; W = 01, CARRY = 0.
       subwf   old,w           ; W = FF, CARRY = 0.
       btfsc   status,c        ; -- skip is taken --
       goto    smaller         ; -- this instruction is skipped --
       goto    larger          ; -- this branch is taken --

   But it fails when new is > 0xFF00:

       ; NEWHI = FF, NEWLO = 20.
       ; OLDHI = FF, OLDLO = 10.

       movf    new+1,w         ; W = 20, CARRY = unknown.
       subwf   old+1,w         ; W = F0, CARRY = 0.
       movf    new,w           ; W = FF, CARRY = 0.
       btfss   status,c        ; -- skip not taken --
       addlw   1               ; W = 00, CARRY = 1.
       subwf   old,w           ; W = FF, CARRY = 1.
       btfsc   status,c        ; -- skip not taken --
       goto    smaller         ; -- this branch is taken --
       goto    larger          ; -- this branch is NOT taken --

> However, a quick check of your code would indicate that, for
> example, 65329 < 1104.

   A less-quick check would've shown that my code ALWAYS gave the
   wrong answer, since I erroneously swapped OLD and NEW as I
   transcribed it from a message I wrote a couple of years ago.

   Sorry about that... It should have read:

       MOVF    OLDLO,W
       SUBWF   NEWLO,W
       MOVF    OLDHI,W
       SKPC
       INCFSZ  OLDHI,W
       SUBWF   NEWHI,W
       BC      NEW_IS_LARGER_OR_EQUAL
       GOTO    NEW_IS_SMALLER

> I guess the argument here is whether we are dealing with signed
> numbers or not. Marcel didn't mention it, and I assumed they
> weren't.

   My code assumes unsigned numbers, too.

   -Andy

=== Andrew Warren - spamBeGonefastfwdspamBeGonespamix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

1998\04\07@044525 by Regulus Berdin

flavicon
face
> From: Andrew Warren <TakeThisOuTfastfwdEraseMEspamspam_OUTIX.NETCOM.COM>
> ...
> This routine (first discovered by Frank Testa, then independently
> rediscovered by a bunch of us) performs the subtraction just as
> quickly, but leaves the carry flag in a valid state:
>
>         MOVF    NEWLO,W
>         SUBWF   OLDLO
>         MOVF    NEWHI,W
>         SKPC
>         INCFSZ  NEWHI,W
>         SUBWF   OLDHI      ; OLD = OLD - NEW, carry valid.

Tnx for the tip, I should have incr NEW instead of decr OLD. The
way I do is like making a manual/written subtraction, that when
having a borrow, the next digit is decremented.

Reggie

1998\04\07@050356 by Andrew Warren

face
flavicon
face
Regulus Berdin <RemoveMEPICLISTspamTakeThisOuTMITVMA.MIT.EDU> wrote:

> Tnx for the tip, I should have incr NEW instead of decr OLD.

Reggie:

If you do that, your routine won't work when NEW > 0xFF00.  For an
explanation, see my recent message to Ron.

-Andy

=== Andrew Warren - fastfwdEraseMEspam.....ix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

1998\04\07@162449 by Scott Dattalo

face
flavicon
face
Since Marcel will need to save the 12(16)-bit number from
one iteration to the next, Andy's otherwise perfectly
working routine needs a slight modification.

Andrew Warren wrote:

>        MOVF    OLDLO,W
>        SUBWF   NEWLO,W
>        MOVF    OLDHI,W
>        SKPC
>        INCFSZ  OLDHI,W
>        SUBWF   NEWHI,W

        MOVF    NEWLO,W
        MOVWF   OLDLO
        MOVF    NEWHI,W
        MOVWF   OLDHI

>        BC      NEW_IS_LARGER_OR_EQUAL
>        GOTO    NEW_IS_SMALLER


It's hardly worth showing, but it's possible to shave a
cycle off of this 'compare and save' algorithm:

   movf   new+1,W   ;W = LSB of new
   subwf  old+1,W   ;W = old - new  (LSB)
   subwf  old+1,F   ;old = old - (old - new) = new

 ;at this point, the carry bit is set if the low byte of old
 ;is greater than or equal to the low byte of new. Also, new
 ;has been copied to old's location.

   movf   new,W
   skpc
    incfsz new,W    ;
     subwf old,W

   movf   new,W     ;Now copy the high byte. Note that
   movwf  old       ;the subwf trick won't work here.
                    ;But then again, Dmitry hasn't put his
                    ;two rubles in yet.

   skpnc
    goto  old_is_larger_or_equal
   goto   old_is_smaller



BTW Andy, you forgot your comments!

Scott

1998\04\07@195740 by Ron Kreymborg

flavicon
face
Andy

Yes, you are right.  My code doesn't work for all 16-bit numbers, but not
just those where NEW > 0xff00. For example, it works fine for the case
NEW=0xff20, OLD=0xff21. The problem is if the ADDLW 1 instruction gets
executed when the MSB of NEW is 0xff. There is nothing in the following
code to handle the carry out.

Well at least it worked for 12-bit numbers.

Cheers
Ron

On Tue, 7 Apr 1998, Andrew Warren wrote:

{Quote hidden}

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ron Kreymborg                   Computer Systems Manager
Monash University               CRC for Southern Hemisphere Meteorology
Wellington Road
Clayton, VIC 3168               Phone     : 061-3-9905-9671
Australia                       Fax       : 061-3-9905-9689
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...