Searching \ for '[PIC]:How to do 24bit Signed Addition/Substration' 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/microchip/devices.htm?key=pic
Search entire site for: 'How to do 24bit Signed Addition/Substration'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]:How to do 24bit Signed Addition/Substration '
2001\04\01@143611 by James Lee Williams

flavicon
face
Hello,

Can someone please tell be how I can do signed 24bit fixed point
addition and substration of the PIC micro controllers.  Everything that
I have seen is for unsigned addition and substraction.  At the moment,
for subtraction, I compliment the result if the carry is clear on the
last subtract of the highest byte.  (Meaning it had to borrow.).  This
seems to give me the correct result, but I don't know if it is the best
or most efficient way to do it for subtraction.

Regards,

James

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2001\04\01@180457 by Olin Lathrop

face picon face
>>
Can someone please tell be how I can do signed 24bit fixed point
addition and substration of the PIC micro controllers.
<<

The mechanics of doing signed and unsigned integer add and subtracts are
identical.  In other words, it doesn't matter whether you think of the
numbers as signed or unsigned.

For an examples, see my ADD24 and SUB24 macros in STD.INS.ASPIC at
http://www.embedinc.com/pic.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, .....olinKILLspamspam@spam@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu


2001\04\01@185754 by James Lee Williams

flavicon
face
Actually it would matter when adding a positive integer with a negative
interger.  For example,
If I where to take this equation x1-x2 -> x_destination.
Let x1 = 15 OR 0x000F
Let x2 = 105 OR 0x0069
-------------
If I didn't handle signed math, the result of this operation would be:
FFA6 which is 65446 in decimal form.  This is clearly not the result of
this subtraction operation.
In order for me to get the correct result I have to decriment the result
if the carry bit is cleared for each of the two bytes.  Indicating a
negative result.  Then, I compliment the result in both low and upper
bytes.  This yields me a 90 result and a signe of negative.  This is the
correct result. Then, I IOR the MSB bit with one to indicate negative.
Again, to illustrate the difference between signed and unsigned would be
in simple addition.  -5 + 10.
Let x1 = 10 (0000000000001010) or 0x000A
Let x2 = - 5(1000000000000101) or 0x8005
--------------
Simple adding these would give the following result.
0x800F OR (1000000000001111).
Now when we remove the sign bit to obtain the actual value we get
0x000F, which is clearly not the result of 10 + (-5).

So in short, the mechanics is not the same.  There is definiatel some
special handling that has to take place to work with signed integers.

Regards,

James


{Original Message removed}

2001\04\01@194206 by Bob Ammerman

picon face
Your problem is that you are using a sign+magnitude representation for the
numbers. Nearly all modern computers use a twos-complement notation for
integers. Twos-complement has the advantage that you can ignore the signs of
the numbers and just treat them as positive. (as long as you don't overflow
the range of representable values).

(tho' sign+magnitude+exponent is the method of choice for floating point)

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam.....mitvma.mit.edu


2001\04\01@201615 by James Lee Williams

flavicon
face
So, you are saying that I can just use a flat ADD_24 through byte
carries reguard of the fact that one might be positive and one negative;
and the result would be the same as, I illustrated before?

All of my values will be positive until I try to subtract x1 from x2.
This cause it to go to negative.  Let me show you what my algorithm
looks like in c:
What is know is that x1,y1 and x2,y2 will always be positive.
Let x1 and y1 be the current position.

void MoveTo(x2,y2)
{
int y1,y2
int deltax = x2-x1;
int deltay = y2-y1;
//incredment or decrement direction of motion.
bool bIncX,bIncY;
if(deltax > 0)bIncX = true;
else bIncX = false;
if(deltay > 0)bIncY = true;
else bIncY = false;
if(deltax < 0) deltax = -deltax;
if(deltay < 0) deltay = -deltay;

int ax = << deltax;
int ay = << deltay;
int decx,decy;
//Now begin Bresenham Move
if(deltay > deltax)
{
 for(decy=ay-deltax;/**/;decy +=ay)
 {
   if(bIncX) x1++;
   else x1--;
   StepXY(x1,y1);
   if(x1==x2) break;
   if(decy >= 0)
   {
     decy -= ax;
     if(bIncY)y1++;
     else y1--;
   }
 }
}
else
{
 for(decx=ax-deltay;/**/;decx +=ax)
 {
   if(bIncY) y1++;
   else y1--;
   StepXY(x1,y1);
   if(y1==y2) break;
   if(decx >= 0)
   {
     decx -= ay;
     if(bIncY)x1++;
     else x1--;
   }
 }
}


{Original Message removed}

2001\04\02@073245 by Bob Ammerman

picon face
>So, you are saying that I can just use a flat ADD_24 through byte
>carries reguard of the fact that one might be positive and one negative;
>and the result would be the same as, I illustrated before?

Yes, as long as you consistently treat the numbers as 2's complement and you
don't overflow the representable values.

Lets take a couple simple 8-bit examples to put your mind at rest:

10 + -1 == 9:

B'00001010' + B'11111111'  = B'00001001'

5 - 10 = -5

B'00000101' - B'00001010' = B'11111011'

Note that we ignore carries out of/borrows into the most significant bit.

It works fine with any number of bits. (It better -- this is the basis
behind integer arithmetic on all modern microprocessors).

>Let me show you what my algorithm looks like in c:

Ah yes, good old Bresenham. You'd be amazed how often this pops up,
sometimes in applications having nothing to do with graphics. I saw a couple
oddities in your code, but I'm guessing they are artifacts of translating
your assembly language in reverse to "C".

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\04\02@090733 by Olin Lathrop

face picon face
>>
Let x1 = 10 (0000000000001010) or 0x000A
Let x2 = - 5(1000000000000101) or 0x8005
--------------
Simple adding these would give the following result.
0x800F OR (1000000000001111).
Now when we remove the sign bit to obtain the actual value we get
0x000F, which is clearly not the result of 10 + (-5).

So in short, the mechanics is not the same.  There is definiatel some
special handling that has to take place to work with signed integers.
<<

The mechanics ARE the same if you use twos complement format.  I can't tell
if you misunderstand the representation of negative numbers in twos
complement or are using some different representation.  For example, using 8
bit integers in twos complement format:

10  -->  00001010
-5  -->  11111011
      + --------
       100000101

The carry out is lost, and you end up with 00000101, which is the right
answer (5 in decimal).


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, EraseMEolinspam_OUTspamTakeThisOuTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\04\02@095941 by James Lee Williams

flavicon
face
Yes, as long as you consistently treat the numbers as 2's complement and
you
don't overflow the representable values.

Lets take a couple simple 8-bit examples to put your mind at rest:

10 + -1 == 9:

B'00001010' + B'11111111'  = B'00001001'

5 - 10 = -5

B'00000101' - B'00001010' = B'11111011'

Note that we ignore carries out of/borrows into the most significant
bit.

It works fine with any number of bits. (It better -- this is the basis
behind integer arithmetic on all modern microprocessors).

Ah, you say that as long as I don't overflow the values, Well this could
easily happen on the second math opertion.  You indicated the following:

5 - 10 = -5
B'00000101' - B'00001010' = B'11111011'

Now if I have to take this result and add it to say 20, then this would
immediately overflow and everything would go wako, am I correct?  This
two's complement stuff makes be nervous when doing it this way.  Do I
have to worry about the carry in this instance?  You are familiar with
Bresenham.  Would this make any difference to the results?

Regards,

James


--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\04\02@100949 by Bob Ammerman

picon face
>Ah, you say that as long as I don't overflow the values, Well this could
>easily happen on the second math opertion.  You indicated the following:

5 - 10 = -5
B'00000101' - B'00001010' = B'11111011'

>Now if I have to take this result and add it to say 20, then this would
>immediately overflow and everything would go wako, am I correct?

No, it would not overflow. Take a look:

-5 + 20 = 15

B'11111011' + B'00010100' = B'00001111'

Again, we get the right answer (note that we _ignore_ the carry out of the
MSBit).

>You are familiar with Bresenham.  Would this make any difference to the
results?

Nope, will work fine with Bresenham.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\04\02@101615 by James Lee Williams

flavicon
face
I guess, that I am messing up the idea of the overflow and the carry.
What would an overflow be considered?  I mean if I carry beyond the
actual size does not generate an overflow, then what does?

I am seeing some of the picture here, but not all of it.
P.S.  I do appreciate you help and clearity in this matter.

Regards,

James

{Original Message removed}

2001\04\02@113046 by Bob Ammerman

picon face
>I guess, that I am messing up the idea of the overflow and the carry.
>What would an overflow be considered?  I mean if I carry beyond the
>actual size does not generate an overflow, then what does?
>I am seeing some of the picture here, but not all of it.
>
>Regards,
>James

After performing an add you compare the carry out to the MSBit of the
result. If they are different then you have an overflow. (I'm pretty sure
that's how it goes).

Try it with a few 8 bit numbers and see if I have that right.  Here is one
example:

64 + 64 = 128

This will overflow because 128 is not in the range of an 8-bit twos
complement value.

B'01000000' + B'01000000' = B'10000000'

Note: Carry out is zero, but the MSBit is a 1, this is an overflow!




Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\04\02@150712 by Olin Lathrop

face picon face
>>
5 - 10 = -5
B'00000101' - B'00001010' = B'11111011'

Now if I have to take this result and add it to say 20, then this would
immediately overflow and everything would go wako, am I correct?
<<

No, try it yourself.  Everything will be fine as long as the values stay
within the representable range for the number of bits you are using.  With 8
bits this range is -128 to +127.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olinspamspam_OUTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\04\02@193135 by o-8859-1?Q?K=FCbek_Tony?=

flavicon
face
Hi,

James Lee Williams wrote:

>I guess, that I am messing up the idea of the overflow and the carry.
>What would an overflow be considered?  I mean if I carry beyond the
>actual size does not generate an overflow, then what does?

Well the 'thing' with signed vs. unsigned, really is only a matter
of how one *interpret* the top bit of the variables.
So, say you have 8 bit variables, these can hold 256 discrete numbers
( only dependant on number of bits ) one way to 'use' them
is to store the numbers 0-255 OR just for fun :) -127 to 127.
Using the so called 2's complement methods we do not need to worry
about anything else than not overflowing the variables and this is
important. Say you're adding three 8 bit variables to one eight bit
sum, in the case of treating the sum as unsigned the three inputs
must be 85 or less to *garantue* no overflow of the output, however
if you treat the output as signed the inputs can only be 42 or less
to have the same garantuee.

So using signed variables normally forces you to think ( goosh :) )
about worst case scenarios, by concluding the maximum theoretical
output for a given formula you need to 'allocate' the variable
size accordingly.

So generally assuming signed math, an addition formula with input size
n bits, needs at least an outputsize of n+1 bits.

Ofcource you can check for overflows, but generally make sure overflow
cannot
happen and you're safe without cluttering up your code with test
for each and every formula.

Some examples for clarity ( signed math ):

Adding two variables with the top bit cleared )( i.e. both positive )
*cannot* have the top bit set of the output. (=overflow)

Adding two variables with the top bit set ( i.e. both negative)
cannot have the top bit of the output cleared. (=overflow)

etc..

>I am seeing some of the picture here, but not all of it.
>P.S.  I do appreciate you help and clearity in this matter.
>Regards,
>James


/Tony

Tony Kübek, Flintab AB            
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
E-mail: @spam@tony.kubekKILLspamspamflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\04\02@193151 by o-8859-1?Q?K=FCbek_Tony?=

flavicon
face
Hi,

I wrote:

>So generally assuming signed math, an addition formula with input size
>n bits, needs at least an outputsize of n+1 bits.

A bit unclear,
this not counting the sign bit, totally this should ofcource be
n+2 bits ( including sign ).

/Tony



Tony Kübek, Flintab AB            
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
E-mail: KILLspamtony.kubekKILLspamspamflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


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