On 2012-06-06 21:54, [email protected] wrote:
Hello everybody,
here are more cents :-)
On Wed, 6 Jun 2012 21:34:33 -0400, Timothy Normand Miller wrote:
You have some good points about some ops being redundant, with respect
to a CMP instruction. But we want other instructions to produce
condition codes, and we want them to be meaningful. Of course, GE,
GT, etc. don't make any sense on the condition results of an ADD.
So, let's reduce this by removing the symmetrical comparisons. We need:
- T
- LT signed
- LT unsigned
- LE signed
- LE unsigned
- C
- ~C
- N
- ~N
- V
- ~V
- Z (EQ)
- ~Z (NE)
Doing this, I can only reduce it to 13, which still requires 4 bits.
I think there is a little issue here, as usually,
conditions should be able to be negated, with a final XOR.
here you get to 13 and break the symmetry, which makes compiling
a bit more complex too.
The actual flag that are supported are :
Zero
Negative
Overflow
Carry
NaN
Inf
Underflow
Div0 ( still not resolve the divide debate so conditional)
Every other condition can be derived from those flags
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.
Another thing is :
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. It would require a lot of Flip-Flop
but in FPGA they are free.
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 :)
Have a great evening,
Yann
________________________
Thanks, you too
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)
