January 13, 2012 Re: start on SIMD documentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Alexander | 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. |
January 13, 2012 Re: start on SIMD documentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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. ?? |
January 13, 2012 Re: start on SIMD documentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Alexander | 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 |
January 13, 2012 Re: start on SIMD documentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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;
|
January 13, 2012 Re: start on SIMD documentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright Attachments:
| 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...
|
January 13, 2012 Re: start on SIMD documentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
January 13, 2012 Re: start on SIMD documentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile Attachments:
| 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.
|
January 13, 2012 Re: start on SIMD documentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Alexander | 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.
|
January 13, 2012 Re: start on SIMD documentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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
|
January 13, 2012 Re: start on SIMD documentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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
|
Copyright © 1999-2021 by the D Language Foundation