SIMD support...

[Paulo Pinto]

Hi,

just bringing into the discussion how Mono does it.

http://tirania.org/blog/archive/2008/Nov-03.html

Also have a look at pages 44-53 from the presentation slides.

--
Paulo


"Walter Bright"  wrote in message news:je6c7j$2ct0$1 at digitalmars.com...

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