SIMD support...

[Manu]

On 6 January 2012 14:56, Martin Nowak <dawg at dawgfoto.de> wrote:

> On Fri, 06 Jan 2012 09:43:30 +0100, Walter Bright <
> newshound2 at digitalmars.com> wrote:
>
>> One caveat is it is typeless; a __v128 could be used as 4 packed ints or
>> 2 packed doubles. One problem with making it typed is it'll add 10 more
>> types to the base compiler, instead of one. Maybe we should just bite the
>> bullet and do the types:
>>
>>     __vdouble2
>>     __vfloat4
>>     __vlong2
>>     __vulong2
>>     __vint4
>>     __vuint4
>>     __vshort8
>>     __vushort8
>>     __vbyte16
>>     __vubyte16
>>
>
> Those could be typedefs, i.e. alias this wrapper.
> Still simdop would not be typesafe.
>

I think they should by well defined structs with lots of type safety and
sensible methods. Not just a typedef of the typeless primitive.


> As much as this proposal presents a viable solution,
> why not spending the time to extend inline asm.
>

I think there are too many risky problems with the inline assembler (as
raised in my discussion about supporting pseudo registers in inline asm
blocks).
  * No way to allow the compiler to assign registers (pseudo registers)
  * Assembly blocks present problems for the optimiser, it's not reliable
that it can optimise around an inline asm blocks. How bad will it be when
trying to optimise around 100 small inlined functions each containing its
own inline asm blocks?
  * D's inline assembly syntax has to be carefully translated to GCC's
inline asm format when using GCC, and this needs to be done
PER-ARCHITECTURE, which Iain should not be expected to do for all the
obscure architectures GCC supports.


> What would be needed?
>  - Implement the asm allocation logic.
>  - Functions containing asm statements should participate in inlining.
>  - Determining inline cost of asm statements.
>

I raised these points in my other thread, these are all far more
complicated problems I think than exposing opcode intrinsics would be.
Opcode intrinsics are almost certainly the way to go.

When being used with typedefs for __vubyte16 et.al. this would
> allow a really clean and simple library implementation of intrinsics.
>

The type safety you're imagining here might actually be annoying when
working with the raw type and opcodes..
Consider this common situation and the code that will be built around it:
__v128 vec = { floatX, floatY, floatZ, unsigned int packedColour ); // pack
some other useful data in W
If vec were strongly typed, I would now need to start casting all over the
place to use various float and uint opcodes on this value?
I think it's correct when using SIMD at the raw level to express the type
as it is, typeless... SIMD regs are infact typeless regs, they only gain
concept of type the moment you perform an opcode on it, and only for the
duration of that opcode.

You will get your strong type safety when you make use of the float4 types
which will be created in the libs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120106/4e21081f/attachment-0001.html>