On 1/13/2012 11:06 AM, Peter Alexander wrote:
> 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.

The instructions are implemented, it's the initialization that isn't and is failing.


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

If int4 is out, I'd prefer something like vint4. Something short.

On 1/13/2012 11:18 AM, Iain Buclaw wrote:
> This is probably intelligable, but makes sense to me.
>
> Change   int4  ->   v4si

please, no!

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

??

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.


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

What's our vector, Victor?

http://www.youtube.com/watch?v=fVq4_HhBK8Y

On 13/01/12 8:37 PM, Walter Bright wrote:
> On 1/13/2012 11:06 AM, Peter Alexander wrote:
>> 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.
>
> The instructions are implemented, it's the initialization that isn't and
> is failing.

Oh ok.

So is there any way to use them at the moment? None of these work:

float4 a = void;
float4 b;
float4 c = [.0f, .0f, .0f, .0f];
float[4] v = [.0f, .0f, .0f, .0f];
float4 d = v;

On 13 January 2012 22:37, Walter Bright <newshound2@digitalmars.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.
>>
>> As for what to change it to, I don't really care. int4v, vec_int4,
>> int_vector4,
>> anything. It doesn't matter.
>>
>
> If int4 is out, I'd prefer something like vint4. Something short.
>

It's a hard call. I like float4/int4, and like the similarity to Cg/HLSL
personally. And these are the types that will be used 99% of the time.
short8 is very rare by comparison... I'm quite apprehensive about making a
compromise for the significantly less frequently used type.
That said, it did make me a little uncomfortable the moment I read it...

Walter:

> What's our vector, Victor? http://www.youtube.com/watch?v=fVq4_HhBK8Y

Thank you Walter :-)


> If int4 is out, I'd prefer something like vint4. Something short.

Current names:

void16
double2
float4
byte16
ubyte16
short8
ushort8
int4
uint4
long2

Your suggestion:

vvoid16
vdouble2
vfloat4
vbyte16
vubyte16
vshort8
vushort8
vint4
vuint4
vlong2


My suggestion:

void16v
double2v
float4v
byte16v
ubyte16v
short8v
ushort8v
int4v
uint4v
long2v

Bye,
bearophile

On 13 January 2012 22:57, bearophile <bearophileHUGS@lycos.com> wrote:

> Walter:
>
> > What's our vector, Victor? http://www.youtube.com/watch?v=fVq4_HhBK8Y
>
> Thank you Walter :-)
>
>
> > If int4 is out, I'd prefer something like vint4. Something short.
>
> Current names:
>
> void16
> double2
> float4
> byte16
> ubyte16
> short8
> ushort8
> int4
> uint4
> long2
>
> Your suggestion:
>
> vvoid16
> vdouble2
> vfloat4
> vbyte16
> vubyte16
> vshort8
> vushort8
> vint4
> vuint4
> vlong2
>
>
> My suggestion:
>
> void16v
> double2v
> float4v
> byte16v
> ubyte16v
> short8v
> ushort8v
> int4v
> uint4v
> long2v
>
> Bye,
> bearophile
>

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.

On 1/13/2012 12:59 PM, Peter Alexander wrote:
> So is there any way to use them at the moment?

Not unless you want to use inline asm to initialize them :-)

I wouldn't bother, though, I hope to get initializing working shortly.

On 1/13/12 2:37 PM, Walter Bright wrote:
> If int4 is out, I'd prefer something like vint4. Something short.

Something short must compensate its potential for confusion with frequent usage and well-established convention. Arguably neither applies here.

Andrei

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?

Andrei