Small Vectors Proposal

[Frits van Bommel]

Oskar Linde wrote:
> Mikola Lysenko wrote:
> [snip]
>> 1. Additional primitive types
>>
>> byte2, byte3, byte4, short2, short3, short4, int2, int3, int4, long2, 
>> long3, long4, cent2, cent3, cent4, ubyte2, ubyte3, ubyte4, ushort2, 
>> ushort3, ushort4, uint2, uint3, uint4, ulong2, ulong3, ulong4, ucent2, 
>> ucent3, ucent4
>> float2, float3, float4, double2, double3, double4, real2, real3, real4
>> ifloat2, ifloat3, ifloat4, idouble2, idouble3, idouble4, ireal2, 
>> ireal3, ireal4
>> cfloat2, cfloat3, cfloat4, cdouble2, cdouble3, cdouble4, creal2, 
>> creal3, creal4
> 
> I think the arguing makes much sense, but as the proposal adds 57(!) new 
> domain specific primitive types to the D language specification, I 
> believe it is way too heavy.
> 
> For discussion, here is a not very thought out counter proposal:
> 
> 1. Make the D 2.0 static array pass-by-value instead of it's 
> inconsistent and strange pseudo-reference/value type heritage from C. 
> (Pass by reference could be retained for extern(C) functions only).
> 
> 2. Define ABIs for SSE2, SSE3, etc platforms so that small static arrays 
> can be allocated and passed in SIMD registers.
> 
> 3. Implement vector operations for static arrays.
> 
> Advantages:
> 
> * The code would automatically be platform independent. On a non 
> SIMD-able platform, float[4], byte[8], and so on would all be well 
> defined and work identically to the way they do on SIMD platforms.
> 
> * Future platforms would not require changes to the language 
> specification. float[8] could suddenly become SIMD-able for instance.
> 
> * Minor changes to the language specification. Mostly ABI changes.

I must say, I like this version better.

> A much worse, but less radical proposal, would be to revive the C 
> "register" keyword. Instead of:
> 
> float4 x;
> 
> you get:
> 
> register float[4] x;

Something like this may unfortunately be necessary if backwards 
compatibility is to be maintained with pass-by-reference code. :(