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

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.

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

On 13/01/12 7:06 PM, 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.
>
> As for what to change it to, I don't really care. int4v, vec_int4,
> int_vector4, anything. It doesn't matter.
>

Sorry, the code was meant to be:

import core.simd;
void main()
{
    float4 a = void;
    a = simd(XMM.PXOR, a, a);
}

The error was for this code.

Peter Alexander:

> 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.
> 
> As for what to change it to, I don't really care. int4v, vec_int4, int_vector4, anything. It doesn't matter.

It's not confusing for D programmers. But if you want to be on the safe side then int4v or vint4 sound acceptable.

Bye,
bearophile

On 13 January 2012 19:06, Peter Alexander <peter.alexander.au@gmail.com> 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.
>
> As for what to change it to, I don't really care. int4v, vec_int4, int_vector4, anything. It doesn't matter.
>

This is probably intelligable, but makes sense to me.

Change   int4  ->  v4si

Vector names that reflect the MODE they represent, rather than the TYPE.


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 13 January 2012 19:18, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> On 13 January 2012 19:06, Peter Alexander <peter.alexander.au@gmail.com> 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.
>>
>> As for what to change it to, I don't really care. int4v, vec_int4, int_vector4, anything. It doesn't matter.
>>
>
> This is probably intelligable, but makes sense to me.
>
> Change   int4  ->  v4si
>
> Vector names that reflect the MODE they represent, rather than the TYPE.
>

Unintelligible, even...


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 13 January 2012 21:06, Peter Alexander <peter.alexander.au@gmail.com>wrote:

> 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.
>

I had the same feeling.
short8 really made me instanytly uncomfortable. I'm so used to seeing a
number on the end of a trivial type as being the width in bits. Even though
I knew exactly what I was looking at, I still unconsciously assumed this
was an 8bit type...

It makes perfect sense for float4, since it's completely absurd to imagine
a 4bit float, and it's also conventional from Cg and HLSL.
I wonder if there's a nice naming convention to mitigate this problem?
Perhaps vshort8? Or some other small prefix/suffix?

On 1/13/2012 11:06 AM, 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);
> }

Er... is there any reason why we're using such a cryptic PXOR value instead of operator overloading?

On 13/01/12 8:02 PM, Mehrdad wrote:
> On 1/13/2012 11:06 AM, 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);
>> }
>
> 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.

The simd(op, ...) syntax is more flexible though because it allows you to select instructions that don't directly map to any standard operator (e.g. shuffles).

On 13/01/12 7:49 PM, Manu wrote:
> On 13 January 2012 21:06, Peter Alexander <peter.alexander.au@gmail.com
> <mailto:peter.alexander.au@gmail.com>> wrote:
>
>     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.
>
>
> I had the same feeling.
> short8 really made me instanytly uncomfortable. I'm so used to seeing a
> number on the end of a trivial type as being the width in bits. Even
> though I knew exactly what I was looking at, I still unconsciously
> assumed this was an 8bit type...
>
> It makes perfect sense for float4, since it's completely absurd to
> imagine a 4bit float, and it's also conventional from Cg and HLSL.
> I wonder if there's a nice naming convention to mitigate this problem?
> Perhaps vshort8? Or some other small prefix/suffix?

Honestly, I be happy with any name as long as it was unambiguous.

vshort8
short8v
short8_v
vec_short8
vec8_short
short_vec8
short_v8
...

Anything will do. Just stick a v, vec, or vector somewhere and I'll be happy.