On 1/5/2012 5:42 PM, Manu wrote:
So I've been hassling about this for a while now, and Walter asked me to pitch
an email detailing a minimal implementation with some initial thoughts.
Takeaways:
1. SIMD behavior is going to be very machine specific.
2. Even trying to do something with + is fraught with peril, as integer adds
with SIMD can be saturated or unsaturated.
3. Trying to build all the details about how each of the various adds and other
ops work into the compiler/optimizer is a large undertaking. D would have to
support internally maybe a 100 or more new operators.
So some simplification is in order, perhaps a low level layer that is fairly
extensible for new instructions, and for which a library can be layered over for
a more presentable interface. A half-formed idea of mine is, taking a cue from
yours:
Declare one new basic type:
__v128
which represents the 16 byte aligned 128 bit vector type. The only operations
defined to work on it would be construction and assignment. The __ prefix
signals that it is non-portable.
Then, have:
import core.simd;
which provides two functions:
__v128 simdop(operator, __v128 op1);
__v128 simdop(operator, __v128 op1, __v128 op2);
This will be a function built in to the compiler, at least for the x86. (Other
architectures can provide an implementation of it that simulates its operation,
but I doubt that it would be worth anyone's while to use that.)
The operators would be an enum listing of the SIMD opcodes,
PFACC, PFADD, PFCMPEQ, etc.
For:
z = simdop(PFADD, x, y);
the compiler would generate:
MOV z,x
PFADD z,y
The code generator knows enough about these instructions to do register
assignments reasonably optimally.
What do you think? It ain't beeyoootiful, but it's implementable in a reasonable
amount of time, and it should make writing tight & fast SIMD code without having
to do it all in assembler.
One caveat is it is typeless; a __v128 could be used as 4 packed ints or 2
packed doubles. One problem with making it typed is it'll add 10 more types to
the base compiler, instead of one. Maybe we should just bite the bullet and do
the types:
__vdouble2
__vfloat4
__vlong2
__vulong2
__vint4
__vuint4
__vshort8
__vushort8
__vbyte16
__vubyte16
