Integer overflow is when the penultimate bit has a carry into the sign bit.
On Thu, Jun 7, 2012 at 5:39 AM, André Pouliot <[email protected]> wrote: > On 2012-06-06 23:15, [email protected] wrote: >> >> Damn mailer sent before i finished :-( >> Here is the full version. >> >> On Wed, 06 Jun 2012 22:20:26 -0400, André Pouliot wrote: >>> >>> The actual flag that are supported are : >>> Zero >>> Negative >>> Overflow >>> Carry >>> NaN >>> Inf >>> Underflow >>> Div0 ( still not resolve the divide debate so conditional) >> >> looks nice and square :-) >> >>> Every other condition can be derived from those flags >> >> >> Right >> >> However, the flags that are valid for FP are pointless for INT, >> so why not reuse the same bits and "alias" (create 2 names, >> and use one in the proper context but giving the same binary code) ? >> Do you expect to find a lot of mixed INT/FP code ? >> > I do not and it is a possibility to use alias for multiple flag that are > exclusive. I think some code will have both at least for some bigger loop > that need to be unrolled even if we have loop operation. > > >>>> I think I have never seen "overflow" used in practice. >>>> Sure, it could be useful but... In practice ? >>>> Do you have examples of actual code that cant't be >>>> working with just the carry bit or the sign bit ? >>>> >>> The only case that overflow is used is for really big integer number >>> that are both negative who are added or subtracted together( I don't >>> remember if it's an add or a subtraction)... It is a corner case. Now >>> that you mention it, for shader I'm not sure if we need to support it. >>> We could round to the nearest expected result. I'll need to think on >>> it. >> >> I was thinking about the integer overflow. >> nevermind... >> > I was thinking about integer overflow too. I didn't precise it was for those > case. > >>>> I thought that the pipeline was FP only, >>>> did that change again ? >>>> Do you intend to include FP status flags too ? >>>> (overflow/underflow/zero/NaN/+/-infinity...) >>>> You could reuse some condition codes and alias them >>>> depending on the type (fp/int) of the last instruction. >>> >>> The pipeline is a FPU/INT combined unit we reuse some part depending >>> on the need that's why it 7 stage long. >> >> I counted 9 stages for the last one published by Tim... whatever. >> > I'm basing what I'm writing about on the PDF and specification document I > published via google doc. > >>> I forgot underflow, thanks I 'll add it in the doc. >> >> :-) >> >>>>> On another note, I was wondering if it would be useful to have two >>>>> different kinds of conditional moves. One moves or does nothing, >>>>> depending on the condition codes. The other moves one input operand >>>>> or the other depending on the truth value of the code, kinda like the >>>>> ?: operator in C. >>>> >>>> >>>> That's a "Mux" instruction there. >>>> You can emulate the "normal" CMOV with a MUX by reusing an operand, >>>> so i'd go for the MUX to keep the opcode count down. >>>> "qui peut le plus peut le moins" >>>> what can do more, can do less :-) >>> >>> Didn't consider the CMOV option, it's an interesting possibility. It >>> could diminish the need for branch and with the current architecture >>> the cost is low. It will need to be defined how to do it but like >>> everything else... >>> >>> I'll add it in the doc :) >> >> >> ok :-) >> However, I was suggesting adding a 2-way MOV (MUX) >> instead of just a conditional move (CMOV). >> It takes 2 CMOV to make a MUX, >> and a MUX can make CMOV as a degenerate case :-) >> >> like a = carry ? b : c; >> >> Yann > > More like a select between two case. Gotcha. I'm already doing the min/max > function on the pipeline with an automatic select so we don't need to do the > compare and move as 2 instruction. I could probably add the same thing for > other flag. I'll need to sleep on that. > André > > > _______________________________________________ > 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)
