On 1/13/2012 8:52 PM, Andrei Alexandrescu wrote:
> On 1/13/12 10:03 PM, Walter Bright wrote:
>> On 1/13/2012 7:03 PM, Andrei Alexandrescu wrote:
>>> How is that possibly different from what you have now?
>>
>> Intrinsic functions are today just a table lookup in the compiler.
>
> They're a table lookup if the operation is a compile-time constant. So this
> argument does not apply.
>
>> Template intrinsics currently do not exist, so more code needs to be
>> written for them.
>
> The same table lookup could be done, except in this case it would be more
> principled.

You and I are talking about different things.

The current compiler looks for intrinsics after all template functions are converted into real functions. The mangled name is looked up in a table to see if:

1. it is an intrinsic function

2. what is the corresponding expression node operator

Doing it for intrinsic functions would require either:

1. adding hundreds of function signatures to the table

2. moving the intrinsic detection to the template instantiation logic

On 1/13/2012 3:51 PM, Andrei Alexandrescu wrote:
> On 1/13/12 5:06 PM, Peter Alexander wrote:
>> On 13/01/12 10:31 PM, Andrei Alexandrescu wrote:
>>> On 1/13/12 2:41 PM, Walter Bright wrote:
>>>> On 1/13/2012 12:27 PM, Peter Alexander wrote:
>>>>> On 13/01/12 8:02 PM, Mehrdad wrote:
>>>>>> Er... is there any reason why we're using such a cryptic PXOR value
>>>>>> instead of operator overloading?
>>>>>
>>>>> I imagine Walter will add the operator overloads later.
>>>>
>>>> Right. simd() is just the bottom layer building block. It's a compiler
>>>> intrinsic, and I don't want to make every overload a compiler intrinsic.
>>>
>>> People will want to pass a variable for op. Would that work?
>>
>> Why would people want to do that?
>>
>> Also, no, it can't possibly work. It just makes no sense.
>>
>
> My point exactly. The chosen syntax must be fixed.
>
> Andrei
Still don't understand why we're not doing it with operator overloading instead...

On 1/13/2012 11:30 PM, Mehrdad wrote:
> Still don't understand why we're not doing it with operator overloading instead...

1. will not match the C ABI for vector types

2. will not generate correct vector symbolic debug info

3. will not match vector parameter name mangling

4. cannot do constant folding, or any optimizations which require semantic knowledge of the vector types

5. cannot optimize across inline asm blocks

6. cannot enregister the simd variables


You'll be worse off than using the existing array vector syntax.

On 1/13/2012 11:06 AM, Peter Alexander wrote:
> *** Internal error: backend/cgcod.c 2048 ***
>
> Are all those instructions implemented? I seem to get the same for all
> instructions.

Things have gotten much better with the latest checkin.

On 01/14/2012 12:00 AM, Walter Bright wrote:
> On 1/13/2012 2:36 PM, Andrei Alexandrescu wrote:
>> All names should have a __ prepended, and then the library defines
>> names for
>> them such as vec!(int, 4) that obey module lookup and all. Dumping a
>> wheelbarrow
>> of confusable new keywords doesn't sound right at all.
>
> They're not keywords, they are (literally) simple aliases:
>
> alias Vector!(int[4]) int4;



v4int



>
> As aliases, they obey all scoping and disambiguation rules, which I
> think is superior to using __ prefixes.
>
> You could use Vector!(int[4]) everywhere instead, but I submit it's a
> bit klunky to do that and might as well provide a set of aliases (or
> else people will produce their own aliases and they'll all have
> different spellings).

> void16v
> double2v
> float4v
> byte16v
> ubyte16v
> short8v
> ushort8v
> int4v
> uint4v
> long2v
>
+1

On Fri, 13 Jan 2012 23:08:42 +0200, Manu wrote:

> I think I'd vote for leaving it as it is, swayed by the fact that the more ambiguous types are super-rarely used. float4/int4 has a nice familiarity with HLSL/Cg.

I like the current name scheme, and would like to keep them too.

On 14/01/12 7:30 AM, Mehrdad wrote:
> On 1/13/2012 3:51 PM, Andrei Alexandrescu wrote:
>> On 1/13/12 5:06 PM, Peter Alexander wrote:
>>> On 13/01/12 10:31 PM, Andrei Alexandrescu wrote:
>>>> On 1/13/12 2:41 PM, Walter Bright wrote:
>>>>> On 1/13/2012 12:27 PM, Peter Alexander wrote:
>>>>>> On 13/01/12 8:02 PM, Mehrdad wrote:
>>>>>>> Er... is there any reason why we're using such a cryptic PXOR value
>>>>>>> instead of operator overloading?
>>>>>>
>>>>>> I imagine Walter will add the operator overloads later.
>>>>>
>>>>> Right. simd() is just the bottom layer building block. It's a compiler
>>>>> intrinsic, and I don't want to make every overload a compiler
>>>>> intrinsic.
>>>>
>>>> People will want to pass a variable for op. Would that work?
>>>
>>> Why would people want to do that?
>>>
>>> Also, no, it can't possibly work. It just makes no sense.
>>>
>>
>> My point exactly. The chosen syntax must be fixed.
>>
>> Andrei
> Still don't understand why we're not doing it with operator overloading
> instead...

How do you do a vector shuffle with operator overloading?

On 2012-01-13 20:06, Peter Alexander wrote:
> On 13/01/12 8:39 AM, Walter Bright wrote:
>> https://github.com/D-Programming-Language/d-programming-language.org/blob/master/simd.dd
>>
>>
>>
>> and core.simd:
>>
>> https://github.com/D-Programming-Language/druntime/blob/master/src/core/simd.d
>>
>>
>
> Nice!
>
> Although...
>
> import core.simd;
> void main()
> {
> float4 a = void; // float a; doesn't work either
> a = simd(XMM.PXOR, a);
> }
>
> *** Internal error: backend/cgcod.c 2048 ***
>
> Are all those instructions implemented? I seem to get the same for all
> instructions.
>
> Also, slight bikeshedding issue: I'm not so sure on using names like
> int4 for vectors. You see things like int32 a lot to mean a 32-bit
> integer, or int8 to mean an 8-bit integer. Using this notation for
> vectors may be confusing.

Doesn't some C libraries use these names for fixed size types?

> As for what to change it to, I don't really care. int4v, vec_int4,
> int_vector4, anything. It doesn't matter.



-- 
/Jacob Carlborg

On 14/01/12 8:27 AM, Walter Bright wrote:
> On 1/13/2012 11:06 AM, Peter Alexander wrote:
>> *** Internal error: backend/cgcod.c 2048 ***
>>
>> Are all those instructions implemented? I seem to get the same for all
>> instructions.
>
> Things have gotten much better with the latest checkin.

Ok, just got latest:

float4 a = void; // this works now
float4 b; // this doesn't (backend/cod2.c 2630)

a = simd(XMM.PXOR, a, a); // this doesn't (backend/cgcod.c 2048)
a = simd(XMM.PXOR, a, b); // this works
a = simd(XMM.PXOR, b, a); // this works
b = simd(XMM.PXOR, a, a); // this doesn't (backend/cgcod.c 2048)

Seems to not like it when the two args are the same.

This doesn't work either:

asm { movaps a, b; } // (bad type/size of operands 'movaps')

So, I can load all zeroes into a register using this:

float4 a = void, b = void;
b = a;
a = simd(XMM.PXOR, a, b);

But can't really do anything else.

Also, is there any way to extract the information from a vector type? Using a union, or taking address and casting to float* didn't work. Presumably it isn't writing back into memory appropriately (or has no memory associated).