On 7 January 2012 01:52, Walter Bright <newshound2@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...