Post by thread:Compares

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_OUTsalesTakeThisOuTpicnpoke.com

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

On Thu, 30 Sep 1999, Tony Nixon wrote: {Quote hidden}> Date: Thu, 30 Sep 1999 10:59:28 +1000 > From: Tony Nixon <Tony.NixonKILLspamENG.MONASH.EDU.AU> > Reply-To: pic microcontroller discussion list <.....PICLISTKILLspam.....MITVMA.MIT.EDU> > To: EraseMEPICLISTspam_OUTTakeThisOuTMITVMA.MIT.EDU > Subject: Compares > > 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 And then I wrote: {Quote hidden}> 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. > 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

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.abbottspam_OUTdial.pipex.com ************************************************************************** * * Forest Electronic Developments * http://dspace.dial.pipex.com/robin.abbott/FED * ************************************************************************** {Original Message removed}

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}>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 >