• bearophile (95/96) Mar 04 2014 An interesting paper:
• dude (2/12) Mar 16 2014 I like this paper, wonder if it has any chance of being

"bearophile" <bearophileHUGS lycos.com> writes:

An interesting paper:
http://www.cdl.uni-saarland.de/papers/lhh14.pdf


Recently Andrei in a post has written that in D "we have an 
almost working X, an almost working Y, etc". Thinking more about 
this I agree that while implementing the simplest possible idea 
has large engineering advantages (and I have learnt a lot from 
this part of the D design by Walter), it's also true that 
sometimes it's important to design the last 10% of a feature too 
(and usually this last 10% requires one or two times more 
thinking than the precedent 90% and sometimes it adds twice the 
complexity). That's why I think it's important to have the 
pre-state ("old") in D contract programming, to support well 
comparison operators in D SIMD and D vector ops, to have means to 
attach compile-time semantics to UDAs that the compile enforces, 
to have a bit more refined built-in unittests with names too, to 
have a more complete design for shared, etc.

This paper shows a simple looking SIMD syntax and semantics for 
C++ that could be useful to complete the design of the D SIMD.

Some superficial syntax:

int varying (4) a = {0, 1, 2, 3};
int varying (4) b = {2, 4, 8, 10};
int varying (4) c = a + b; // 2, 5, 10 , 13

--------------

int varying(4) v = {0, 8, 7, 1};
if (v < 3) v += 2;
else v -= 3;

Now v contains [2, 5, 4, 3].

--------------

short varying (4) s;
int varying (4) i;
s + i; // s is converted to int varying (4)

--------------

// standard C pointer
int uniform * uniform a;
// vectorial pointer to scalar int
int uniform * varying (4) b;
// scalar pointer to vectorial int
int varying (4)* uniform c;
// vectorial pointer to vectorial int
int varying (4)* varying (4) d;

--------------

Template parametrized on the SIMD vector length:

template <int L>
struct Vec3 {
     simd (L) Vec3(float varying (L)xx,
                   float varying (L)yy,
                   float varying (L)zz)
       :x(xx),y(yy),z(zz){}

     simd (L)Vec3<L>operator+(Vec3<L>v) {
         Vec3<L>result;
         result.x = x + v.x;
         result.y = y + v.y;
         result.z = z + v.z;
         return result;
     }

     float varying (L)x,y,z;
};

--------------

The section 3.2, is about "SIMD Mode", this type system semantics 
is missing in D and perhaps it is worth thinking about (and later 
adding):

<<
If a control-flow-dependent expression is a vector of length L 
instead of a scalar, Sierra enters a special mode: the SIMD mode. 
All parts of the program depending on that expression are 
evaluated in that mode. At runtime each program point must know 
which lanes are active. Therefore, Sierra maintains a value of 
type bool varying(L) which we call current mask. The programmer 
has read access to this value via the current_mask keyword. We 
call L the current vector length. As vector lengths must be 
specified at compile time, the current vector length is 
statically known. Sierra’s semantic analysis keeps track of this 
information. If this length is 1, we say the program is in scalar 
mode. Usual C++ semantics apply in scalar mode.<

The following statements will trigger SIMD mode of length L for S 
if Ev is a vector of length L:

if (Ev) S [else S]
   - switch (Ev) S
   - for (Si; Ev; E) S
   - while (Ev) S
   - do S while (Ev);

Additionally, short-circuit evaluation might trigger SIMD mode of 
length L for E if Ev is a vector of length L:
- Ev && E and E && Ev
- Ev || E and E || Ev
- Ev ? E : E

If the type of Ev is a vector of length L, the program must 
either be in scalar mode or in SIMD mode of length L. Nesting of 
SIMD modes with different vector lengths is forbidden. However, 
scalar control flow is always allowed. In SIMD mode, Sierra 
vectorizes control flow. The statements break, continue, case and 
return can be used in SIMD mode. But currently, Sierra does 
neither allow goto nor labels in SIMD mode.


Bye,
bearophile

"dude" <nothx yahoo.com> writes:

 If the type of Ev is a vector of length L, the program must 
 either be in scalar mode or in SIMD mode of length L. Nesting 
 of SIMD modes with different vector lengths is forbidden. 
 However, scalar control flow is always allowed. In SIMD mode, 
 Sierra vectorizes control flow. The statements break, continue, 
 case and return can be used in SIMD mode. But currently, Sierra 
 does neither allow goto nor labels in SIMD mode.


 Bye,
 bearophile

  I like this paper, wonder if it has any chance of being 
standardized. If not specifically this, then something similar--