On 1/6/2012 1:32 PM, Manu wrote:
On 6 January 2012 22:36, Walter Bright <newshou...@digitalmars.com
<mailto:newshou...@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?
For one thing, the compiler has a very hard time optimizing library implemented
types. It's why int, float, etc., are native types. We've come a long way with
library types, but there are limits.
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.
Detecting a "conforming arrangement" is how native types work! Once you wed the
compiler logic to a particular library implementation, it acquires the worst
aspects of a native type with the worst aspects of a library type.
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.
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.