SIMD support...

[Walter Bright]

On 1/6/2012 11:41 AM, Manu wrote:
> On 6 January 2012 21:21, Walter Bright <newshound2 at digitalmars.com
> <mailto:newshound2 at digitalmars.com>> wrote:
>
>     On 1/6/2012 5:44 AM, Manu wrote:
>
>         The type safety you're imagining here might actually be annoying when
>         working
>         with the raw type and opcodes..
>         Consider this common situation and the code that will be built around it:
>         __v128 vec = { floatX, floatY, floatZ, unsigned int packedColour ); //
>         pack some
>
>
>     Consider an analogy with the EAX register. It's untyped. But we don't find
>     it convenient to make it untyped in a high level language, we paint the
>     fiction of a type onto it, and that works very well.
>
>
> Damn it, I though we already reached agreement, why are you having second
> thoughts? :)
> Your analogy to EAX is not really valid. EAX may hold some data that is not an
> int, but it is incapable of performing a float operation on that data.
> SIMD registers are capable of performing operations of any type at any time to
> any register, I think this is the key distinction that justifies them as
> inherently 'typeless' registers.

I strongly disagree with this. EAX can (and is) at various times used as byte, 
ubyte, short, ushort, int, uint, pointer, and yes, even floats! Anything that 
fits in it, actually. It is typeless. The types used on them are a fiction 
perpetrated by the language, but a very very useful fiction.


>     To me, the advantage of making the SIMD types typed are:
>
>     1. the language does typechecking, for example, trying to add a vector of 4
>     floats to 16 bytes would be (and should be) an error.
>
>
> The language WILL do that checking as soon as we create the strongly typed
> libraries. And people will use those libraries, they'll never touch the
> primitive type.

I'm not so sure this will work out satisfactorily.


> The primitive type however must not inhibit the programmer from being able to
> perform any operation that the hardware is technically capable of.
> The primitive type will be used behind the scenes for building said libraries...
> nobody will use it in front-end code. It's not really a useful type, it doesn't
> do anything. It just allows the ABI and register semantics to be expressed in
> the language.
>
>     2. Some of the SIMD operations do map nicely onto the operators, so one
>     could write:
>
>        a = b + c + -d;
>
>
> This is not even true, as you said yourself in a previous post.
> SIMD int ops may wrap, or saturate... which is it?

It would only be for those ops that actually do map onto the D operators. (This 
is already done by the library implementation of the array arithmetic 
operations.) The saturated int ops would not be usable this way.


> Don't try and express this at the language level. Let the libraries do it, and
> if they fail, or are revealed to be poorly defined, they can be updated/changed.

Doing it as a library type pretty much prevents certain optimizations, for 
example, the fused operations, from being expressed using infix operators.


>     3. A lot of the SIMD opcodes have 10 variants, one for each of the 10 types.
>     The user would only need to remember the operation, not the variants, and
>     let the usual overloading rules apply.
>
>
> Correct, and they will be hidden behind the api of their strongly typed library
> counterparts. The user will never need to be aware of the opcodes, or their
> variants.
>
>     And, of course, casting would be allowed and would be zero cost.
>
>
> Zero cost? You're suggesting all casts would be reinterprets? Surely: float4
> fVec = (float4)intVec; should perform a type conversion?
> Again, this is detail that can/should be discussed when implementing the
> standard library, leave this sort of problem out of the language.

Painting a new type (i.e. reinterpret casts) do have zero runtime cost to them. 
I don't think it's a real problem - we do it all the time when, for example, we 
want to retype an int as a uint:

    int i;
    uint u = cast(uint)i;


> Your earlier email detailing your simple API with an enum of opcodes sounded
> fine... whatever's easiest really. The hard part will be implementing the
> alignment, and the literal syntax.