Just so folks have the heads up, here is the discussion of the blog post on reddit: http://www.reddit.com/r/rust/comments/1igvye/vision_for_rust_simd/
~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
