January 13, 2012
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
January 13, 2012
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
January 13, 2012
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.
January 14, 2012
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
January 14, 2012
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:
[snip]

> 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.
January 14, 2012
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.
January 14, 2012
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?


January 14, 2012
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
January 14, 2012
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.
January 14, 2012
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