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 <j...@nockert.se> wrote:

> On H.25/07/16, at 12:13, Brendan Zabarauskas <bjz...@yahoo.com.au> 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
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to