I'm not saying that the shuffles would have to be generated using the field
names - that would be near impossible.
For example:
~~~
#[simd] struct RGB <T> { r: T, g: T, b: T, a: T }
~~~
Shuffling would still use the CL syntax:
~~~
let v2 = v.s3201
~~~
I would be really interested to hear what sanxiyn had in mind for #[simd] when
he added it.
Relevant PRs with discussions:
https://github.com/mozilla/rust/pull/5841
https://github.com/mozilla/rust/pull/6214
https://github.com/mozilla/rust/pull/7705
~Brendan
On 16/07/2013, at 9:06 PM, Jens Nockert <[email protected]> wrote:
> On H.25/07/16, at 12:13, Brendan Zabarauskas <[email protected]> wrote:
>
>>> 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).
>
> While nice, I don't think this is a good idea.
>
> It leads to very complex shuffle-syntax, and makes intrinsics and anything
> else with a T1 (x T1) -> T2 type signature (comparisons, non-bitwise casts)
> much harder to call and implement.
>
> It would also mean that all intrinsics would have to be generic. And that you
> need to pattern-match match in trans to generate shufflevector operations.
>
> Examples,
>
> ~~~ OpenCL shuffle
> let v2 = v.abgr;
> ~~~ Named property shuffle
> let v2 = match v1 { rgba { r:r, b:b, g:g, a:a } => rgba { r:a, g:b, b:g, a:r
> } };
> ~~~
>
> And that isn't even the degenerate case of wanting to replace the order of a
> subset of the elements of a u8x16-like type which succintly can be described
> in OpenCl-like syntax.
>
> ~~~
> v1.s89 = v1.s98; // or for complex arithmetic
> let i0 = a * b;
> r.even = i0.even - i0.odd;
> r.odd = a.odd * b.even + a.even * b.odd;
> ~~~
>
> And these I cannot write the named-property variants of on my phone, so you
> will have to imagine what they would look like.
>
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
