Truncated match.
PICList
Thread
'unsigned 16bit subtract'
1999\02\12@130021
by
Dave Johnson

I'm working on a sort routine, sorting 16 bit values that can span the
full "unsigned" range. To compare two values in the sort, I'm subtracting
one from another: if the result is negative, then the second is larger
than the first.
I started with the 16bit subtract routine in Myke's book:
movf r2hi, w
subwf r1hi, w
movwf temphi
movf r2lo, w
subwf r1lo, w
btfss status, c
decf temphi
; check for negative value
btfsc temphi, 7
goto Greater_Than
...
but this is a "signed" routine in the sense that it looks at the high bit
of the result to see if it's negative, and because he does the
subtraction "backward", the czrry flag is useless. But I'm using full
"unsigned" 16 bit values, so for instance if I'm subtracting 0x0001 from
0x8001, the result will get reported as negative, since the high bit is
set, even though the number didn't "roll over."
What I want is a 16 bit subtract that will let me check the carry flag at
the end, to see if the number rolled over.
Here's what I think, and I'm looking for confirmation that this will
work: I can subtract the low bytes first, and if carry is set (result is
"negative") then decrement the high byte of the number I'm subtracting
FROM (basically perform the carry). Then I subtract the high bytes, and
if the carry is set after that, then the result is negative (meaning that
the number I'm subtracting is larger than the number I'm subtracting
from). That's the brute force and awkwardness approach, but it seems
logically sound to me. Did I miss something?
Even if that will work, is there a more elegant (read: faster) way to do
this? Somehow I suspect there is :)
Thanks for any help,
Dave Johnson
1999\02\12@130642
by
jamesp

What about inverting the number you are subtracting, then addig it to the numbe
r
you are subtracting from and looking for a carry?
Jim
{Quote hidden}>I'm working on a sort routine, sorting 16 bit values that can span the
>full "unsigned" range. To compare two values in the sort, I'm subtracting
>one from another: if the result is negative, then the second is larger
>than the first.
>
>I started with the 16bit subtract routine in Myke's book:
>
>movf r2hi, w
>subwf r1hi, w
>movwf temphi
>movf r2lo, w
>subwf r1lo, w
>btfss status, c
> decf temphi
>
>; check for negative value
>btfsc temphi, 7
> goto Greater_Than
>....
>
>but this is a "signed" routine in the sense that it looks at the high bit
>of the result to see if it's negative, and because he does the
>subtraction "backward", the czrry flag is useless. But I'm using full
>"unsigned" 16 bit values, so for instance if I'm subtracting 0x0001 from
>0x8001, the result will get reported as negative, since the high bit is
>set, even though the number didn't "roll over."
>
>What I want is a 16 bit subtract that will let me check the carry flag at
>the end, to see if the number rolled over.
>
>Here's what I think, and I'm looking for confirmation that this will
>work: I can subtract the low bytes first, and if carry is set (result is
>"negative") then decrement the high byte of the number I'm subtracting
>FROM (basically perform the carry). Then I subtract the high bytes, and
>if the carry is set after that, then the result is negative (meaning that
>the number I'm subtracting is larger than the number I'm subtracting
>from). That's the brute force and awkwardness approach, but it seems
>logically sound to me. Did I miss something?
>
>Even if that will work, is there a more elegant (read: faster) way to do
>this? Somehow I suspect there is :)
>
>Thanks for any help,
>
>Dave Johnson
>
1999\02\12@143627
by
Gerhard Fiedler
At 10:00 02/12/99 0800, Dave Johnson wrote:
>I'm working on a sort routine, sorting 16 bit values that can span the
>full "unsigned" range. To compare two values in the sort, I'm subtracting
>one from another: if the result is negative, then the second is larger
>than the first.
>
>I started with the 16bit subtract routine in Myke's book:
maybe you can sort after the high byte first (ie. only 8 bit math), and
then sort after the low bytes within the groups with equal high byte.
depending on the numbers you have that can be faster.
ge
1999\02\12@151544
by
Dave Evans
part 0 741 bytes contenttype:application/octetstream;Good Luck!
Dave Evans
spam_OUTdave.evansTakeThisOuTdlcc.com
{Quote hidden}> Original Message
> From: Dave Johnson [
.....djohnsonKILLspam@spam@SIRIUS.COM]
> Sent: Friday, February 12, 1999 10:00 AM
> To:
PICLISTKILLspamMITVMA.MIT.EDU
> Subject: unsigned 16bit subtract
>
>
> I'm working on a sort routine, sorting 16 bit values that can span the
> full "unsigned" range. To compare two values in the sort, I'm
> subtracting
> one from another: if the result is negative, then the second is larger
> than the first.
>
ContentType: application/octetstream;
name="test.asm"
ContentDisposition: attachment;
filename="test.asm"
Attachment converted: wonderland:test.asm (????/) (00029F32)
1999\02\12@183209
by
Regulus Berdin
Hi,
Dave Johnson wrote:
> What I want is a 16 bit subtract that will let me check the carry flag at
> the end, to see if the number rolled over.
The standard subtract works. Carry is preserved at the end.
sub16:
movf r2lo,w
subwf r1ho,f
movf r2hi,w
skpc
incfsz r2hi,w
subwf r1hi,f
If carry flag is set, there is no borrow occured. So r1 is more than or
equal to r2.
regards
Reggie
More... (looser matching)
 Last day of these posts
 In 1999
, 2000 only
 Today
 New search...