Searching \ for 'Compares' 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=compares
Search entire site for: 'Compares'.

Truncated match.
PICList Thread
'Compares'
1999\09\29@205942 by Tony Nixon

flavicon
picon face
Hi all,

I don't know why, but I "still" get confused when doing things like this
in assembler.

  if RAMx > RAMy then

I just can't seem to keep in my mind what is needed especially when a
SUBLW instruction is involved.

So, to make it easier on myself and others, I've posted a small text
file which lists probably all the variations for basic number
comparisons in 8 and 16 bit format. There are two sets, one give a true
branch and the other gives a false branch.

If anyones interested, the link is

http://www.picnpoke.com/projects/compares.txt

--
Best regards

Tony

http://www.picnpoke.com
Email spam_OUTsalesTakeThisOuTspampicnpoke.com

1999\09\29@214722 by Scott Dattalo

face
flavicon
face
On Thu, 30 Sep 1999, Tony Nixon wrote:

> Hi all,
>
> I don't know why, but I "still" get confused when doing things like this
> in assembler.
>
>    if RAMx > RAMy then
>
> I just can't seem to keep in my mind what is needed especially when a
> SUBLW instruction is involved.

After being nailed a few times myself, I affectionately call it
carry-fucked. However, it helps to use the MPASM (and conseqently gpasm)
recognized macros such as SKPC and SKPNC instead of btfsc status,c etc.

> So, to make it easier on myself and others, I've posted a small text
> file which lists probably all the variations for basic number
> comparisons in 8 and 16 bit format. There are two sets, one give a true
> branch and the other gives a false branch.
>
> If anyones interested, the link is
>
> http://www.picnpoke.com/projects/compares.txt

If I get a chance I'll whip up the 18cxxx equivalent snippets.

I can say though, for the 16-bit sequences it'd be much quicker to:

XH:XL  YH:YL

 movf    yl,w
 subwf   xl,w
 movf    yh,w
 skpz
  incf   yh,w
   subwf xh,w
 skpnc
  goto   x_is_greater_than_or_equal_to_y

Similar sequences exist for the other cases.

more the 18cxxx

 movf   yl,w
 subwf  xl,w
 movf   yh,w
 subwfb xh,w
 bn     x_is_greater_than_y

etc...


Scott

1999\09\29@222058 by Tony Nixon

flavicon
picon face
Scott Dattalo wrote:

> I can say though, for the 16-bit sequences it'd be much quicker to:
>
> XH:XL  YH:YL
>
>   movf    yl,w
>   subwf   xl,w

I'm a bit confused here. C and or Z may be set now.
But they appear to be ignored for the low byte.

>   movf    yh,w
>   skpz
>    incf   yh,w
>     subwf xh,w
>   skpnc
>    goto   x_is_greater_than_or_equal_to_y
>


--
Best regards

Tony

http://www.picnpoke.com
Email .....salesKILLspamspam@spam@picnpoke.com

1999\09\30@131841 by Scott Dattalo

face
flavicon
face
On Thu, 30 Sep 1999, Tony Nixon wrote:

{Quote hidden}

And then I wrote:

{Quote hidden}

And then Tony asked about the Z and C bits after the low-order byte
subtraction. I inadvertantly deleted the message so I don't know what you
exactly asked Tony. However, I think I can answer the generic question of
doing comparisons.

First, don't worry about the size of the variables being compared (because
the result is the same for 8, 16, 24, etc. bits).

Whenever you subtract two numbers, A-B you get this result:

The carry will be set if A is greater than or equal to B. Or equivalently,
the carry will be cleared if B is less than A.

So if I want this kind of result:

if(A >=B )
 foo();

Then I'd write in PIC assembly:

  movf   B,w
  subwf  A,w
  skpnc
   call  foo

The other three cases yield:

if(A > B) foo();

  movf   A,w
  subwf  B,w
  skpc
   call  foo

if(B > A) foo();

  movf   B,w
  subwf  A,w
  skpc
   call  foo

if(B >= A) foo();

  movf   A,w
  subwf  B,w
  skpnc
   call  foo

The main thing to notice is that the Z bit is not necessary for any
comparisons.

Now the 6 word subtraction:

  movf    AL,w
  subwf   BL,w
  movf    AH,w
  skpc
   incf   AH,w
    subwf BH,w

Will correctly propogate the carry. So for the 4 cases, A>B, A>=B, B>A,
and B>=A we only need to either subtract A from B or B from A and then we
need to only check to see if the carry bit is set or is it cleared. The
information in the z bit is not used. Furthermore, we don't need to check
the carry bit from the low order subtraction because the carry information
is automagically propogated to the high order. Is this clearer?


Scott

1999\09\30@141905 by Robin Abbott

flavicon
face
Yes this is quite hard.

I find it easier to show the state of the flags in a table, consider:

movfw X
subwf Y,w

This subtracts X from Y and leaves the result in W.

Now look at flags for the compare operations:

X<Y       C=1, Z=0
X<=Y     C=1  Z=Don't Care
X==Y     C=1 Z=1
X>=Y     C=0 Z=Don't Care
X>Y       C=0, Z=0
X!=Y      Z=1

Hope this helps! (Mind you it would have been easier if Microchip had simply
put the logic in Hardware to "correct" the carry flag after a subtraction !

Robin Abbott - robin.abbottspamspam_OUTdial.pipex.com

**************************************************************************
*
* Forest Electronic Developments
* http://dspace.dial.pipex.com/robin.abbott/FED
*
**************************************************************************

{Original Message removed}

1999\09\30@143708 by eplus1

flavicon
face
<BLOCKQUOTE AUTHOR="Robin Abbott">
X!=Y      Z=1
</BLOCKQUOTE>

Errr... if X!=Y, Z=0. Right? Typo?

James Newton, webmaster http://techref.homepage.com
(hint: you can add your own private info to the techref)
@spam@jamesnewtonKILLspamspamgeocities.com
1-619-652-0593 phoneÊ

1999\09\30@150638 by Quentin
flavicon
face
Robin Abbott wrote:
>
> Yes this is quite hard.
Indeed, this was the most confusing part when I learned PIC's.
> X!=Y      Z=1
Z=0?
> Hope this helps! (Mind you it would have been easier if Microchip had simply
> put the logic in Hardware to "correct" the carry flag after a subtraction !
>
The way I remember the "incorrect" carry bit, is I tell myself that when
I do subtraction, Carry is already set incase I need it, so it clears
when I use it, but stay there if I don't.

A bit of reverse logic.
:)
Quentin

1999\09\30@163111 by Dan Larson

flavicon
face
If one performs a two's complement on the operand being
subtracted and add it to the operand being subtracted
from, the carry flag is inverted for a borrow just as it
is using SUBWF.

This suggests to me, that internally,
SUBWF passes the operand through a two's complement
unit and then through an adder.

They are probably saving hardware by not conditioning
the resulting carry for a subtract operation.

Of course I may be WWAAYYY off! After all, I am only an
amateur engineer <G>!

Dan

On Thu, 30 Sep 1999 21:05:18 +0200, Quentin wrote:

{Quote hidden}

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