SIMD support...

[Manu]

On 7 January 2012 01:52, Walter Bright <newshound2 at digitalmars.com> wrote:

> On 1/6/2012 1:32 PM, Manu wrote:
>
>> 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?
>>
>
> That's a good point.


.. oh god, what have I done. :/

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.
>>
>
> Support the 10 vector types as basic types, support them with the
> arithmetic infix operators, and use intrinsics for the rest of the
> operations. I believe this scheme:
>
> 1. will look better in code, and will be easier to use
> 2. will allow for better error detection and more comprehensible error
> messages when things are misused
> 3. will generate better code
> 4. shouldn't be hard to implement, as I already did most of the work when
> I did the SIMD support for float and double.
>
>
>  Has it drifted from what you said last night?
>>
>
> Yes.
>

Okay, I'm very worried at this point. Please don't just do this...
There are so many details and gotchas in what you suggest. I couldn't feel
comfortable short of reading a thorough proposal.

Come on IRC? This requires involved conversation.

I'm sure you realise how much more work this is...
Why would you commit to this right off the bat? Why not produce the simple
primitive type, and allow me the opportunity to try it with the libraries
before polluting the language its self with a massive volume of stuff...
I'm genuinely concerned that once you add this to the language, it's done,
and it'll be stuck there like lots of other debatable features... we can
tweak the library implementation as we gain experience with usage of the
feature.

MS also agree that the primitive __m128 is the right approach. I'm not
basing my opinion on their judgement at all, I independently conclude it is
the right approach, but it's encouraging that they agree... and perhaps
they're a more respectable authority than me and my opinion :)

What I proposed in the OP is the simplest, most non-destructive initial
implementation in the language. I think there is the lest opportunity for
making a mistake/wrong decision in my initial proposal, and it can be
extended with what you're suggesting in time after we have the opportunity
to prove that it's correct. We can test and prove the rest with libraries
before committing to implement it in the language...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120107/265b23d9/attachment.html>