> Introducing a new t, ty_simd_vec(t, uint), instead of using the current
> #[simd] struct { … }, is yet another thing that is controversial about the
> patch
This is indeed a shame because named fields are very nice for clean,
self-documenting apis. Perhaps properties solve this, but I don't think there
would be much will to add more features considering all the work that still has
to be done (I could be wrong though).
~Brendan
On 16/07/2013, at 2:27 PM, Jens Nockert <[email protected]> wrote:
> Hello rust-dev!
>
> I implemented OpenCL-style[0] accessors for SIMD types in Rust[1], the code
> quality isn't near /merge-worthy yet, but I wanted some input.
>
> For some code-examples, go to
> https://github.com/jensnockert/rust/tree/simd/src/test/run-pass/simd-test and
> check it out, you should be able to get the idea of how they work.
>
> Note that I didn't add any actual syntax for vector types yet (since it would
> be highly controversial and I don't know what would be the best option), so I
> just added a simd!(name: T * n) syntax extension that declares a new type
> that maps down to a LLVM <n * T>.
>
> My preference for syntax right now would be simd!(n x T) if I can get that to
> parse, or simd!(T, ..n). And then you would declare a type with type f32x4 =
> simd(4 x f32); and it would magically work. Another option would be some
> variant of the [T, ..n] syntax used for fixed-length vectors.
>
> Introducing a new t, ty_simd_vec(t, uint), instead of using the current
> #[simd] struct { … }, is yet another thing that is controversial about the
> patch and this needs a bit of explanation of the problem with #[simd] struct
> { … }.
>
> To be able to make these accessors work, you unfortunately need to be able to
> generate anonymous types in the compiler, x.even for example (take the
> even-indexed elements of a vector) may be a type that is undeclared. And if
> you want to be able to pretty-print that, you need to be able to generate a
> type without a name, which makes #[simd] struct { … } impossible.
>
> You could just pre-declare all possible options up to 256-bit long, which
> probably would only be a hundred types or so, but would feel a bit silly.
>
> There are also other operations that could generate (possibly) unnamed types,
> like a == b, which should generate a i1-vector, or a shufflevector intrinsic
> that could generate vectors of any length.
>
> Ps. I didn't think of #[simd] (T, T, T, T) &c. before implementing (sanxiyn
> gave me that idea), but I still think that is probably a worse idea than
> adding SIMD as an additional type with actual syntax.
>
> [0]: http://www.khronos.org/files/opencl-quick-reference-card.pdf, page 2,
> "Vector Component Addressing"
> [1]: https://github.com/jensnockert/rust/tree/simd
> _______________________________________________
> Rust-dev mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
