SIMD support...

[Manu]

On 6 January 2012 22:36, Walter Bright <newshound2 at digitalmars.com> wrote:

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

How so, can you support this theory?


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


But why are you against adding this stuff in the library? It's contrary to
the general sentiment around here where people like putting stuff in
libraries where possible. It's less committing, and allows alternative
implementations if desired.

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

You're talking about MADD? I was going to make a separate suggestion
regarding that actually.
Multiply-add is a common concept, often available to FPU's aswell (and no
way to express it)... I was going to suggest an opMultiplyAdd() operator,
which you could have the language call if it detects a conforming
arrangement of * and + operators on a type. This would allow operator
access to madd in library vectors too.

   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;


Yeah sure, but I don't think that's fundamentally correct, if you're
drifting towards typing these things in the language, then you should also
start considering cast mechanics... and that's a larger topic of debate.
I don't really think "float4 floatVec = (float4)intVec;" should be a
reinterpret... surely, as a high level type, this should perform a type
conversion?

I'm afraid this is become a lot more complicated than it needs to be.
Can you illustrate your current thoughts/plan, to have it summarised in one
place. Has it drifted from what you said last night?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120106/4e1d76b2/attachment-0001.html>