On Sun, Jun 24, 2012 at 2:50 PM, <[email protected]> wrote: > 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 > ?
No idea. :) I'm taking a conservative approach to things I don't know enough about. Probably 20 years ago, I worked out the use of the overflow bit in comparisons, so my memory isn't fresh. > > 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. Yes, and I have considered that option. Moreover, I specifically want to test that option. What I'm doing right NOW is working on the option where there are complex predicates and compare instructions that don't know the condition. Next, I'll include an alternative option where the compare instructions know what the condition is and therefore the predicates are simpler. Note that when I say predicates, I mean like ARM, not Itanium. > > 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. Pointless for correctness, extremely indirect for speed, not pointless for area. P = area of add(A,B) or sub(A,B) Q = area of sub(0,B) R = area of addsub(A,B,selector) If (R > P+Q), then we change the sign separately. Otherwise we use the addsub. That accounts not just for area but also leakage power. There are also separate dynamic power considerations. Indeed, for dynamic power considerations, we may argue for separate adder and subtractor paths, because now we can clock-gate them separately. If they're combined, then a larger circuit is on for every add or subtract. If they're separate, then there are two smaller circuits that are mutually exclusive, albeit with larger total area and leakage power. > - The row of XORs will be optimised away. It's not a row of XORs. A 1's compliment is a row of XORs, while a 2's complement has its own carry chain. Also, (A-B) is the same as (A+(~B)+1), so if you can have a carry-in, you can do this with just a row of XORs and some multiplexing. But now we're running into tools limitations. The HDL synthesizers I've encountered do a crap job of optimizing (A+B+1), where they end up with two adders, rather than one adder with carry-in. As a result, I end up doing (A+B+1) as (A-(~B)). > - with no "overflow" to compute, no need to worry about it, anyway :-) I have to put some more thought into the implications of this. I'm not a compilers person, so I don't know what the tradeoffs are with regard to signed vs. unsigned comparisons. I just know what lots of different CPUs provide. Obviously, we should evaluate this issue, but I need input from someone who is an expert on compilers. > > "Overflow" is a legacy of an era that is long gone, so don't bother with it. I would like to know more about this. Can you provide a longer explanation? With an overflow bit, (A<B) is a single instruction change, depending on whether A and B are signed or not. Without an overflow bit, how is this handled? > > Hope it helped you, Thanks! > 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) -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
