On Sun, 24 Jun 2012 14:17:02 -0400, Timothy Normand Miller wrote:
I had said earlier that overflow is carry from the penultimate bits
into the sign bit. But that isn't accurate. That's true for an
adding positive numbers. But when adding two negative numbers, this
carry would not mean an overflow. Rather this is the proper
definition: When adding two numbers of the same sign, there is an
overflow if the sum does not have the same sign.
correct.
What might be the most efficient way to work that into an adder in
hardware?
it depends :-)
What about subtraction? Subtraction is the same as adding the
negative of the subtrahend. However, in hardware, we don't first
change the sign of the subtrahend and then add, because it is more
efficient to use an optimized addsub macro. Therefore we can't
integrate overflow into the addsub in quite the same way.
The real question is : how often have you used or needed to detect
overflow ?
I suppose you need it because of conditional instructions that test
less than or equal, and those stuff.
You can get rid of of the overflow bit by creating "compare"
instructions
that specify if the operands are signed or not.
Hint: the only difference is to XOR the MSB of the operands, and pass
them
through a substract unit. The comparison result will end up in the
carry bit.
About the optimised add/sub macro that is faster :
- it is pointless since you have designed a pipeline where the
integer part has enormous slack.
- The row of XORs will be optimised away.
- with no "overflow" to compute, no need to worry about it, anyway :-)
"Overflow" is a legacy of an era that is long gone, so don't bother
with it.
Hope it helped you,
Yann
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
