Small Vectors Proposal

[Oskar Linde]

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.

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;

/Oskar