## digitalmars.D - Sierra, a SIMD extension for C++

- "bearophile" <bearophileHUGS lycos.com> Mar 04 2014
- "dude" <nothx yahoo.com> Mar 16 2014

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

Mar 04 2014

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--

Mar 16 2014