say you have 3 unsigned 4-bit integers.. A,B,and C.. where C is the sum of A and B. how in the world would i be able to tell if C was OVERFLOWED or not. the book says only use the logical operators (OR,AND,NOT,XOR). (note:: i know the fact that the answer will be wrong if an overflow occured..but the computer doesn't *know* that, it just adds A and B and leaves you with C)

i had to do the same thing with signed integers which was easy as ass, but this has me stumped good.

if someone could shed some light on this for me without just handing me the answer..that'd be cool. i have tried various things and notice no patterns to grab hold of like the signed int problem....

thanks,
--jeremy

I'm not sure if I understood your question, but... if C is an unsigned int, then you know that it can only allocate a positive value between 0 and 65.535. You could maybe make an if-statement to check if it overflows the number 65.535 (if C > 65.535)... I think . But that is just a guess. I'd also like to know an effective way to handle overflow, since my books does not teach how to handle it either :S.

here's a example using 4 bits (the largest value obviously being 15)...

now ..obviously 10+12 does not equal 6. and with your suggestion..6 is not greater than 15

see what i'm sayin .. the ALU will always leave you with a result that fits in an N-bit register...but it's not necassarily correct depending on if there was a carry.....hmmmm..

EDIT::: Apparently I am having reading difficulties today.... think about the operations you are given....

I see... hmmmmmmm. That is going to be interesting to know . I've not played with C for a long time now, I'm trying to learn Java. One of the biggest problems we all face is that the programming books around, besides being expensive, are terrible written

no ..it is general. it is the very beginnings of a CS book (chapter 2 actually . just on various data types and what not... the problem in the book was to actually write a 'procedure' (just some pseudo code..), that takes three 4-bit unsigned integers as arguments, then determines if an overflow occured (using only bit-wise operators..though i can't see doing this without conditional checks...),and returns either 0000 or 1000.

apparantly, you're not the only one having reading problems today...after i posted, i had read your edit, and still i did not register in my brain what you just said...

i will look again

here's my ideas thus far ;)

im working on detecting whether a carry out was performed.. with 2 N-bit unsigned integers..

--if both MSBs (most significant bits) are 1..carryout is definate and overflow is imminent..
A :: 1100 B :: 1001

of course by looking at these *we* know that the MSBs are 1...using bitwise AND we
find out by using a mask of 1000..

1100 A
1000 MASK
====
1000 (result of A .AND. MASK)

1001 B
1000 MASK
====
1000 (result of B .AND. MASK)

in psuedo code i could say...
if [ (A .AND. MASK) .AND. (B .AND. MASK) ] then we overflowed...

--if both MSBs are 0 ..no carryout, overflow impossible..
A :: 0111 B :: 0111 (both set to the largest they can be without hitting the MSB, to prove a point (to myself anyway..) ;)

0111 A
1000 MASK
====
0000

0111 B
1000 MASK
====
0000

... if [ ! (A .AND. MASK) .AND. (B .AND. MASK) ] then, no overflow

im thinking...i have checked the MSB.. if im this far in the procedure (that is ..either both MSBs were not 1...or not 0)... the only other option is that one of them is 1 and the other is 0. time to shift the mask to the right by one (ie.. 0100), until it is 0000 (then i'm absolutely done eh?). once i have my new mask, i start the process over again..yadda yadda...

ofcourse there's still peices to put together, this was just the rough idea. i would've just went ahead and worked this down till i figured out whether it will work or not.. but i figured i'd post the idea now...go to bed, wake up tomorrow, and by that time someone will have kicked me if i'm perhaps just doing this the hardway ;). i'm still not all too sure if i'm *allowed* to use an 'if' statement for control?? if someone knows that it can *definately* be done with using any control mechanisms.. i will attempt to structure everything tomorrow..(and rewrite the 2's complement one i did before..)

thanks for helping,
--jeremy

so, if you can do the check on signed int's, can you not convert the unsigned one into a signed one, and use the same algo you have?

i dont believe that's what the questions in the book were looking for tho?

the same rules would also not apply.. the whole thing with the 2's complement example i had previously done was that, ..if two like signs were added and the sum ended up being of the opposite sign..we had overflowed, if the sign of the sum remained the same, we're good. unless ofcourse the signs of the two integers being added were different to begin with..then no overflow is possible. i can't imagine how i would apply that same idea to this unsigned example..perhaps there is some truth that i am yet unaware of tho? also, if im understand the method you suggest correctly..

say i had to determine whether or not the following unsigned ints overflowed..

0111
0111
====
1110

had i applied the rules i used for the 2's complement as explained above..that would be returned as an overflow by my 'procedure', when in fact it is perfectly valid. 14 obviously is not in the range of a 4-bit 2's complement representation. overall i believe the examples , and all of chapter 2(to me anyway..), portrayed the fact that, a binary string of digits is a binary string of digits.. each bit can either be 1 or 0 regardless but the same bit-string might mean different things depending on what they are to represent. the computer (or in this case the ALU), has no clue about what these bits are for, it simply does what it does and moves on..

but, perhaps i have misunderstood your comment in which case i apologize for the drawn out explanation of my sometimes irrational thought. please do correct me or give me some examples of what you meant..

thanks,
--jeremy