SIMD support...

[Manu]

On 6 January 2012 04:40, Iain Buclaw <ibuclaw at ubuntu.com> wrote:

> 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.


I'm confused, are you advocating using arrays of primitive types to express
SIMD values again? Why are you using the square brackets in your example?

I think starting with float128 is wrong. SIMD registers aren't necessarily
floats. The default (language implemented) type should be typeless, and
allow libraries to build typed api's on top of that.
The only thing the language needs to think about is a single typeless,
128bit, 16 byte aligned value.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120106/e7583396/attachment.html>