Is it possible to add two signed 8-bit numbers together and set both the carry and overflow bits?
Per your comments, your question seems to be "is it possible to have both carry and overflow set for a two's complement add involving signed number?" It is. The typical implementation is to take the exclusive-OR of the carry-in for the last adder with the carry-out at the end of the chain -- hence, an overflowing addition of negative numbers will cause the carry-out bit to be set and the overflow bit to be set.
Here's an example, add -1 to -128:
Carry 10000 0000
1000 0000 (-128)
1111 1111 (-1)
---------
0111 1111 (oops, this is 127!)
Carry will be set, since the last add resulted in a carry -- and overflow will be set based on the rule above (also, note that -128 added to -1 is obviously not 127)
You don't have access to the flags in C, even if you could get the compiler to generate code that set them, you have have no way to use them.
You can write your own add routine in C that will return carry and overflow flags for
signed 8-bit operands. If you're referring to the hardware carry and overflow bits inside
the processor, no, that cannot be done portably in C.
Related
I am working with the mips assembly language but am confused on the overflow aspect of arithmetic here.
Say I am subtracting 25 from 20 and end up with -5. Would this result in an overflow?
I understand that with addition if you add 2 positive numbers or 2 negative numbers and the output is the opposite sign then there is overflow but am lost when it comes to subtraction.
Find the examples at the extreme, let's do it in 8 bits signed to make it simple but the same principles holds in 32 bits
minuend: the smallest possible positive (non-negative) number, 0 and
subtrahend: the largest possible number, 127
When we do 0 - 127, the answer is -127 and that indeed fits in 8 bits signed. There is a borrow. In any processor the effect of the borrow is to propagate 1's though out the upper bits, making it a negative number of the proper magnitude.
Different processors set flags differently based on this borrow, MIPS doesn't have flags, while x86 will set flags to indicate borrow, and other processors will set the flags to indicate carry.
In 8 bit signed numbers:
minuend: the smallest possible positive (non-negative) number, 0 and
subtrahend: the largest possible number, -128
When we do 0 - -128, the answer should be 128, but that cannot be represented in 8 bit signed format, so this is the example of overflow. 0 - -127 = 127 and that can be represented, so no overflow there.
If we do it in 8 bits unsigned, your example of 25-20 = -5, but -5 cannot be represented in an unsigned format, so this is indeed overflow (or modular arithmetic, if you like that).
Short answer: Yes, as the 32-bit representation of -5 is FFFFFFFB.
Long answer: Depends on what you mean by "overflow".
There's signed overflow, which is when you cross the 7FFFFFFF-80000000 boundary.
And there's unsigned overflow where you cross the FFFFFFFF-00000000 boundary.
For signed arithmetic, signed overflow is undeniably a bad thing (and is considered undefined behavior in C and other languages). However, unsigned overflow is not necessarily a problem. Usually it is, but many procedures rely on it to work.
For example, imagine you have a "frame timer" variable, i.e. a 32-bit counter variable that increments by 1 during an interrupt service routine. This interrupt is tied to a real-time clock running at 60 hertz, so every 1/60th of a second the variable's value increases by 1.
Now, this variable will overflow eventually. But do we really care? No. It just wraps around back to zero again. For our purposes, it's fine, since we really don't need to know that accurately how long our program has been running since it began. We probably have events that occur every n ticks of the timer, but we can just use a bitmask for that. Effectively in this case we're using unsigned overflow to say "if this value equals FFFFFFFF and we're about to add 1 to it, reset it to zero instead." Which thanks to overflow we can easily implement without any additional condition checking.
The reason I bring this up is so that you understand that overflow is not always a bad thing, if it's the unsigned variety. It depends entirely on what your data is intended to represent (which is something you can't explain even to a C compiler.)
I have searched a bit and didn't find anything that properly explained this.
In MIPS you have add and addu to do additions. The main difference is that addu doesn't generate an overflow exceptions.
Let's say we have this binary (I'm using four bits although MIPS is 32 for simplification):
0111
If we add 1 it becomes 1000.
With the add instruction there is an overflow and no carry, since a positive 7 became a negative 1 (assuming two's complement in MIPS). This generates an overflow exception too.
With the addu there is no overflow and no carry, since everything went as expected.
Now let's say you have this binary:
1111
If we add 1 it becomes 0000.
With the add instruction there should be no overflow since a negative 1 became a 0. What about the carry out flag, does it change to 1?
And what happens with the addu instruction? Is it considered overflow, since 15 became 0? I know that there is no overflow exception, but what happens to the overflow flag? Does it get set to 1? What about the carry flag?
There is no carryout flag in MIPS architecture.
Overflow exception in the case of addition happens when the sign of the result is different form the expected sign which can happen:
When you add two positive numbers and you get a negative number as a result
When you add two negative numbers and you get a positive number as a result
So yes, in your hypothetical 4 bit MIPS 0111+1 results in an overflow, with the corresponding flag being activated.
I was studying from a web course and found an example in which subtraction operation was explained. In that example,
A= A5H, B= 9BH
and operation SUB B was executed.
As the subtraction operation in 8085 microprocessor is carried out by converting subtrahend into 2's complement and then adding it to minuend, the answer thus obtained was A= (0000 1010)2(see figure)
As it is clearly visible that a carry is produced after the operation, so the CY flag, i.e., carry flag must be SET. But they explained it as under:
"CY bit seems to be ‘1’. But it is complemented and then
stored. Therefore, CY bit is stored as ‘0’."
I didn't understand that why carry flag is to be complimented? Is it because the subtrahend is converted into 2's complement or anything else?
Indirectly, yes.
In order to subtract with a 'borrow' status result as 808x architecture requires, you add the complement of the subtrahend, AND complement the carry out from the ALU to get the 'borrow' bit. Thus you complement carry for effectively the same reason you complemented the subtrahend, but not directly because you did so.
Some CPUs instead have a 'carry/NOT borrow' status which uses the un-complemented carry logic. See https://en.wikipedia.org/wiki/Carry_flag#Carry_flag_vs._borrow_flag .
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Hey Everyone,
I'm working on a project which requires me to use signed adders.
How does one implement this adder in HDL without using the arithmetic operators?(test bench not required), is there a way to modify an existing adder circuit to work as a signed adder, if so your inputs will be of great help.
Thank you in advance.
To answer the first part of your question, you need to implement (for example) a ripple carry adder, which is a series of full adders connected in a certain way. There will be tons of stuff about this on the internet, because it is standard stuff. For example: http://eda-playground.readthedocs.io/en/latest/code-examples/full-adder.html
To answer the second part of your question: an adder which can handle signed numbers is identical to one that can only handle unsigned numbers as long as the inputs and outputs use two's complement representation.
To negate a number using two's complement representation, one inverts all the bits and adds one. For example, using an 8-bit two's complement representation
23 is 00010111 and
-23 is 11101001 which was generated by inverting all the bits (11101000) and then adding 1
now let's add the two together using a standard adder, ie by doing long addition as you would have learnt at school:
23 is 00010111
-23 is 11101001 +
--------
(1)00000000
--------
Look: it works! The (1) is the carry output, which you can ignore. The result of adding two numbers needs to be one bit wider than the wider of those two numbers. So, really we should have widened the two inputs to 9-bit first. So, in a 9-bit two's complement representation:
23 is 000010111
-23 is 111101001 +
---------
(1)000000000
---------
You widen numbers which use a two's complement representation (i.e., signed numbers) by sign-extending: that is, you take the left hand bit (the MSB, the sign bit) and repeat it leftwards (in this case once, because we are widening by just 1 bit).
So, I've been trying to learn about computers for the last few months and really learn in detail how they work. I was learning about subtractors recently and I was wondering..
First of all, to my understanding, a subtractor uses two's compliment to get a result. But, why does it subtract? for example, the two's compliment of 5 (0101) is 1011. But, that also is a positive eleven. Even though the number gets negated, what makes the subtractor take that as a negative number instead of another positive number? If the problem was 8 - 5, what stops it from doing 8 +11?
What makes it recognize a signed bit from an unsigned bit? I've heard the program running decided, but then the question would be what gives the program the ability to decide whether to add or subtract and how is that interpreted to the CPU and AlU.
Also, I've learned that AlU's use one circuit that switches forth between addition and subtraction. How does this circuit work? What makes it decide whether to add or subtract?
Lastly, how does this circuit switch from addition to subtraction? The only subtractor I've been shown is an adder with not gates attached to it? How does the circuitry differ in something that can change functions?
Subtraction is nothing else than addition with the second operand being a negative number. Two's complement is constructed so that adding with a negative number simply works as expected (when ignoring overflow).
The ALU does not need to know if a number is positive or negative, but in two's complement all numbers with the most significant bit set to 1 is a negative number. The ALU doesn't care because two's complement is designed so that it all just works.
Now, subtraction is just addition so we can use the same circuits to carry out both functions. What the switch you are talking about does is that it negates the second operand (negation is pretty easy in two's complement, there are a few ways to do it), then it adds the numbers.