Exact match. Not showing close matches.
PICList
Thread
'[PIC]:How to do 24bit Signed Addition/Substration '
2001\04\01@143611
by
James Lee Williams
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_OUTpiclistunsubscriberequestTakeThisOuTmitvma.mit.edu
2001\04\01@180457
by
Olin Lathrop
2001\04\01@185754
by
James Lee Williams

Actually it would matter when adding a positive integer with a negative
interger. For example,
If I where to take this equation x1x2 > 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
Your problem is that you are using a sign+magnitude representation for the
numbers. Nearly all modern computers use a twoscomplement notation for
integers. Twoscomplement 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, lowlevel
software)

http://www.piclist.com hint: To leave the PICList
.....piclistunsubscriberequestKILLspam.....mitvma.mit.edu
2001\04\01@201615
by
James Lee Williams

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 = x2x1;
int deltay = y2y1;
//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=aydeltax;/**/;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=axdeltay;/**/;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

>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 8bit 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, lowlevel
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
>>
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) 7429014, EraseMEolinspam_OUTTakeThisOuTembedinc.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

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 8bit 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
>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, lowlevel
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
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

>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 8bit 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, lowlevel
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
>>
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) 7429014, olinspam_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
o88591?Q?K=FCbek_Tony?=

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 0255 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
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
Email: @spam@tony.kubekKILLspamflintab.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
o88591?Q?K=FCbek_Tony?=
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
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
Email: KILLspamtony.kubekKILLspamflintab.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...