On Wed, 06 Jun 2012 22:20:26 -0400, André Pouliot wrote:
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
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
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 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 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 :)
Glad I helped :-)
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 :-)
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
