On 6 January 2012 21:21, Walter Bright <newshound2@digitalmars.com> wrote:
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
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.
Damn it, I though we already reached agreement, why are you having second thoughts? :)
Your analogy to EAX is not really valid. EAX may hold some data that is not an int, but it is incapable of performing a float operation on that data.
SIMD registers are capable of performing operations of any type at any time to any register, I think this is the key distinction that justifies them as inherently 'typeless' registers.
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.
The primitive type however must not inhibit the programmer from being able to perform any operation that the hardware is technically capable of.
The primitive type will be used behind the scenes for building said libraries... nobody will use it in front-end code. It's not really a useful type, it doesn't do anything. It just allows the ABI and register semantics to be expressed in the language.
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?
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.
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.
Correct, and they will be hidden behind the api of their strongly typed library counterparts. The user will never need to be aware of the opcodes, or their variants.
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.
Your earlier email detailing your simple API with an enum of opcodes sounded fine... whatever's easiest really. The hard part will be implementing the alignment, and the literal syntax.