[rust-dev] RFC: Tuple Swizzling/Shuffling

Richard Diamond wichard at vitalitystudios.com
Thu Jan 16 23:51:01 PST 2014


That would require quite a bit of look-ahead in the parser (unless you
really meant 'let (a, b, c) = ..') and doesn't expose the intent of the
swizzle without effort; not to mention in terms of grace its not exactly an
upgrade from:
let (v_x, v_y, v_z, v_w) = f32x4(..);
// things

However, if you were just referring to being able to access individual
elements by an index, yeah, that's a bruise from tuple usage and sadly not
yet fixable by generics.

Richard Diamond


On Thu, Jan 16, 2014 at 4:02 AM, Liigo Zhuang <com.liigo at gmail.com> wrote:

> let tuple = (1.0f32, 2.0f32, 3.0f32, 4.0f32);
> let a,b,c = tuple.1, tuple.2, tuple.3; // I prefer this. (0-based?)
> // or: tuple.a, tuple.b, tuple.c, ...z
> // or: tuple[index]
>
>
> 2014/1/15 Richard Diamond <wichard at vitalitystudios.com>
>
>> Basically the idea here is to support shuffling for SIMD types in a way
>> that can be easily lowered to IR (LLVM's shufflevector requires the mask be
>> a vector of constants, so an intrinsic function is out of the question),
>> however I image this sugar could extend to tuples with multiple types.
>>
>> Some examples:
>>
>> let vec = (1.0f32, 2.0f32, 3.0f32, 4.0f32);
>> let all_x = vec -> (0, 0, 0, 0); // perhaps this should be "vec <- (0, 0,
>> 0, 0)"?
>> assert_eq!(all_x, (1.0f32, 1.0f32, 1.0f32, 1.0f32));
>> let single_x = vec -> (0);
>> assert_eq!(single_x, (1.0f32));
>>
>> let mut vec = vec;
>> vec <- (0) = 5.0f32; // set x only
>> vec <- (1, 2) = (6.0f32, 7.0f32) // set y & z
>> assert_eq!(vec, (5.0f32, 6.0f32, 7.0f32, 4.0f32));
>>
>> let vec = vec;
>> // the mask may be arbitrarily long:
>> assert_eq!(vec -> (0, 1, 2, 3, 0), (5.0f32, 6.0f32, 7.0f32, 4.0f32,
>> 5.0f32));
>>
>> // leaves vec unchanged
>> let functional_update = vec -> (0, 1, 3) .. (0.5f32, 1.0f32, 10.0f32);
>> // functional_update would take it's type from vec
>> assert_eq!(vec, (5.0f32, 6.0f32, 7.0f32, 4.0f32));
>> assert_eq!(functional_update, (0.5f32, 1.0f32, 7.0f32, 10.0f32));
>>
>> A couple of things would need to be disallowed, however:
>>
>> let mut vec = vec;
>> // no duplicate assignments/functional updates:
>> vec <- (0, 0) = (..);
>> let _ = vec -> (0, 1, 2, 3, 0) .. (..);
>> // no out-of-bounds:
>> vec <- (5, 9000) = (..);
>> let _ = vec -> (5, 9001);
>> let _ = vec -> (5, 9002) .. (..);
>> let _ = vec -> (0, 1, 2, 3, 4) .. (..);
>> // all mask values must be a const expr:
>> let mut non_const_expr = 15;
>> vec <- (non_const_expr) = (..);
>> let _ = vec -> (non_const_expr) .. (..);
>> let _ = vec -> (non_const_expr);
>> // mismatched tuple sizes:
>> vec <- (0, 1) = (0.0f32, 0.0f32, 0.0f32);
>> let _ = vec -> (0) .. (0.0f32, 0.0f32);
>>
>> AIUI, the notation would be:
>> tuple_mask : '(' integer [ ',' integer ] * ')' ;
>> tuple_expr : '(' expr [ ',' expr ] * ')' |
>>                   tuple_expr "->" tuple_mask [ ".." tuple_expr ] ? ;
>>
>> I'm willing to write this myself, but I'd like some consensus/feedback
>> regarding ze proposed sugar.
>>
>> _______________________________________________
>> Rust-dev mailing list
>> Rust-dev at mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
>
>
> --
> by *Liigo*, http://blog.csdn.net/liigo/
> Google+  https://plus.google.com/105597640837742873343/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140117/2abc2547/attachment-0001.html>


More information about the Rust-dev mailing list