primitive vector types

[Bill Baxter]

On Fri, Feb 20, 2009 at 4:25 AM, Mattias Holm <hannibal.holm at gmail.com> wrote:
> Since (SIMD) vectors are so common and every reasonabe system support them
> in one way or the other (and scalar emulation of this is rather simple), why
> not have support for this in D directly?
>
> Yes, the array operations are nice (and one of the main reasons for why I
> like D :) ), but have the problem that an array of floats must be aligned on
> float boundaries and not vector boundaries. In my mind vectors are a
> primitive data type that should be exposed by the programming language.

To justify making them primitive types you need to show that they are
widespread, and that there is some good reason that they cannot be
implemented in a library.  And even if they can't be implemented in a
library right now, it could be that fixing that reason is better than
making new built-in types.   For instance I think there's issues now
with getting the right stack alignment for structs.  But that's
something that needs to be fixed generally, not by making new built-in
types that know how to do alignment right.

> Something OpenCL-like:
>
>        float4 vec;
>        vec.xyzw = {1.0,1.0, 1.0, 1.0}; // assignment
>        vec.xyzw = vec.wyxz; // permutation
>        vec[i] = 1.0; // indexing
>
> And then we can easily immagine some extra nice features to have with
> respect to operators:
>
>        vec ^ vec2; // 3d cross product for float vectors, for int vectors
> xor
>

All of this is pretty much doable in a library.  The only nonobvious
one is vec.xyzw = vec.wyxz which can be implemented using a bunch of
CTFE auto-code generation (see some earlier version of H3r3tic's
Hybrid library).

And using xor for cross product sucks.  It doesn't have the right precedent.

> Has this been discussed before?

I think it has and no one came up with a reason why these can't be
library types.

--bb