suggestion: basic SIMD types modelled after Cg/HLSL

[Craig Black]

Good ideas.  Perhaps it would be easier to integrate Cg/HLSL w/ D so that 
they could work well together.  Perhaps Cg/HLSL code could  be inlined like 
assembler.  That way the full functionality of these languages could be 
leveraged.  I don't know how difficult this would be to implement though.

-Craig

"cschueler" <cschueler_member at pathlink.com> wrote in message 
news:e93n8a$27cl$1 at digitaldaemon.com...
>
> Hi list,
> I'll throw in a suggestion for extending D when no other worries are left 
> over.
>
> Why not incorporate the 4-way SIMD (single instruction multiple data) 
> vectors,
> which are available in hardware by now on virtually every platform, by 
> means of
> builtin types in the same syntax as in Cg (Nvidia's C for graphics) resp. 
> HLSL
> (high-level shading language).
>
> The rationale should be quite easy: the hardware can do it, so in the same 
> sense
> as D is enthusiastic of supporting 80-bit floats, it could as well map 
> these
> capapilites to language primitives.
>
> Here is in very compressed form what it currently looks like in Cg.
> You can define vectors like this:
>
> float2 a;
> float3 b;
> float4 c;
>
> matrices like this:
>
> float2x2 A;
> float3x4 B;
> float4x4 C;
>
> Add/Sub/Mul/Div/Compare and math functions like sqrt(), sin(), exp() etc,
> operate element wise. So in Cg
>
> float4 result = a < b;
>
> results in a float4 the elements of which are set to the comparison 
> results of
> the individual elemens (0 or 1). (I've seen in the archives one thread of 
> a
> discussion that the return type opCmp is fixed to bool so this behavior 
> might
> confilct with some existing language spec. Mind however that SIMD compare
> capability is very useful for muxing constructs.)
>
> You can swizzle element access:
>
> // put the contents of vector a in swizzled order into x
> float4 result = a.xzyw;
>
> Literal constants expand to the vector type of their context, so the 
> constant
> "1" may silently propagate to float4(1,1,1,1) if needed:
>
> // will promote to ( a + float4(1,1,1,1) ) / float4(2,2,2,2)
> float4 result = ( a + 1 ) / 2;
>
> Of course you can apply a swizzle to a propagated constant
>
> // no syntax error (why should it?)
> float4 result = (1).xyzw;
>
> Some intrinsic functions like dot and cross products are available.
> Matrix multiplcation is done with mul.
>
> float4 result = mul( matrix, vector );
> float3 result = cross( v1, v2 );
>
>
> That's for the basics. Cg/HLSL is familiar already to a number of people, 
> so in
> one scoop, you'd obviate the need for a large number of people (basically 
> the
> non-scientific crowd) to write their own matrix/vector classes and give 
> them a
> familiar syntax to boot.
>
> I'd envision that a sufficiently endowed compiler could generate code for 
> the
> laguage features even if the target platform has no SIMD hardware; much in 
> the
> same spirit of a float-emulator when native hardware is not available.
>
> Anyway, these are only points to kick off a discussion. Obvioulsy I'd like 
> D to
> move into a direction where it is useful for me (As you may infer from my 
> other
> posts :) )
>
>
>
>
>
>
>
>