www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - start on SIMD documentation

reply Walter Bright <newshound2 digitalmars.com> writes:
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
Jan 13 2012
next sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
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.
Jan 13 2012
next sibling parent Peter Alexander <peter.alexander.au gmail.com> writes:
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.
Jan 13 2012
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
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
Jan 13 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
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> =

 On 13/01/12 8:39 AM, Walter Bright wrote:
 https://github.com/D-Programming-Language/d-programming-language.org/bl=



 and core.simd:


 https://github.com/D-Programming-Language/druntime/blob/master/src/core=




Nice! Although... import core.simd; void main() { =A0 =A0float4 a =3D void; // float a; doesn't work either =A0 =A0a =3D 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 int=


 for vectors. You see things like int32 a lot to mean a 32-bit integer, o=


 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 =A0 int4 =A0-> =A0v4si Vector names that reflect the MODE they represent, rather than the TYPE.

Unintelligible, even... --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Jan 13 2012
prev sibling next sibling parent reply Mehrdad <wfunction hotmail.com> writes:
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?
Jan 13 2012
parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
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).
Jan 13 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
Jan 13 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 13 2012
next sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
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.
Jan 13 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 13 2012
parent reply Mehrdad <wfunction hotmail.com> writes:
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

instead...
Jan 13 2012
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 14 2012
prev sibling parent Peter Alexander <peter.alexander.au gmail.com> writes:
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

instead...

How do you do a vector shuffle with operator overloading?
Jan 14 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/13/2012 2:31 PM, Andrei Alexandrescu wrote:
 People will want to pass a variable for op. Would that work?

It'll currently fail miserably - it has to be a constant. Otherwise, we have runtime code generation. While not impossible, it is a large increase in scope.
Jan 13 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/13/12 4:57 PM, Walter Bright wrote:
 On 1/13/2012 2:31 PM, Andrei Alexandrescu wrote:
 People will want to pass a variable for op. Would that work?

It'll currently fail miserably - it has to be a constant. Otherwise, we have runtime code generation. While not impossible, it is a large increase in scope.

Then probably the operation should be simd!opcode(arguments). If a function is intrinsic it shouldn't have special syntactic rights. Andrei
Jan 13 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/13/2012 3:51 PM, Andrei Alexandrescu wrote:
 On 1/13/12 4:57 PM, Walter Bright wrote:
 On 1/13/2012 2:31 PM, Andrei Alexandrescu wrote:
 People will want to pass a variable for op. Would that work?

It'll currently fail miserably - it has to be a constant. Otherwise, we have runtime code generation. While not impossible, it is a large increase in scope.

Then probably the operation should be simd!opcode(arguments). If a function is intrinsic it shouldn't have special syntactic rights.

You're right, I'm just not too thrilled about generating hundreds of template instantiations.
Jan 13 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/13/12 7:42 PM, Walter Bright wrote:
 On 1/13/2012 3:51 PM, Andrei Alexandrescu wrote:
 On 1/13/12 4:57 PM, Walter Bright wrote:
 On 1/13/2012 2:31 PM, Andrei Alexandrescu wrote:
 People will want to pass a variable for op. Would that work?

It'll currently fail miserably - it has to be a constant. Otherwise, we have runtime code generation. While not impossible, it is a large increase in scope.

Then probably the operation should be simd!opcode(arguments). If a function is intrinsic it shouldn't have special syntactic rights.

You're right, I'm just not too thrilled about generating hundreds of template instantiations.

How is that possibly different from what you have now? Andrei
Jan 13 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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. Template intrinsics currently do not exist, so more code needs to be written for them.
Jan 13 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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. Andrei
Jan 13 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
Jan 13 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/13/12 11:02 PM, Walter Bright wrote:
 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.

No. Please hear me out.
 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

So this is an implementation issue that has nothing to do with doing the right thing. That's no reason to do the wrong thing. The real problem with the current approach is as follows. Defining an intrinsic function is cheating. It means the language's facilities are unable to expose computation to the compiler in a manner that makes it able to translate it to efficient code. This in turn points to problems in either the language or the compiler technology. To a good extent these are known issues of the state of the art. There are advantages to e.g. making integers intrinsic types and imbuing the compiler with understanding of basic arithmetic identities. Or it makes sense to define integral rotation as an intrinsic function (or devise a peephole optimization that detects the pattern) because it's one assembler operation deriving from a rather involved algorithm. So intrinsics are a necessary evil. On to your implementation of simd, which is simd(opcode, op1, op2) This is a lie - it's cheating twice. The expression looks like a function but does not feel like a function. The first argument, the opcode, is NOT a function parameter. It's part of the function. Passing a variable in there does not work as a matter of design - the generated code depends on that so opcode must be known during compilation. So what do we have to integrate the cheating operation within the current language semantics? I can think of two. First, make the operand part of the function name: simdOPCODE(op1, op2) This is reasonable because it acknowledges what really happens - each function has its identity and its generated code. The second, spaceship-era approach (and closer to the current implementation) is to make the first argument a template parameter. This is because template parameters must be known during compilation, which is exactly opcode's requirement: simd!opcode(op1, op2) Either approach should work perfectly fine; it "cheats in style" by using an existing language construct that exactly matches the special-cased capability. The current approach cheats badly - it messes with the language's fabric by defining a construct that's not a function but looks like one. I'd be in your debt if you could at least do the right thing when defining new intrinsics. Thanks, Andrei
Jan 16 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/16/2012 8:38 AM, Andrei Alexandrescu wrote:
 Either approach should work perfectly fine; it "cheats in style" by using an
 existing language construct that exactly matches the special-cased capability.
 The current approach cheats badly - it messes with the language's fabric by
 defining a construct that's not a function but looks like one.

You're right, it is cheating.
 I'd be in your debt if you could at least do the right thing when defining new
 intrinsics.

We can talk about that some more. At some point, there's going to have to be some compiler magic going on.
Jan 16 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/16/12 1:32 PM, Walter Bright wrote:
 On 1/16/2012 8:38 AM, Andrei Alexandrescu wrote:
 Either approach should work perfectly fine; it "cheats in style" by
 using an
 existing language construct that exactly matches the special-cased
 capability.
 The current approach cheats badly - it messes with the language's
 fabric by
 defining a construct that's not a function but looks like one.

You're right, it is cheating.
 I'd be in your debt if you could at least do the right thing when
 defining new
 intrinsics.

We can talk about that some more. At some point, there's going to have to be some compiler magic going on.

OK. The overarching point is that the magic should be virtually indistinguishable from using the regular constructs. It's an optimization, and just like with any other optimization, you don't expect it to change the meaning of a construct. Andrei
Jan 16 2012
prev sibling next sibling parent Peter Alexander <peter.alexander.au gmail.com> writes:
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.
Jan 13 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 13 2012
next sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
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;
Jan 13 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 13 2012
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Jan 13 2012
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/13/12 3:08 PM, Manu wrote:
 On 13 January 2012 22:57, bearophile <bearophileHUGS lycos.com
 <mailto: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.

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. Andrei
Jan 13 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/13/2012 11:36 PM, Andrei Alexandrescu wrote:
 On 1/13/12 3:08 PM, Manu wrote:
 On 13 January 2012 22:57, bearophile <bearophileHUGS lycos.com
 <mailto: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.

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

All of those are library types defined in core.simd. For example, float4 is declared as alias Vector!(float[4]) float4 And Vector simply hides what is built-in. template Vector(T){ alias __vector(T) Vector; } I think this is a very clean design.
Jan 13 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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; 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).
Jan 13 2012
parent sclytrack <sclytrack fake.com> writes:
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).

Jan 14 2012
prev sibling parent reply Sean Cavanaugh <WorksOnMyMachine gmail.com> writes:
What about the 256 bit types that are already present in AVX instruction 
set?

I've written a several C++ based SIMD math libraries (for SSE2 up 
through AVX), and PPC's VMX instruction sets that you can find on game 
consoles.

The variable type naming is probably the most annoying thing to work out.

For HLSL they use float, float1, float2, float3, float4 and int, uint 
and double versions, and this convention works out quite well until you 
start having to deal with smaller integer types or FP16 half floats.

However on the CPU side of things there are signed and unsigned 8, 16, 
32, 64 and 128 bit values.  It gets even more complicated in that not 
all the math operations or comparisons are supported on the non-32 bit 
types.  The hardware is really designed for you to pack and unpack the 
smaller types to 32 bit do the work and pack the results back, and the 
64 bit integer support is also a bit spotty (esp wrt multiply and divide).

On 1/13/2012 2:57 PM, bearophile 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

Jan 14 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/14/2012 9:15 PM, Sean Cavanaugh wrote:
 What about the 256 bit types that are already present in AVX instruction set?

Eventually, I'd like to do them, too.
 I've written a several C++ based SIMD math libraries (for SSE2 up through AVX),
 and PPC's VMX instruction sets that you can find on game consoles.

 The variable type naming is probably the most annoying thing to work out.

 For HLSL they use float, float1, float2, float3, float4 and int, uint and
double
 versions, and this convention works out quite well until you start having to
 deal with smaller integer types or FP16 half floats.

 However on the CPU side of things there are signed and unsigned 8, 16, 32, 64
 and 128 bit values.

I'm not sure why the convention used in std.simd fails here.
 It gets even more complicated in that not all the math
 operations or comparisons are supported on the non-32 bit types.

Right. D is designed to give an error for operations that are not supported, rather than downgrade to emulation like gcc does.
Jan 14 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/14/2012 9:52 PM, Martin Nowak wrote:
 On Sun, 15 Jan 2012 06:21:22 +0100, Walter Bright <newshound2 digitalmars.com>
 wrote:

 On 1/14/2012 9:15 PM, Sean Cavanaugh wrote:
 What about the 256 bit types that are already present in AVX instruction set?

Eventually, I'd like to do them, too.

https://github.com/dawgfoto/dmd/commits/AVXSupport

Nice, how about a pull request?
Jan 14 2012
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 13 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/13/2012 11:29 PM, Andrei Alexandrescu wrote:
 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

Both apply. Frequent usage: Under the precondition that core.simd is imported, of course. Well-Established convention: See GLSL/HLSL/OpenCL/...
Jan 13 2012
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.

??
Jan 13 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf3074b440cf03bb04b66f0772
Content-Type: text/plain; charset=UTF-8

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... --20cf3074b440cf03bb04b66f0772 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 13 January 2012 22:37, Walter Bright <span di= r=3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com">newshound2 digi= talmars.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl= e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex"><br>Also, slight bikeshedd= ing issue: I&#39;m not so sure on using names like int4 for<br> vectors. You see things like int32 a lot to mean a 32-bit integer, or int8 = to<br> mean an 8-bit integer. Using this notation for vectors may be confusing.<br=

As for what to change it to, I don&#39;t really care. int4v, vec_int4, int_= vector4,<br> anything. It doesn&#39;t matter.<br> </blockquote> <br></div> If int4 is out, I&#39;d prefer something like vint4. Something short.<br></= blockquote><div><br></div><div>It&#39;s a hard call. I like float4/int4, an= d like the similarity to Cg/HLSL personally. And these are the types that w= ill be used 99% of the time.</div> <div>short8 is very rare by comparison... I&#39;m quite apprehensive about = making a compromise for the significantly less frequently used type.</div><= div>That said, it did make me a little uncomfortable the moment I read it..= .</div> </div> --20cf3074b440cf03bb04b66f0772--
Jan 13 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf3074b44002095a04b66f45b3
Content-Type: text/plain; charset=UTF-8

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. --20cf3074b44002095a04b66f45b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 13 January 2012 22:57, bearophile <span dir= =3D"ltr">&lt;<a href=3D"mailto:bearophileHUGS lycos.com">bearophileHUGS lyc= os.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"= margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Walter:<br> <div class=3D"im"><br> &gt; What&#39;s our vector, Victor?<br> &gt; <a href=3D"http://www.youtube.com/watch?v=3DfVq4_HhBK8Y" target=3D"_bl= ank">http://www.youtube.com/watch?v=3DfVq4_HhBK8Y</a><br> <br> </div>Thank you Walter :-)<br> <div class=3D"im"><br> <br> &gt; If int4 is out, I&#39;d prefer something like vint4. Something short.<= br> <br> </div>Current names:<br> <br> void16<br> double2<br> float4<br> byte16<br> ubyte16<br> short8<br> ushort8<br> int4<br> uint4<br> long2<br> <br> Your suggestion:<br> <br> vvoid16<br> vdouble2<br> vfloat4<br> vbyte16<br> vubyte16<br> vshort8<br> vushort8<br> vint4<br> vuint4<br> vlong2<br> <br> <br> My suggestion:<br> <br> void16v<br> double2v<br> float4v<br> byte16v<br> ubyte16v<br> short8v<br> ushort8v<br> int4v<br> uint4v<br> long2v<br> <br> Bye,<br> <span class=3D"HOEnZb"><font color=3D"#888888">bearophile<br> </font></span></blockquote></div><br><div>I think I&#39;d vote for leaving = it as it is, swayed by the fact that the more ambiguous types are super-rar= ely used. float4/int4 has a nice familiarity with HLSL/Cg.</div> --20cf3074b44002095a04b66f45b3--
Jan 13 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--002354470e0ce5920e04b6708393
Content-Type: text/plain; charset=UTF-8

On 14 January 2012 00:31, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org
 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?

...I really don't think they will. and most people would never dive this deep if the standard lib does its job properly. --002354470e0ce5920e04b6708393 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 14 January 2012 00:31, Andrei Alexandrescu <s= pan dir=3D"ltr">&lt;<a href=3D"mailto:SeeWebsiteForEmail erdani.org">SeeWeb= siteForEmail erdani.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail= _quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:= 1ex"> <div class=3D"im">On 1/13/12 2:41 PM, Walter Bright wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 1/13/2012 12:27 PM, Peter Alexander wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 13/01/12 8:02 PM, Mehrdad wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Er... is there any reason why we&#39;re using such a cryptic PXOR value<br> instead of operator overloading?<br> </blockquote> <br> I imagine Walter will add the operator overloads later.<br> </blockquote> <br> Right. simd() is just the bottom layer building block. It&#39;s a compiler<= br> intrinsic, and I don&#39;t want to make every overload a compiler intrinsic= .<br> </blockquote> <br></div> People will want to pass a variable for op. Would that work?</blockquote><d= iv><br></div><div>...I really don&#39;t think they will.</div><div>and most= people would never dive this deep if the standard lib does its job properl= y.</div> </div> --002354470e0ce5920e04b6708393--
Jan 13 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf3005dee25eec9b04b670c182
Content-Type: text/plain; charset=UTF-8

On 14 January 2012 00:36, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org
 wrote:

 On 1/13/12 3:08 PM, Manu wrote:

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

    Walter:

     > What's our vector, Victor?
     > http://www.youtube.com/watch?**v=fVq4_HhBK8Y<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.

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.

These ARE the library defined types we're talking about, defined in simd.d --20cf3005dee25eec9b04b670c182 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 14 January 2012 00:36, Andrei Alexandrescu <s= pan dir=3D"ltr">&lt;<a href=3D"mailto:SeeWebsiteForEmail erdani.org">SeeWeb= siteForEmail erdani.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail= _quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:= 1ex"> <div class=3D"im">On 1/13/12 3:08 PM, Manu wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> On 13 January 2012 22:57, bearophile &lt;<a href=3D"mailto:bearophileHUGS l= ycos.com" target=3D"_blank">bearophileHUGS lycos.com</a><br></div><div><div= class=3D"h5"> &lt;mailto:<a href=3D"mailto:bearophileHUGS lycos.com" target=3D"_blank">be= arophileHUGS lycos.<u></u>com</a>&gt;&gt; wrote:<br> <br> =C2=A0 =C2=A0Walter:<br> <br> =C2=A0 =C2=A0 &gt; What&#39;s our vector, Victor?<br> =C2=A0 =C2=A0 &gt; <a href=3D"http://www.youtube.com/watch?v=3DfVq4_HhBK8Y= " target=3D"_blank">http://www.youtube.com/watch?<u></u>v=3DfVq4_HhBK8Y</a>= <br> <br> =C2=A0 =C2=A0Thank you Walter :-)<br> <br> <br> =C2=A0 =C2=A0 &gt; If int4 is out, I&#39;d prefer something like vint4. So= mething short.<br> <br> =C2=A0 =C2=A0Current names:<br> <br> =C2=A0 =C2=A0void16<br> =C2=A0 =C2=A0double2<br> =C2=A0 =C2=A0float4<br> =C2=A0 =C2=A0byte16<br> =C2=A0 =C2=A0ubyte16<br> =C2=A0 =C2=A0short8<br> =C2=A0 =C2=A0ushort8<br> =C2=A0 =C2=A0int4<br> =C2=A0 =C2=A0uint4<br> =C2=A0 =C2=A0long2<br> <br> =C2=A0 =C2=A0Your suggestion:<br> <br> =C2=A0 =C2=A0vvoid16<br> =C2=A0 =C2=A0vdouble2<br> =C2=A0 =C2=A0vfloat4<br> =C2=A0 =C2=A0vbyte16<br> =C2=A0 =C2=A0vubyte16<br> =C2=A0 =C2=A0vshort8<br> =C2=A0 =C2=A0vushort8<br> =C2=A0 =C2=A0vint4<br> =C2=A0 =C2=A0vuint4<br> =C2=A0 =C2=A0vlong2<br> <br> <br> =C2=A0 =C2=A0My suggestion:<br> <br> =C2=A0 =C2=A0void16v<br> =C2=A0 =C2=A0double2v<br> =C2=A0 =C2=A0float4v<br> =C2=A0 =C2=A0byte16v<br> =C2=A0 =C2=A0ubyte16v<br> =C2=A0 =C2=A0short8v<br> =C2=A0 =C2=A0ushort8v<br> =C2=A0 =C2=A0int4v<br> =C2=A0 =C2=A0uint4v<br> =C2=A0 =C2=A0long2v<br> <br> =C2=A0 =C2=A0Bye,<br> =C2=A0 =C2=A0bearophile<br> <br> <br></div></div><div class=3D"im"> I think I&#39;d vote for leaving it as it is, swayed by the fact that the<b= r> more ambiguous types are super-rarely used. float4/int4 has a nice<br> familiarity with HLSL/Cg.<br> </div></blockquote> <br> All names should have a __ prepended, and then the library defines names fo= r them such as vec!(int, 4) that obey module lookup and all. Dumping a whee= lbarrow of confusable new keywords doesn&#39;t sound right at all.</blockqu= ote> <div><br></div><div>These ARE the library defined types we&#39;re talking a= bout, defined in simd.d</div></div> --20cf3005dee25eec9b04b670c182--
Jan 13 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/13/2012 11:06 AM, Peter Alexander 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.

Consider also that the int8 is an alias, not a keyword. This means that the compiler will inform you of any ambiguities, as well as allow: core.simd.int8 to disambiguate.
Jan 13 2012
parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 13/01/12 10:55 PM, Walter Bright wrote:
 On 1/13/2012 11:06 AM, Peter Alexander 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.

Consider also that the int8 is an alias, not a keyword. This means that the compiler will inform you of any ambiguities, as well as allow: core.simd.int8 to disambiguate.

I realize that. It's just that I mentally associate the identifier int8 with an 8-bit integer as it is something I regularly see in C++ code. However, I'm willing to drop my position. After a quick Google, I discovered that it's not as common as I thought. I'm happy to keep float4 etc. since it is simple and is already used in a couple of shader languages.
Jan 13 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/13/2012 3:15 PM, Peter Alexander wrote:
 I realize that. It's just that I mentally associate the identifier int8 with an
 8-bit integer as it is something I regularly see in C++ code.

 However, I'm willing to drop my position. After a quick Google, I discovered
 that it's not as common as I thought. I'm happy to keep float4 etc. since it is
 simple and is already used in a couple of shader languages.

I know you agree with me but I'm not done arguing :-) Making an int8 type in D would be execrable style, as 'byte' is (unlike in C) *defined* to be an 8 bit signed integer.
Jan 13 2012
prev sibling next sibling parent "F i L" <witte2008 gmail.com> writes:
Dope! Great starting place.

I think the syntax is great as-is. 'short' means a 16 bit integer 
type, so I don't see why short8 would conflict anywhere (in D). 
Plus, like Manu pointed out, float4/int4 is really what'll be 
most used and is identical to HLSL.

...to bad size_t wasn't intz like in Crack... ;-P
Jan 13 2012
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Fri, 13 Jan 2012 13:06:28 -0600, Peter Alexander
<peter.alexander.au gmail.com> wrote:
 On 13/01/12 8:39 AM, Walter Bright 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.

Well, in my experience (graphics/GPU), float4 is the standard nomenclature.
Jan 13 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--0016e6dedde649e19904b67327e9
Content-Type: text/plain; charset=UTF-8

On 14 January 2012 03:42, Walter Bright <newshound2 digitalmars.com> wrote:

 On 1/13/2012 3:51 PM, Andrei Alexandrescu wrote:

 On 1/13/12 4:57 PM, Walter Bright wrote:

 On 1/13/2012 2:31 PM, Andrei Alexandrescu wrote:

 People will want to pass a variable for op. Would that work?

It'll currently fail miserably - it has to be a constant. Otherwise, we have runtime code generation. While not impossible, it is a large increase in scope.

Then probably the operation should be simd!opcode(arguments). If a function is intrinsic it shouldn't have special syntactic rights.

You're right, I'm just not too thrilled about generating hundreds of template instantiations.

Is that expensive somehow? Surely they all just boil down to a call to the intrinsic anyway? --0016e6dedde649e19904b67327e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 14 January 2012 03:42, Walter Bright <span di= r=3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com">newshound2 digi= talmars.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl= e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On 1/13/2012 3:51 PM, Andrei Alexan= drescu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 1/13/12 4:57 PM, Walter Bright wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 1/13/2012 2:31 PM, Andrei Alexandrescu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> People will want to pass a variable for op. Would that work?<br> </blockquote> <br> It&#39;ll currently fail miserably - it has to be a constant. Otherwise, we= <br> have runtime code generation. While not impossible, it is a large<br> increase in scope.<br> </blockquote> <br> Then probably the operation should be simd!opcode(arguments). If a function= is<br> intrinsic it shouldn&#39;t have special syntactic rights.<br> </blockquote> <br></div></div> You&#39;re right, I&#39;m just not too thrilled about generating hundreds o= f template instantiations.<br> </blockquote></div><br><div>Is that expensive somehow?<br>Surely they all j= ust boil down to a call to the intrinsic anyway?</div> --0016e6dedde649e19904b67327e9--
Jan 13 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 14 2012
parent Peter Alexander <peter.alexander.au gmail.com> writes:
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).
Jan 14 2012
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
 void16v
 double2v
 float4v
 byte16v
 ubyte16v
 short8v
 ushort8v
 int4v
 uint4v
 long2v

Jan 14 2012
prev sibling next sibling parent Shahid <govellius gmail.com> writes:
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.
Jan 14 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
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
Jan 14 2012
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Sun, 15 Jan 2012 06:21:22 +0100, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 1/14/2012 9:15 PM, Sean Cavanaugh wrote:
 What about the 256 bit types that are already present in AVX  
 instruction set?

Eventually, I'd like to do them, too.

https://github.com/dawgfoto/dmd/commits/AVXSupport
Jan 14 2012
prev sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Sun, 15 Jan 2012 07:07:03 +0100, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 1/14/2012 9:52 PM, Martin Nowak wrote:
 On Sun, 15 Jan 2012 06:21:22 +0100, Walter Bright  
 <newshound2 digitalmars.com>
 wrote:

 On 1/14/2012 9:15 PM, Sean Cavanaugh wrote:
 What about the 256 bit types that are already present in AVX  
 instruction set?

Eventually, I'd like to do them, too.

https://github.com/dawgfoto/dmd/commits/AVXSupport

Nice, how about a pull request?

It's still some instructions to go.
Jan 14 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 13 January 2012 19:06, Peter Alexander <peter.alexander.au gmail.com> wr=
ote:
 On 13/01/12 8:39 AM, Walter Bright wrote:
 https://github.com/D-Programming-Language/d-programming-language.org/blo=


 and core.simd:


 https://github.com/D-Programming-Language/druntime/blob/master/src/core/=



Nice! Although... import core.simd; void main() { =A0 =A0float4 a =3D void; // float a; doesn't work either =A0 =A0a =3D 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 --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Jan 13 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--bcaec51b175fd8c85704b66e2978
Content-Type: text/plain; charset=UTF-8

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? --bcaec51b175fd8c85704b66e2978 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 13 January 2012 21:06, Peter Alexander <span = dir=3D"ltr">&lt;<a href=3D"mailto:peter.alexander.au gmail.com">peter.alexa= nder.au gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote= " style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">Also, slight bikeshedding issue: I&= #39;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. Us= ing this notation for vectors may be confusing.</div> </div> </blockquote></div><br><div>I had the same feeling.</div><div>short8 really= made me instanytly uncomfortable. I&#39;m so used to seeing a number on th= e end of a trivial type as being the width in bits. Even though I knew exac= tly what I was looking at, I still unconsciously assumed this was an 8bit t= ype...</div> <div><br></div><div>It makes perfect sense for float4, since it&#39;s compl= etely absurd to imagine a 4bit float, and it&#39;s also conventional from C= g and HLSL.</div><div>I wonder if there&#39;s a nice naming convention to m= itigate this problem?</div> <div>Perhaps vshort8? Or some other small prefix/suffix?</div> --bcaec51b175fd8c85704b66e2978--
Jan 13 2012
prev sibling parent deadalnix <deadalnix gmail.com> writes:
Le 13/01/2012 09:39, Walter Bright a écrit :
 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

Let me propose something that solve this problem and many other. I never had time to explain it properly, but this is definitively interesting for this conversation, so I'll give a quick draft. The idea is to add a new ASM instruction to add an alias to a register choosen by the compiler and ensure it represent some existing variable. Thus, the compiler could ensure not to use a register already used and avoid stack manipulation when possible. This would also help ASM to get more readable. As register are not equal one to another, we need to specify which type of register we want to use. For that, we just replace the « variable » part of the register name by N. For exemple XMMN is any SSE register. RNX represent a general purpose register on x86_64. Now we define the false alias ASM instruction. Here is a (dumb) exemple : long toto = 42; long tata = 1337; asm { alias toto RNX; alias tata RNX; add toto tata; // Now toto is 1379. } If tot and tata are already in some register, the compiler can simply map. If they are in memory, the the compiler must choose a register and mov the right data into it.
Jan 14 2012