SIMD support...

Iain Buclaw ibuclaw at ubuntu.com
Thu Jan 5 18:40:08 PST 2012


On 6 January 2012 01:42, Manu <turkeyman at gmail.com> 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.
>
> The first thing I'd like to say is that a lot of people seem to have this
> idea that float[4] should be specialised as a candidate for simd
> optimisations somehow. It's obviously been discussed, and this general
> opinion seems to be shared by a good few people here.
> I've had a whole bunch of rants why I think this is wrong in other threads,
> so I won't repeat them here... and that said, I'll attempt to detail an
> approach based on explicit vector types.
>
> So, what do we need...? A language defined primitive vector type... that's
> all.
>
>
> -- What shall we call it? --
>
> Doesn't really matter... open to suggestions.
> VisualC calls it __m128, XBox360 calls it __vector4, GCC calls it 'vector
> float' (a name I particularly hate, not specifying any size, and trying to
> associate it with a specific type)
>
> I like v128, or something like that. I'll use that for the sake of this
> document. I think it is preferable to float4 for a few reasons:
>  * v128 says what the register intends to be, a general purpose 128bit
> register that may be used for a variety of simd operations that aren't
> necessarily type bound.
>  * float4 implies it is a specific 4 component float type, which is not what
> the raw type should be.
>  * If we use names like float4, it stands to reason that (u)int4, (u)short8,
> etc should also exist, and it also stands to reason that one might expect
> math operators and such to be defined...
>

It is a fine start to support with a float128 type. :)


With vectors, there are around 20 tied to the x86 architecture iirc,
to whom's base types cover D equivalents of: byte, ubyte, short,
ushort, int, uint, long, ulong, float and double.  I think for
consistent naming convention, much like 'c' is used to denote complex
types, I think 'v' should be used to denote vector types.  For
example, the types available on x86 will be:

64bits:
vfloat[2], vlong[1], vint[2], vshort[4], vbyte[8]

128bits:
vdouble[2], vfloat[4], vlong[2], vint[4], vshort[8], vbyte[16],
vulong[2], vuint[4], vushort[8], vubyte[16]

256bits:
vdouble[4], vfloat[8], vlong[4], vint[8], vshort[16], vbyte[32]


For portability, vectors should be defined with the following logic:For example:

* vector size cannot be zero
* vector size must be a power of 2.
* if there is no hardware support for the vector type/size, then fall
back to static array type of same size.
* defining a vector without a size ie: vint foo;  will default the
size to zero, which will error.


That's all I can think of so far.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';


More information about the Digitalmars-d mailing list