SIMD support...

Walter Bright newshound2 at digitalmars.com
Fri Jan 6 00:43:30 PST 2012


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


More information about the Digitalmars-d mailing list