SIMD support...

[Walter Bright]

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
> other useful data in W
> If vec were strongly typed, I would now need to start casting all over the place
> to use various float and uint opcodes on this value?
> I think it's correct when using SIMD at the raw level to express the type as it
> is, typeless... SIMD regs are infact typeless regs, they only gain concept of
> type the moment you perform an opcode on it, and only for the duration of that
> opcode.
>
> You will get your strong type safety when you make use of the float4 types which
> will be created in the libs.

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.

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.

2. Some of the SIMD operations do map nicely onto the operators, so one could write:

    a = b + c + -d;

and the correct SIMD opcodes will be generated based on the types. I think that 
would be one hell of a lot nicer than using function syntax. Of course, this 
will only be for those SIMD ops that do map, for the rest you're stuck with the 
functions.

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.


And, of course, casting would be allowed and would be zero cost.

I've been thinking about this a lot since last night, and I think that since the 
back end already supports XMM registers, most of the hard work is done, that 
doing it this way would fit in well. (At least for 64 bit code, where the 
alignment issue is solved, but that's an orthogonal issue.)